追踪将服务器CPU耗光的凶手

前面我们讨论系统调用的时候结论是耗时200ns-15us不等 。不过我今天说的我的这个遭遇可能会让你进一步认识系统调用的真正开销 。在本节里你会看到一个耗时2.5ms的connect系统调用 , 注意是毫秒,相当于2500us!
问题描述
当时是我的一个线上云控接口 , 是Nginx+lua写的 。正常情况下 , 单虚机8核8G可以抗每秒2000左右的QPS , 负载还比较健康 。但是该服务近期开始出现一些500状态的请求了 , 监控时不时会出现报警 。通过sar -u查看峰值时cpu余量只剩下了20-30% 。
 

追踪将服务器CPU耗光的凶手

文章插图
 
 
图3.jpg
第一步、迅速锁定嫌疑人
top命令查看cpu使用 , 通过top命令发现峰值的时候cpu确实消耗的比较多 , idle只有20-30%左右 。在使用的cpu里 , 软中断的占比也比较高 , 1/3左右 。
再通过cat /proc/softirqs查看到软中断是都是网络IO产生的NET_TX , NET_RX , 和时钟TIMER 。
既然软中断这个贼人吃掉了我这么多的CPU时间 , 所以案件的嫌疑人就这么初步被我锁定了 。
【追踪将服务器CPU耗光的凶手】处理 , 那既然是NET_TX , NET_RX和TIMER都高 , 那咱就挑可以削减的功能砍一砍呗 。
  • 1.砍掉多余的gettimeofday系统调用
  • 2.每个请求砍掉一次非必须redis访问 , 只留了必要的 。
结果:峰值的cpu余量从确实多出来一些了 。报警频率确实下来了 , 但是还是偶尔会有零星的报警 。可见该嫌疑人并非主犯 。。
第二步、干掉一大片 , 真凶在其中
接着查看网络连接的情况ss -n -t -a发现 , ESTABLISH状态的链接不是很多 , 但是TIME-WAIT有11W多 。继续研究发现针对


    推荐阅读