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

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

$ top -bc |grep systemd

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

image.png

于是对接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进程进行跟踪。

image.png

得到如下回显:

systemd --user进程CPU占用高问题分析_第1张图片

 看这个进程是在不停的扫描磁盘。

关于这个问题,我在《google-cloud-kuberbetes-run-away-systemd-100-cpu-usage》一文中得到答案:

systemd --user进程CPU占用高问题分析_第2张图片

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

# cat /proc/mounts |wc
  120     720   46377

2.异常节点:

# cat /proc/mounts |wc
  1017    6102  341121

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

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

systemd --user进程CPU占用高问题分析_第3张图片

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

systemd --user进程CPU占用高问题分析_第4张图片

 

 

systemd --user进程CPU占用高问题分析_第5张图片

由上图我们发行,环境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 团队给出如下优化方案:

systemd --user进程CPU占用高问题分析_第6张图片

 原文链接: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 --user进程CPU占用高问题分析)