核心是确认worker进程是否无约束争抢TLS资源，表现为多PID绑定同一PSR、perf显示ssl3_read_bytes等函数占比高、OCSP或会话缓存配置不当引发CPU争抢。
排查 Nginx SSL 模块运行时的资源竞争，核心是确认多个 worker 进程是否在无约束调度下争抢 TLS 握手与加解密资源——这会导致缓存失效、TLB miss 和跨核迁移开销激增，表现为 CPU 使用率异常偏高但吞吐未提升。
观察进程与 CPU 绑定状态
资源竞争常体现为多个 worker 被调度到同一物理核心上。执行以下命令验证：
- ps -eo pid,psr,comm | grep 'nginx: worker' | sort -k2,2n：若多个 PID 显示相同 PSR（CPU 编号），说明存在绑定冲突
- top -H -p $(pgrep nginx | head -1)：查看线程级 CPU 占用，若某核心上多个 nginx 线程持续高于 80%，即为典型争抢信号
定位 TLS 层计算热点
用性能分析工具确认是否 SSL 处理成为瓶颈：
- perf top -p $(pgrep nginx | head -1) -g：重点关注函数占比，如 ssl3_read_bytes、EVP_EncryptFinal_ex 或 ecdsa_sign_setup 占比显著偏高，说明 TLS 加解密或签名操作消耗过大
- 结合 nginx -V | grep ssl 确认 OpenSSL 版本，低于 1.1.1 的版本无法启用 TLSv1.3，握手开销难以下降
检查会话复用与缓存配置合理性
不当的 SSL 会话缓存策略会加剧竞争，尤其当大量短连接反复新建会话时：
- 检查 ssl_session_cache 是否设为 shared:SSL:20m 及以上，并确认 ssl_session_timeout 不超过 4 小时（建议 2–4h）
- 若 ssl_session_tickets on 启用，需确保 ssl_session_ticket_key 文件存在且权限受限（仅 nginx 主进程可读）
- 临时关闭会话票据和缓存（ssl_session_tickets off; ssl_session_cache off;），观察 CPU 是否回落，可辅助判断是否缓存管理引发争抢
排除 OCSP Stapling 与模块干扰
OCSP 响应获取失败或第三方模块 SSL 回调异常，也可能导致 worker 阻塞或内存堆积，间接引发资源争抢：
- 将 ssl_stapling 改为 off 并重启，观察 error_log 中是否仍有大量 ngx_ssl_stapling_cert_t 相关警告或内存增长趋势减缓
- 检查是否加载了 Lua、ModSecurity、自定义证书校验等模块；若有，尝试禁用后对比 worker 内存/CPU 行为
- 启用 debug 日志（error_log /var/log/nginx/ssl_debug.log debug;），筛选含 ssl handshake、no shared cipher、version too low 的条目，高频出现说明客户端兼容性差，频繁重试加重竞争
