Tengo un sistema Linux remoto que ayer se volvió muy lento. Dado que el desbloqueo remoto de luks que configuré no parece funcionar de manera confiable y no podré acceder físicamente a la máquina dentro de los próximos 10 días, estoy intentando depurar esto en lugar de reiniciar.
Las herramientas de estado del sistema a las que estoy acostumbrado son htopy dstat, dado que las ejecuté dstaten una sesión ssh, puedo ver que desde ayer 2021-09-09 08:51:42 "sys" siempre utiliza completamente un núcleo de CPU, lo cual Supongo que se refiere al núcleo.
No veo ningún proceso o hilo culpable en htop.
Detuve todos los servicios de usuario y desmonté todo lo que no fuera esencial, lo que hizo que el sistema respondiera un poco mejor nuevamente, pero aún no tan rápido como debería (obtuve una CPU Intel i7 con un SSD).
He encontradohttps://tanelpoder.com/posts/high-system-load-low-cpu-utilization-on-linux/e instalé el referenciadohttps://0x.tools/para obtener 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
El dpkgproceso se puede explicar si intento correr apt upgradea 1/1000 de la velocidad que normalmente se esperaría (solo una sensación, no la medí).
¿Quizás hay un problema con mi sistema de archivos raíz btrfs...? No puedo encontrar la btrfs-cleanerentrada htop, supongo que voy a investigar un poco más sobre qué es eso.
Anoche ejecuté un btrfs scrubanálisis que se completó súper rápido y no encontré ningún 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
Pero cuando usé nano para modificar un archivo de configuración en la partición raíz, cargarlo y guardarlo fue muy lento en este momento.
Me acabo de topar con esto:https://www.reddit.com/r/btrfs/comments/fmucrq/btrfs_snapshots_make_entire_system_lag_cpu_usage/que tiene un comentario que suena similar a mi problema:
cada vez que se arranca y después de una instantánea, btrfs-transacti y btrfs-cleaner consumirían un núcleo por completo, provocando un retraso inmenso
Solo que esto dice que solo dura unos minutos en el arranque y la creación de instantáneas, pero deshabilité la btrbkconfiguración de mi copia de seguridad en este sistema hace unos días cuando uno de los discos adjuntos comenzó a mostrar problemas.
No estoy seguro de si mi sistema de archivos raíz btrfs estaba usando qgroups, pero lo ejecuté, btrfs quota disable /lo que tomó alrededor de 10 segundos y no proporcionó ningún comentario.
¿Alguien tiene alguna otra pista para mí sobre cómo depurar/resolver este problema?
Respuesta1
El problema eran esas cuotas de btrfs. Correr
btrfs quota disable /
hizo que el sistema fuera utilizable nuevamente :)