☰

诊断 Ubuntu 18.04 上 systemd 的高 CPU 使用率

tag-icon • tag-icon systemd ubuntu-18.04
诊断 Ubuntu 18.04 上 systemd 的高 CPU 使用率

没有把握确切地这个问题开始的时候，但我想是最近几天。我在服务器上安装了 Ubuntu 18.04，发现它的负载非常高。它几乎什么都不做（我安装了 2 个 KVM 客户机，但现在只有 1 个在运行）。它有 24 个逻辑核心，重启后负载始终为 12。启动/停止 KVM 客户机没有区别

快照htop：

顶部

跑步systemd-cgtop并没有显示出更多：

systemd-cgtop

对该进程运行 strace，htop主要显示如下内容：

epoll_pwait(4, [], 1024, 345, NULL, 8)  = 0
epoll_pwait(4, [], 1024, 154, NULL, 8)  = 0
epoll_pwait(4, [], 1024, 500, NULL, 8)  = 0
epoll_pwait(4, [], 1024, 345, NULL, 8)  = 0
epoll_pwait(4, [], 1024, 155, NULL, 8)  = 0

偶尔会混合：

epoll_pwait(4, [], 1024, 160, NULL, 8)  = 0
epoll_pwait(4, [{EPOLLIN, {u32=13, u64=13}}], 1024, 500, NULL, 8) = 1
read(13, "{\"id\":90,\"jsonrpc\":\"2.0\",\"error\""..., 2048) = 64
futex(0xa15408, FUTEX_WAKE_PRIVATE, 1)  = 1
futex(0xa153a0, FUTEX_WAKE_PRIVATE, 1)  = 1
epoll_pwait(4, [{EPOLLIN, {u32=9, u64=9}}], 1024, 164, NULL, 8) = 1
read(9, "\1\0\0\0\0\0\0\0", 1024)       = 8
epoll_pwait(4, [], 1024, 164, NULL, 8)  = 0

如果我终止该进程，一切出现恢复正常 — — 当然是负载方面，而且 KVM 客户端似乎不受影响。

我还能尝试其他什么来找出根本原因吗？

其他信息——请询问其他有用的信息：

# dpkg -l systemd
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                    Version          Architecture     Description
+++-=======================-================-================-===================================================
ii  systemd                 237-3ubuntu10.40 amd64            system and service manager

# apt list --installed | grep systemd
libnss-systemd/bionic-updates,now 237-3ubuntu10.40 amd64 [installed]
libpam-systemd/bionic-updates,now 237-3ubuntu10.40 amd64 [installed]
libsystemd0/bionic-updates,now 237-3ubuntu10.40 amd64 [installed]
python3-systemd/bionic,now 234-1build1 amd64 [installed]
systemd/bionic-updates,now 237-3ubuntu10.40 amd64 [installed]
systemd-sysv/bionic-updates,now 237-3ubuntu10.40 amd64 [installed]

输出perf top --pid=$(pgrep systemd -d,)：

Samples: 4M of event 'cycles:ppp', Event count (approx.): 455698006733
Overhead  Shared Object             Symbol
   4.07%  systemd                   [.] hashAes1Rx4<false>
   2.90%  systemd                   [.] fillAes1Rx4<false>
   0.44%  systemd                   [.] randomx::JitCompilerX86::generateProgramPrologue
   0.32%  perf-1597.map             [.] 0x00007f4fe9795105
   0.28%  perf-1597.map             [.] 0x00007f4fe97c5105
   0.28%  perf-1597.map             [.] 0x00007f4fe97b5105
   0.28%  perf-1597.map             [.] 0x00007f4fe9795129
   0.28%  perf-1597.map             [.] 0x00007f4fe97a5105
   0.27%  perf-1597.map             [.] 0x00007f4fe97e5105
   0.27%  perf-1597.map             [.] 0x00007f4fe97d5105
   0.25%  perf-1597.map             [.] 0x00007f4fe97c5129
   0.25%  perf-1597.map             [.] 0x00007f4fe97b5129
   0.25%  perf-1597.map             [.] 0x00007f4fe97d5129
   0.25%  perf-1597.map             [.] 0x00007f4fe97e5129
   0.25%  perf-1597.map             [.] 0x00007f4fe97a5129
   0.24%  perf-1597.map             [.] 0x00007f4fe9845129
   0.24%  perf-1597.map             [.] 0x00007f4fe9825129
   0.24%  perf-1597.map             [.] 0x00007f4fe9815129
   0.24%  perf-1597.map             [.] 0x00007f4fe9835129
   0.24%  perf-1597.map             [.] 0x00007f4fe9845105
   0.23%  perf-1597.map             [.] 0x00007f4fe9805129
   0.23%  perf-1597.map             [.] 0x00007f4fe9835105
   0.23%  perf-1597.map             [.] 0x00007f4fe97f5129
   0.23%  perf-1597.map             [.] 0x00007f4fe9825105
   0.23%  perf-1597.map             [.] 0x00007f4fe9815105
   0.23%  perf-1597.map             [.] 0x00007f4fe97f5105
   0.23%  perf-1597.map             [.] 0x00007f4fe9805105
   0.16%  systemd                   [.] randomx::JitCompilerX86::h_CBRANCH
   0.09%  systemd                   [.] randomx::JitCompilerX86::h_ISTORE
   0.08%  systemd                   [.] fillAes4Rx4<false>
   0.08%  systemd                   [.] randomx::JitCompilerX86::h_FMUL_R
   0.05%  systemd                   [.] randomx::JitCompilerX86::h_IADD_RS
   0.05%  systemd                   [.] randomx_reciprocal_fast
   0.05%  systemd                   [.] randomx::JitCompilerX86::h_IMUL_R
   0.05%  systemd                   [.] randomx::JitCompilerX86::h_ISUB_R
   0.04%  systemd                   [.] randomx::JitCompilerX86::h_IXOR_R
   0.04%  systemd                   [.] randomx::JitCompilerX86::h_FSUB_R

答案1

将有助于了解这些 PID 到底在做什么。strace 不是一个完整的图景，因为采样的系统调用可能与其性能无关。

尝试分析。安装调试符号以获取函数名称而不是无意义的数字。占用 CPU 时间最多的程序应该主导样本，但无论如何都要过滤到 systemd 命名的 PID：

perf top --pid=$(pgrep systemd -d,)

最重要的几个功能将提供我们的建议，并提供一些内容通过其他操作系统支持渠道发送。

另外，考虑测试在运行 rescue.target 时这些是否仍然处于繁忙状态。救援 shell 要简单得多，并且没有问题可以排除非常早期的初始化。

安装调试符号的细节通常意味着阅读Ubuntu 的符号 wiki，安装一个http://ddebs.ubuntu.com repo，并找到您最喜欢的查找 dbgsym 包的方法。从systemd-dbgsym大概涵盖systemd二进制文件开始。此外，我偏向于 wiki 的建议

apt install debian-goodies
find-dbgsym-packages [core_path|running_pid|binary_path]

成功意味着查看perf top或gdb堆栈跟踪，找到熟悉的函数名称并使用它来进一步调查。

hashAes1Rx4 似乎是一个 AES 哈希原语。在 GitHub 上搜索它的代码会找到各种加密代码，但没有直接与 systemd 相关的内容。

但是等等，randomx::JitCompilerX86来自工作量证明项目. sysmd 是 C。Monero 加密货币使用 AES在其工作量证明中。我怀疑该主机正在进行加密挖掘。很可能是由于误用或泄露。

我不是一名安全人员，所以你会希望通过入侵指标找到证据。如果被感染，则需要完整的响应。

但是，这可以解释一些令人费解的行为。systemd 不是用 C++ 编写的。并且没有执行那么多 AES 的用例，不会压垮您的实际计算工作量。单位完成的工作将出现在他们的 cgroup 中。但假装是 systemd 二进制文件对于恶意软件来说是一个很好的伪装。

不幸的是，进行此类调查没有捷径。怀疑它看起来不像应该做的事情，在开源中寻找函数名称，然后想起加密挖掘目前是一件大事。

相关内容