在 Ubuntu 18.04 上通過 systemd 診斷高 CPU 使用率
不知道這到底是什麼時候開始的，但我想是最近幾天。我在伺服器上安裝了 Ubuntu 18.04，並註意到它的負載非常高。它幾乎什麼也沒做（我已經安裝了 2 個 KVM 來賓，但現在只有 1 個在執行）。它有24個邏輯核心，重啟後負載一直是12個。啟動/停止 KVM 來賓沒有任何區別
快照
htop：
執行
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
將有助於了解這些 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 二進製文件是惡意軟體的一個很好的偽裝。
不幸的是，進行此類調查沒有捷徑可走。懷疑看起來不應該做什麼，在開源中尋找函式名稱，然後記住加密探勘是目前的事情。