У меня есть удаленная система Linux, которая вчера стала очень медленной. Поскольку удаленная разблокировка Luks, которую я настроил, работает ненадежно, и я не смогу физически получить доступ к машине в течение следующих 10 дней, я пытаюсь отладить ее вместо перезагрузки.
Инструменты состояния системы, к которым я привык, это htopи dstat, поскольку я dstatработал в сеансе SSH, я вижу, что со вчерашнего дня 2021-09-09 08:51:42 одно ядро процессора всегда полностью используется «sys» — что, как я полагаю, означает ядро?
Я не вижу ни одного процесса или потока, вызывающего проблему htop.
Я остановил все пользовательские службы и отмонтировал все ненужное, что позволило системе снова немного улучшить работу, но все равно не так быстро, как следовало бы (у меня процессор Intel i7 с SSD).
Я нашелhttps://tanelpoder.com/posts/high-system-load-low-cpu-utilization-on-linux/и установил указанныйhttps://0x.tools/чтобы получить этот результат для psn -G syscall,wchan:
=== Active Threads ========================================================================================
samples | avg_threads | comm | state | syscall | wchan
-----------------------------------------------------------------------------------------------------------
100 | 1.00 | (btrfs-cleaner) | Running (ON CPU) | [running] | 0
100 | 1.00 | (dpkg) | Disk (Uninterruptible) | fsync | btrfs_commit_transaction
100 | 1.00 | (systemd-journal) | Disk (Uninterruptible) | ftruncate | wait_current_trans
1 | 0.01 | (sshd) | Running (ON CPU) | [running] | 0
1 | 0.01 | (thermald) | Disk (Uninterruptible) | [running] | ec_guard
1 | 0.01 | (thermald) | Running (ON CPU) | [running] | 0
Процесс dpkgможно объяснить, если попытаться пробежать apt upgradeэтот участок примерно со скоростью, составляющей 1/1000 от обычной скорости (это просто ощущение, я не измерял).
Может быть, проблема с моей корневой файловой системой btrfs...? Я не могу найти в btrfs-cleaner, htopдумаю, мне нужно будет побольше узнать, в чем дело..
Вчера вечером я запустил тест, btrfs scrubкоторый завершился очень быстро и не обнаружил никаких проблем:
# btrfs scrub status /
UUID: 2f38e0ad-7f16-4a36-8096-b7981d47b4ff
Scrub started: Thu Sep 9 23:59:00 2021
Status: finished
Duration: 0:00:24
Total to scrub: 53.09GiB
Rate: 1.78GiB/s
Error summary: no errors found
Но когда я использовал nano для изменения файла конфигурации в корневом разделе, загрузка и сохранение были очень медленными.
Я только что наткнулся на это:https://www.reddit.com/r/btrfs/comments/fmucrq/btrfs_snapshots_make_entire_system_lag_cpu_usage/в котором есть комментарий, который похож на мою проблему:
каждый раз при загрузке и после снимка btrfs-transacti и btrfs-cleaner полностью использовали ядро, вызывая огромную задержку
только там говорится, что загрузка и создание снимка занимают всего несколько минут, но я отключил btrbkнастройку резервного копирования в этой системе несколько дней назад, когда на одном из подключенных дисков начали возникать проблемы.
Я не уверен, использовалась ли моя корневая файловая система btrfs qgroups, но я только что запустил ее btrfs quota disable /, что заняло около 10 секунд и не дало никакой обратной связи.
Есть ли у кого-нибудь еще подсказки, как отладить/решить эту проблему?
решение1
Проблема в том, что эти квоты btrfs. Работает
btrfs quota disable /
сделал систему снова пригодной к использованию :)