主页 / server / 问题 / 1017133
Accepted
dsl101
Asked: 2020-05-15 05:52:39 +0800 CST

在 Ubuntu 18.04 上通过 systemd 诊断高 CPU 使用率

  • 772

不知道这到底是什么时候开始的，但我想是最近几天。我在服务器上安装了 Ubuntu 18.04，并注意到它的负载非常高。它几乎什么也没做（我已经安装了 2 个 KVM 来宾，但现在只有 1 个在运行）。它有24个逻辑核心，重启后负载一直是12个。启动/停止 KVM 来宾没有任何区别

快照htop：

htop

运行systemd-cgtop显示更多：

systemd-cgtop

在该过程上运行 stracehtop主要显示如下所示的行：

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
systemd ubuntu-18.04

1 个回答

  1. Best Answer

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

    尝试分析。安装调试符号以获取函数名称而不是无意义的数字。做大部分 CPU 时间的事情应该支配样本，但无论如何都要过滤到 systemd 命名的 PID：

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

    前几项功能将为我们的建议提供建议，并提供通过您的其他操作系统支持渠道发送的内容。

    另外，考虑在运行rescue.target 时测试这些是否仍然很忙。Rescue shell 要简单得多，没有问题会排除很早的 init。

    安装调试符号的细节通常意味着阅读Ubuntu 的符号 wiki，安装http://ddebs.ubuntu.com 存储库，并找到您最喜欢的方式来查找 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的 C++ 代码。sytsemd 是 C。门罗币加密货币在其工作证明中使用 AES 。我怀疑这个主机正在做加密挖掘。很可能来自误用或妥协。

    我不是安全人员，因此您将希望通过妥协指标找到证据。如果被感染，则会得到完整的响应。

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

    不幸的是，进行此类调查没有捷径可走。怀疑看起来不应该做什么，在开源中寻找函数名称，然后记住加密挖掘是目前的事情。

    • 1

相关问题