Eu tenho um sistema Linux remoto que ficou super lento ontem. Como o desbloqueio remoto do luks que configurei não parece funcionar de maneira confiável e não poderei acessar fisicamente a máquina nos próximos 10 dias, estou tentando depurar isso em vez de reinicializar.
As ferramentas de status do sistema com as quais estou acostumado são htope dstatdesde que executei dstatuma sessão ssh posso ver que desde ontem 2021-09-09 08:51:42 um núcleo da CPU é sempre totalmente usado por "sys" - o que eu acho que significa o kernel?
Não consigo ver nenhum processo ou thread culpado no htop.
Parei todos os serviços do usuário e desmontei tudo o que não era essencial, o que fez o sistema responder um pouco melhor novamente, mas ainda não tão rápido quanto deveria (comprei uma CPU Intel i7 com SSD).
encontreihttps://tanelpoder.com/posts/high-system-load-low-cpu-utilization-on-linux/e instalei o referenciadohttps://0x.tools/para obter este resultado para 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
O dpkgprocesso pode ser explicado por eu tentar correr apt upgradea 1/1000 da velocidade que você normalmente esperaria (apenas uma sensação, não medi).
Talvez haja um problema com meu sistema de arquivos raiz btrfs...? Não consigo encontrar o btrfs-cleanerin htop, acho que vou pesquisar um pouco mais sobre o que é.
Eu executei uma btrfs scrubnoite passada que foi super rápida e não encontrei nenhum problema:
# 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
Mas quando usei o nano para modificar um arquivo de configuração na partição raiz, carregando e salvando, ficou muito lento agora.
Acabei de me deparar com isso:https://www.reddit.com/r/btrfs/comments/fmucrq/btrfs_snapshots_make_entire_system_lag_cpu_usage/que tem um comentário semelhante ao meu problema:
toda vez na inicialização e após um instantâneo, o btrfs-transacti e o btrfs-cleaner consumiriam um núcleo completamente, causando um atraso imenso
apenas que isso diz que dura apenas alguns minutos na inicialização e na criação de instantâneos, mas desativei minha btrbkconfiguração de backup neste sistema há alguns dias, quando um dos discos anexados começou a apresentar problemas.
Não tenho certeza se meu sistema de arquivos raiz btrfs estava usando qgroups, mas acabei de executar btrfs quota disable /o que levou cerca de 10 segundos e não dei nenhum feedback.
Alguém tem alguma outra dica para mim sobre como depurar/resolver esse problema?
Responder1
O problema são essas cotas btrfs. Correndo
btrfs quota disable /
tornou o sistema utilizável novamente :)