Назад | Перейти на главную страницу

Диагностика высокой загрузки ЦП с помощью systemd в Ubuntu 18.04

Точно сказать не могу именно когда это началось, но думаю, в последние дни. У меня на сервере установлен 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

systemd ubuntu-18.04

Помогло бы понять, что именно делают эти PID. strace не дает полной картины, так как выбранные системные вызовы могут не иметь отношения к его производительности.

Попробуйте профилировать. Установите символы отладки, чтобы получать имена функций, а не бессмысленные числа. То, что делает большую часть времени ЦП, должно преобладать над выборками, но все равно фильтровать до systemd с именами PID:

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

Несколько основных функций дадут советы по нашим предложениям, а также предоставят информацию для отправки через другие каналы поддержки вашей ОС.

Также подумайте о том, чтобы проверить, заняты ли они по-прежнему, при запуске rescue.target. Спасательная оболочка намного проще, и отсутствие проблемы исключает очень ранний запуск.

Особенности установки отладочных символов обычно подразумевают чтение Вики по символам Ubuntu, установка http://ddebs.ubuntu.com repo и найдите свой любимый способ найти пакеты dbgsym. Начиная с systemd-dbgsym как предположительно это охватывает systemd двоичный. Кроме того, я неравнодушен к предложению вики о

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. Криптовалюта Monero использует AES в доказательстве работы. Я подозреваю, что этот хост занимается майнингом криптовалют. Очень вероятно из-за неправильного использования или компромисса.

Я не специалист по безопасности, поэтому вы захотите найти доказательства с помощью индикаторов взлома. И полный ответ, если заражен.

Однако это объяснило бы некоторое загадочное поведение. systemd не написан на C ++. И у него нет варианта использования для выполнения такого большого количества AES, не перегружающего ваши фактические вычислительные рабочие нагрузки. Работа, проделанная юнитами, будет отображаться в их контрольных группах. Но выдать себя за двоичный файл systemd было бы хорошей маскировкой для вредоносных программ.

К сожалению, у нас нет ярлыка для проведения такого расследования. Подозрение, которое не похоже на то, что он должен делать, поиск названий функций в открытом исходном коде, а затем вспоминание о том, что майнинг криптовалют - это вещь в данный момент.