问题背景

线上系统从 CentOS 6 迁往 CentOS 7,整个过程较为顺利,但在使用中发现了一个奇怪的问题,在处理计算任务的机器上,CPU计算部分的耗时在不同节点上存在差异且差异显著,如下图所示:

A12280BA-1D10-4FC6-8C61-66C73A1A424B.png

出问题的机器计算耗时波动剧烈,耗时差别达到30%~50%,极端的 case 会更高,但并非所有机器、所有请求都受到影响。在初期问题机器只集中在个别机器和高峰时间段,高峰过后就会恢复,到后期则是随机的机器和全时间段,压力退去之后也不能恢复,重启大法也不能奈何。
这个问题的诡异之处就在于它的飘忽不定,定位经历了很长时间,也是很偶然的看到一篇文章才解决了问题

解决过程

CentOS 7集群上线之初由于存在两种机型,差别仅在于磁盘的区别,而出问题的机器则集中在同一种机型上,所以开始很自然的认为是机器配置导致的问题,观察各项监控,发现 cpu.system占用较高,说明有频繁的系统调用,最常见的情况自然是 IO 有问题,排查网络交互均正常,内存看不出问题,加上磁盘本身就存在区别,程序又有大量的日志输出,监控 agent 一直槽点多多,怀疑的重点转移到磁盘读写这块儿了,刚好磁盘的监控确实也有点不同(下图中下方红线部分):

A5B1559E-2447-476A-8BB1-BC8712399D0A.png

由于代码都是原来的一套,在原来的机器上也没有问题,那么性能更强的新机器上,出问题的概率也很小,那么问题很可能是出现在读日志的监控 agent 上了,鉴于新agent 属于第一次使用,本身 cpu 占用率也很高,在各项指标都指向它且没有强力证据自证清白,只好当仁不让的背起了这口锅(当然最后事实证明并不是 agent 的原因,记录事情发展经过)。排除 agent 的可能后,再回过头来反复观察对比各项监控(top,vmstate,iostate,sar 以及系统监控等),除了cpu.system,cpu.context_switch,load 等始终存在区别,其它指标时常反复,没有什么线索。考虑到已花了较多的时间,而且只有固定的几台有问题,干脆在机型替换时直接换掉,一了百了。

但问题在替换机器之后发生了很大的变化,如下图:

DBEDD890-94AF-491F-A44B-917B25C6CBC3.png

在替换之前,只有固定的机器在高峰期耗时变长,而替换之后,原本正常的机器也随机的开始不正常,并且在高峰过后,这种不正常的状况会一直持续,无法自行恢复,仿佛进入了一种混沌的状态。这下问题就有点严重了。

重新集中观察对比各项监控指标,除了system 和 context_switch 之外,此时又观察到 softirq 以及 migration 进程存在区别。同时,设计实验证明,在异常时,并非整机有问题,而是部分请求(或者说部分进程)出现长耗时,而同期其它请求正常,在继续排除了 NGXIN PHP 等常驻进程的问题后,问题范围可以缩小一些了,猜测系统配置问题的可能性较大,只是是哪个,还得找。

继续实验的同时,借助 Google,将各种已明确的指标和现象抽出关键字各种搜索,终于,很幸运找到了一篇文章,大意是从 CentOS 6 向 CentOS 7 迁移后,也发生了性能下降的问题,显著的表现也是 context_switch 和 softirq 指标显著不同,load 存在区别,性能不及预期的情况,这位仁兄在历经各种心酸血泪(各种更新内核,更换 OS重装,重装驱动等等)之后才解决,初读并没觉得和我们是一个问题,再次阅读的时候,发现其中指标差异有点类似,抱着试试的态度,尝试了一下他的解决方案,问题解决!

问题解决

方案得来不易,怎么做的就不直接剧透了,和 NUMA Balancing 有关,想了解具体情况的,点击博客贡献访问量吧。

关于 NUMA,其中一篇介绍如下:
NUMA架构的CPU — 你真的用好了么? - CSDN博客