日记238. 进程都被绑在一个核上，如何定位？

一、背景

周三本来要拉这个一个同事 B 开会，他说在处理一个 XX 项目的问题，周二遇到的，还没找到原因。

我问这个项目不是交接给 同事 C 出去了吗？
回答得知，这个问题比较大，已经拉了同事 A 一起帮忙看了。

原来，当初这个项目是其他团队同事 A 负责的，后来交接给我们团队的 同事 B，然后他有交接给其他团队的同事 C。

我说问题给我描述一下，我来帮你们看下吧。

二、问题现象

有一个服务，架构是多进程模式。

现在发现进程的亲和性(affinity)都被绑定在了CPU 1 上。
这就导致这个核的 CPU 跑满了，然后服务就高负载了。

问重启可以解决问题吗？
回答不能解决问题。

问新扩容服务，可以解决问题吗？
回答不能解决。

于是我就申请了这个项目服务机器的登陆权限，去看看这个申请的问题。

三、问题分析

首先介绍下多进程服务的架构，具体来说分为三类进行：控制进程、收发包进程、逻辑进程组。
控制进程只有一个，收发包进程只有一个，逻辑进程组有多个，业务逻辑都在这个进程组里。
启动的时候，只需要启动控制进程，控制进程会根据配置，拉起收发包进程和逻辑进程组。

分析1：首先我怀疑是机器的问题。
问同事 B 相同机器的其他服务业这样吗？
回答其他服务都正常。
这个信息可以推理出是这个服务自身的问题，不是机器的问题。

我先去申请了这个服务所有机器的 root 权限。

分析2：拿到权限后，做的第一件事是查看 root 用户和普通用户的 crontab 配置。
先看看是不是有定时脚本来自动绑核。
发现 crontab 都是正常的。
这说明没有脚本来自动绑核。

分析3：我在这个服务的路径下全文搜索 taskset 关键词，看是否有某个脚本来绑核。
结果没搜到任何内容。
这说明启动服务的时候，也没有 Shell 命令来绑核。

分析4：写了一个 bash 函数，查看这个项目所有进程的绑核情况。
结果发现，控制进程和逻辑进程被绑核了，收发包进程进程竟然没有被绑核。
这说明这个绑核逻辑还有特殊逻辑，只对控制进程和逻辑进程绑核了。

pidlist=$(ps -aef | grep svr_name | grep -v grep | awk '{print $2}')
user_name=xxxx
for x in $pidlist; 
do 
    ps -aef | grep -E "$user_name\s+$x " | grep -v "grep"
    taskset -p $x; 
done

分析5：手动杀死一个逻辑进行，再马上手动启动逻辑进程。
结果发现，手动启动的逻辑进程没有被绑核。
这说明没有外部的脚本或任务来绑核，业务逻辑也没有主动绑核，既有可能是控制进程自身进行了绑核。

分析6：不使用发布系统的启动命令，手动启动控制进程。
结果发现，控制进程和逻辑进程依旧被绑核了。
这说明与发布系统无关，肯定是控制进程自身的问题。

分析7：查看控制进程的配置文件。
结果发现配置文件里配置了亲和性 affinity。
这说明问题原因找到了，控制进程自身的问题。

配置文件是由另外一个程序读取业务配置生成的。
分析8：查看业务的配置。
没有发现配置绑核逻辑。
这说明业务的配置没问题，是服务框架自身的问题。

分析9：手动删除系统配置文件，手动重新生成系统配置。
发现生成的配置依旧有绑核。
这说明系统配置生成工具有问题。

分析10：查看正常服务生成工具的 md5与当前工具的 md5。
发现 md5 不一样，创建时间也不一样，有问题的是两年前的，没问题的是四年前的。
这说明是两年前网络框架进行了升级，导致这个问题。

分析11：查看正常服务与当前服务的网络框架版本。
发现正常服务使用的是 4 年前的稳定版网络框架，异常服务使用的 2 年前的灰度版本。
这说明 2 年前的灰度版本网络框架有 BUG。

分析12：使用我自己的服务部署 2 年前的灰度版本网络框架。
发现我的服务业发生绑核问题。
这说明确实是网络框架的问题。

分析13：找对应同事要到网络框架代码，查看代码。
发现 2 年前确实有变更，默认值是绑定一个核。
这再次说明是网络框架的问题。

四、最后

我找网络框架的同学反馈问题时，他们说 2 年前大家都开始上云并使用新网络框架，这个框架早就不维护了。

好吧，还能说什么呢，至少要把有问题的框架版本删除吧。

这次我们这个服务解决了这个问题，但是看有 BUG 的那个网络框架版本还部署了 130 个服务。
这说明至少还有 130 个服务有这个问题。

晚点我拉个群，周知一下这些人吧。

《完》

-EOF-

本文公众号：天空的代码世界
个人微信号：tiankonguse