Hallo,
hier die ausführlichere Diagnose, aus der ich Schlussfolgere, dass mehrere Threads im Wait State das ganze System blockieren.
Ich habe eine Platte mittels dm-crypt verschlüsselt. I/O-Operationen auf die verschlüsselte Platte legen dabei das System trotz reicher HW-Ausstattung lahm. (Das OS mit home und allem drum und dran liegt auf einer nichtverschlüsselten Platte.) Ich versuche mittels Monitoring die Ursache zu ermitteln.
Problem: wenn ich "große" Datenmengen (mehrere GB große Einzeldateien oder tausende Dateien im MB-Bereich) auf die verschlüsselte Platte schiebe, wird das System sehr, sehr zäh. (Beim Lesen das gleiche)
Symtome: immer wieder frieren Firefox, Evolution, Musikplayer, Nautilus und manchmal sogar das Gnome-Terminal während des Kopierens ein (tauen nach mal 1s, mal 10s, mal 30s wieder auf). Der Wechsel des virtuellen Desktops dauert; Verschieben von Fenstern ist sehr zäh. Nach Allerweltsoperationen wie dem Anklicken eines Menüs in beliebigen Anwendungen gibt es eine sehr merkbare Verzögerung, bis das Menu ausgeklappt wird. Die meiste Zeit fühlt sich das System damit "nur" sehr langsam an, manchmal ist Weiterarbeiten kurzfristig nicht möglich.
Systemausstattung: - Ubuntu 9.10 AMD64, Kernel 2.6.31-20-generic #58-Ubuntu SMP, Dateisystem auf den betroffenen Partitionen XFS - Phenom II 905e, Quad Core, 4 x 2.5 GHz - 4 GB RAM - Quell-HD: - Seagate 2,5", 250 GB, SATA - schreiben ca. 100 MB/s - Ziel-HD: - Seagate 3,5", 400 GB, EIDE - schreiben ca. 50 MB/s
Crypto: Blowfish
Monitoring: - CPU: in top taucht der kcryptd mit ca. 70% CPU-Nutzung _eines_ Kerns auf - RAM: Ermittelt via free. 3961 MB existent, 3530 MB used, ohne buffers 2504 MB [Oh Gott! Es ist ein Gnome-Desktop mit paar Anwendungen geladen und sonst nix - aber das ist ein anderes Thema], 400 MB Swap sind in Gebrauch - dmesg/syslog: nichts
Jetzt wird's interessant: - vmstat weist hohe Wait-Zahlen für das Gesamtsystem aus, ich schaue mir das in mpstat an. [in Klammern Vermutungen von mir]
Wenn ich nur eine große Datei kopiere ist es ein Kern, der ausgelastet wird - nur der Kern bekommt Wait angerechnet. Man merkt vom Kopieren nix.
Wenn sonst nochwas auf dem System abläuft bekommen mehrere Kerne Wait aufgebrummt. Man merkt leicht, dass da was los ist. [der kcryptd wechselt dann eben auch mal den Kern]
Wenn viele kleinere Dateien kopiert werden, wird es prekär: Dann bekommen alle vier Kerne auf Wait-Zahlen bis 98%. Selbst leichtgewichtige Anwendungen wie das Terminal frieren nun immer wieder ein. [Der kcryptd erzeugt Threads. Obwohl er nicht mal einen Kern auslastet (HD dafür zu langsam), versucht er, die Verschlüsselung parallel ablaufen zu lassen, um schneller zu werden. Damit steht der kcryptd unverändert mit rund 70% auf einem Core im top, aber er besteht aus vier Threads, die jeweils knapp 20% auf je einem Core mit crypto auslasten (könnte mir ja egal sein), ABER: sie crypten nicht nur auf jedem Core, sie warten auch dort und blockieren damit das ganze System]
Wie seht ihr diese Vermutung? Kennt ihr Methoden, mit denen man diese besser belegen könnte?
Vielen Dank im Voraus & Beste Grüße Fabian