Ich habe ein Remote-Linux-System, das gestern super langsam geworden ist. Da die von mir eingerichtete Remote-Luks-Entsperrung nicht zuverlässig zu funktionieren scheint und ich in den nächsten 10 Tagen nicht physisch auf die Maschine zugreifen kann, versuche ich, dies zu debuggen, anstatt neu zu starten.
Die Systemstatus-Tools, die ich gewohnt bin, sind htopund dstatund da ich dstates in einer SSH-Sitzung laufen hatte, kann ich sehen, dass seit gestern, 09.09.2021, 08:51:42 Uhr, ein CPU-Kern immer vollständig von „sys“ genutzt wird – womit wohl der Kernel gemeint ist?
Ich kann keinen verantwortlichen Prozess oder Thread darin sehen htop.
Ich habe alle Benutzerdienste gestoppt und alles ausgehängt, was nicht unbedingt erforderlich ist. Dadurch reagierte das System wieder etwas besser, aber es war noch immer nicht annähernd so schnell, wie es sollte (ich habe eine Intel i7-CPU mit einer SSD).
Ich habe gefundenhttps://tanelpoder.com/posts/hohe-system-load-niedrige-cpu-utilization-unter-linux/und installierte die referenziertehttps://0x.tools/um dieses Ergebnis zu erhalten für 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
Der dpkgVorgang lässt sich so erklären, dass ich versuche, apt upgrademit etwa einem Tausendstel der Geschwindigkeit zu laufen, die man normalerweise erwarten würde (nur ein Gefühl, ich habe es nicht gemessen).
Vielleicht liegt ein Problem mit meinem BTRFS-Root-Dateisystem vor...? Ich kann es nicht finden btrfs-cleaner, htopich denke, ich werde noch ein bisschen weiter recherchieren, was das ist...
Ich habe gestern Abend einen ausgeführt btrfs scrub, der superschnell abgeschlossen wurde und bei dem ich keine Probleme festgestellt habe:
# 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
Aber als ich Nano verwendet habe, um eine Konfigurationsdatei auf der Root-Partition zu ändern, war das Laden und Speichern gerade super langsam.
Ich bin gerade darüber gestolpert:https://www.reddit.com/r/btrfs/comments/fmucrq/btrfs_snapshots_make_entire_system_lag_cpu_usage/der einen Kommentar enthält, der meinem Problem ähnlich klingt:
jedes Mal beim Booten und nach einem Snapshot würden btrfs-transacti und btrfs-cleaner einen Kern vollständig verbrauchen, was zu enormen Verzögerungen führte
hier steht nur, dass das Booten und Erstellen des Snapshots nur ein paar Minuten dauert, aber ich habe mein btrbkBackup-Setup auf diesem System vor ein paar Tagen deaktiviert, als eine der angeschlossenen Festplatten anfing, Probleme zu machen.
Ich bin nicht sicher, ob mein btrfs-Root-Dateisystem verwendet hat qgroups, aber ich habe es einfach ausgeführt btrfs quota disable /, was etwa 10 Sekunden gedauert hat und keine Rückmeldung gegeben hat.
Hat jemand noch andere Tipps für mich, wie ich dieses Problem beheben/lösen kann?
Antwort1
Das Problem, wo diese BTRFS-Kontingente. Laufen
btrfs quota disable /
hat das System wieder nutzbar gemacht :)