systemd|systemd --user进程CPU占用高问题分析 systemd--user进程CPU占用高问题分

1.问题由来近期发现堡垒机环境有如下问题，systemd占用大量cpu：

文章图片

原文链接：https://www.cnblogs.com/yaohong/p/16046670.html

2.问题定位 2.1.什么是systemd 咋们可以先从systemd这个进程入手分析这个问题：
根据文档《systemd (简体中文)》文档，我们可知如下图信息：
作用：
systemd 会给每个用户生成一个 systemd 实例，用户可以在这个实例下管理服务，启动、停止、启用以及禁用他们自己的单元。
工作原理：

“从 systemd 226 版本开始，/etc/pam.d/system-login 默认配置中的 pam_systemd 模块会在用户首次登录的时候, 自动运行一个 systemd --user 实例。只要用户还有会话存在，这个进程就不会退出；用户所有会话退出时，进程将会被销毁。”。

根据上面这段话，我们可以猜测：ssh登录时可以创建systemd进程，ssh退出登录时可以销毁systemd --user进程。
怀着这个猜测，我们进行下面的研究分析。
2.2.systemd进程怎么产生的首先,我们在第一个终端，执行下面的命令创建test3用户:

$ groupadd test3 $ useradd -g test3 -m -d /home/test3 -s /bin/bash test3 $ passwd test3

然后，在第二个终端，执行ssh登录test3

$ ssh test3@172.21.0.46

接着，在第一个终端，执行如下命令过滤新产生的test3 用户的systemd进程

$ top -bc |grep systemd

得到如下图回显，可知：1.9秒前产生了一个pid为19178的systemd --user进程，此进程占用了40.9%的CPU。

文章图片

于是对接systemd进程创建得出如下结论：
systemd版本大于226（centos7为219、ubuntu1604为229），ssh 登录会产生登录用户对应的systemd进程。
2.3.systemd进程为何没有被销毁既然ssh登录会产生systemd进程，那退出ssh登录应该会销毁对应systemd进程。
于是，我们在2.2中的第二个窗口执行 exit退出ssh连接。

$ exit

文章图片

然后，再执行如下命令,发现没有test3用户的systemd进程了。

$ top -bc | grep systemd

至此，我们对systemd进程的退出也有了了解：退出ssh连接即可销毁对应systemd进程。
但，为什么我们看到的腾讯云环境上systemd进程一直没有被销毁？

文章图片

此时我想到了 非正常退出ssh连接，
如2.1章节，在第二个终端，执行ssh登录test3，再如下图直接点“X”直接关闭窗口，

文章图片

然后，在第一个终端，执行如下命令过滤新产生的test3 用户的systemd进程

$ top -bc |grep systemd

test3用户的systemd进程还存在，惊讶！！！
于是分别做如下操作对systemd进程关闭做测试，并得出相应结论:

1.xshell连内部vmware上虚拟机环境，点“X”号关闭窗口，对应systemd进程正常销毁；
2.web端连公司堡垒机上的云主机环境，点“X”号关闭窗口，对应systemd进程不能被销毁；
3.web端通过部门内部运维平台连接内部虚拟机环境，点“X”号关闭窗口，对应systemd进程不能被销毁；

于是对于systemd进程销毁得出如下结论：
web端连接的虚拟机终端，直接点“X”号关闭窗口，登录用户对应的systemd进程都不能被销毁，exit命令退出终端登录可以销毁，Xshell无此问题。
2.4.systemd进程吃CPU的原因关于进程跟踪我们很容易想到strace命令。
我们对2.1章节中创建的test3的systemd进程进行跟踪。

文章图片

得到如下回显：

文章图片

看这个进程是在不停的扫描磁盘。
关于这个问题，我在《google-cloud-kuberbetes-run-away-systemd-100-cpu-usage》一文中得到答案：

文章图片

Docker在17.03和18.09版本之间的变化导致了大量的systemd活动，无论在pod中执行了什么。同时，只要runc发生change，它导致所有mount units被重新加载，作为执行存活探针的一部分。
于是针对这个猜想，我看了下k8s同一集群中systemd正常与异常的节点：
1.正常节点：

# cat /proc/mounts |wc 12072046377

2.异常节点：

# cat /proc/mounts |wc 10176102341121

于是瞬间也有了结论：
systemd 进程cpu使用率太高是因为mount挂载点太多，mount有更新后，通过dbus通知到systemd重新遍历所有mount，遍历操作比较耗cpu。
同时，既然说到和docker版本有关系，我便针对性找了两个有差异的环境做docker版本对不：

1.ubuntu1604+mount挂载多+systemd正常环境

文章图片

2.ubuntu1604+mount挂载多+systemd异常环境

文章图片

文章图片

由上图我们发行，环境1中mount挂载为1537个，比环境2中mount挂载为1028个更高但是没出现systemd吃cpu问题，可知系统相同情况下和docker版本有关。
对于什么情况下出现systemd占用高，我们得出如下结论：
systemd版本大于226（ubuntu1604为229）+docker版本为19.03.14，无论runc做了什么操作，dbus会通知systemd重新遍历 mount，遍历mout过多（cat /proc/mounts |wc命令查看）会导致systemd进程吃CPU。
三、解决方案 1.不使用web终端连接systemd版本大于226，docker>=19.03.14的环境，可以使用比如xshell连接。
2.针对runc活动导致systemd进程吃CPU问题，google GKE 团队给出如下优化方案：

文章图片

原文链接：https://www.cnblogs.com/yaohong/p/16046670.html
四、总结 1.systemd进程如何被创建：systemd版本大于226（centos7为219、ubuntu1604为229），ssh 登录会产生登录用户对应的systemd --user进程。
2.systemd进程为何未被销毁：web端连接的虚拟机终端，直接点“X”号关闭窗口，登录用户对应的systemd进程都不能被销毁，exit命令退出终端登录可以销毁，Xshell无此问题。
3.systemd进程为何吃cpu：systemd版本大于226（ubuntu1604为229）+docker版本为19.03.14，无论runc做了什么操作，dbus会通知systemd重新遍历 mount，如果遍历mount过多（cat /proc/mounts |wc命令查看，700个会吃30%CPU，1000个会吃50%左右CPU）就会导致systemd进程吃CPU。
原文链接：https://www.cnblogs.com/yaohong/p/16046670.html
五、参考文档《systemd (简体中文)》
《google-cloud-kuberbetes-run-away-systemd-100-cpu-usage》
《原文链接：https://www.cnblogs.com/yaohong/p/16046670.html》
【systemd|systemd --user进程CPU占用高问题分析】