故障现象
CPU空闲率突然从85%降到30%左右，出现资源不足的告警。当前线上Nginx集群CPU出现瓶颈，可能对请求处理带来较大的延时，好在10min左右故障自动恢复，本文将记录故障时的排查过程，以供读者参考。
故障排查
CPU使用率告警后，第一时间上服务器上确认情况，CPU使用率确实突然使用了70%以上且都是cpu.user用户空间的使用。
通过perf top命令查看发现bn_sqrx8x_internal,mul4x_internal 使用CPU增高，是导致整体CPU使用的直接原因。bn_sqrx8x_internal,mul4x_internall函数是处理https握手阶段的openssl相关的函数，所以接下来查看流量是否突增。
第一时间查看了网卡流量和nginx日志，发现服务器整体网卡流量和ES中的nginx访问日志量有所增加，和故障时间吻合，所以基本可以确定是访问量变化导致的Nginx CPU使用率突然上升，和业务线确认后也证实了这一点。
但是问题来了？业务访问量是上升了，但是网卡流量整体并没有上涨多少，从30Mbps到40Mbps，完全在可接受范围内，但是为什么CPU使用率会上涨到这么多呢？
这个时候想看下是不是服务器收到了大量的数据小包，如果小包数量上升的太大，会使整体网卡流量涨幅不大，但是服务器在处理这些小包的过程可能会消耗较多的CPU。查看网卡数据包监控发现：
故障发生时，服务器收到大量的数据包，联想perf top排查结果，想到是此时有大量HTTPS请求过来，导致服务器在HTTPS握手过程消耗大量的CPU资源，从而导致CPU资源到达瓶颈。
得出结论
查看Nginx配置发现，之前添加的SSL相关的配置中，对ssl_session_timeout配置了10s，Nginx官网对这个参数的解释：
1 | Syntax: ssl_session_timeout time; |
这个参数指定客户端可以重用会话参数的时间，默认是5m，如果时间太短，会导致同一客户端不能重用会话参数，从而在HTTPS请求量增加时会导致大量的HTTPS握手处理，消耗大量的CPU资源。
解决优化
灰度调整参数ssl_session_timeout到10m。
支付宝打赏
微信打赏
赞赏支持一下
