Hallo!
Problem in Kurzfassung: Wieso blockieren auf I/O wartende Prozesse das ganze System?
THEORIE: Wait bezeichnet meines Wissens nach den Zustand, dass ein auf einer CPU laufender Prozess auf den Abschluss einer I/O-Operation wartet. Wenn Bedarf besteht kann er die Time Slice abgeben und ein anderer Prozess kann rechnen. Wenn ich also im Hintergrund was kopiere stört mich das beim Arbeiten kaum.
PRAXIS - allgemein: Wenn auf einer CPU ein Prozess in Wait steht, ist sie für weitere Arbeit gesperrt. Wenn man I/O betreibt ist das System in der Zeit nur mehr sehr eingeschränkt nutzbar, die Latenzen stören im Desktop-Einsatz.
PRAXIS - Quad Core und dmcrypt: Wenn ich eine Vielzahl von Dateien (im MB-Bereich) auf eine verschlüsselte Platte kopiere scheint der kryptd mehrere Threads zu erzeugen, die allesamt im Wesentlichen mit Wait beschäftigt sind. Kumuliert belegt der kcryptd nur ca. 70% eines einzelnen Kerns, trotzdem sind durch ihn alle Kerne mit Wait belegt und das normale Arbeiten wird erheblich gestört (Editor, Terminal, Musikplayer, Mailclient reagieren sehr langsam, frieren sogar immer wieder ganz ein).
Wieso führen Threads/Prozesse/Kerne in Wait-State zum Blockieren des ganzen Systems? Liege ich mit obigem Theorie-Abschnitt (was Wait sein sollte) falsch? Welche anderen Ursachen könnte es noch geben?
Eine (entsprechend längere) Mail, wie ich zu meiner Diagnose gelangt bin, schicke ich gleich nach.
Ich bin mit meinem Latein am Ende, will mich aber mit einem sich selbst einfrierenden System auf ordentlicher Hardware nicht zufriedengeben.
Vielen Dank schonmal im voraus & Beste Grüße Fabian
PS: ich entsinne mich noch der Tage, da ich unter auf'm 486 (25 MHz, 8 MB RAM, Linux 1.0) im Hintergrund tars ein- und auspacken konnte, ohne das mich das beim Programmieren unter X gestört hat - das waren noch Zeiten, als man sich wirklich sicher sein konnte, das bessere OS zu haben ;-)
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
On Sat, Mar 27, 2010 at 12:43:44AM +0100, Fabian H?nsel wrote:
Hallo,
Hej Fabian,
meine OS-Vorlesung ist zwar schon etwas her, aber ich vermute das Problem hier ist die Festplatte bzw. der Bus an sich an sich. Nicht nur die Festplatte sondern auch der Bus ist ein Medium welches zwischen den Prozessen aufgeteilt werden muss (jedenfalls das Stück zwischen RAM und IDE/SATA Kontroller). Und wenn dort die kcrypt Threads durch die recht schnelle und intensive Datenübertragung einen Großteil der Bandbreite beanspruchen, werden die weniger häufig aktiven Prozesse evtl. etwas warten müssen, bis sie Daten über den Bus transportieren können.
Firefox schreibt Sicherheitskopien des aktuellen Zustandes zum schnellen Restore, Evolution hat immer etwas zu schreiben, der Musikplayer liest die Musikdaten, Nautilus überwacht das aktuell angezeigte Verzeichnis auf Veränderung etc. Wenn die Prozesse bei diesen Aufgaben nicht gleich Bandbreite auf dem Bus bekommen werden sie natürlich in den WAIT Modus versetzt.
Aber das ist nur eine Vermutung, zur genauen Analyse müsste man wahrscheinlich die IDE/SATA Driver mit Debug-Informationen versehen und Zeiten messen.
Ciao, Tobias
Hej Tobias!
Tobias Koenig skrev:
ich vermute das Problem hier ist die Festplatte bzw. der Bus an sich an sich. Nicht nur die Festplatte sondern auch der Bus ist ein Medium welches zwischen den Prozessen aufgeteilt werden muss
In puncto nominale Busbreiten ist der IDE-Port mit Ultra-DMA 133 das engste Wegstück.
Ich glaube, diese Ursache ausschließen zu können, da die beschriebenen Effekte nicht auftreten, wenn ich die Platte unverschlüsselt verwende. Die Datenübertragungsrate ist dann gleich hoch und es bekommt (fast) nur ein Core Wait-Zeiten angerechnet. Weiterarbeiten ist problemlos möglich, auch Fullscreenflash läuft ohne Ruckler.
Hab mal weiter Ursachen eingegrenzt: Ebenso treten die Probleme _nicht_ auf, wenn ich die Platte mit Twofish oder AES verschlüssele. Dann werden zwar ebenfalls alle Kerne mit Crypto beschäftigt, aber die Wait-Werte bleiben bei 20% (und die Datenrate liegt weiter bei ca. 50 MB/s).
Der Hund muss also entweder irgendwo im Blowfish-Code vergraben liegen oder Blowfish braucht einfach signifikant mehr Rechenleistung (wobei dies noch nicht erklären würde, warum so viel Wait auftaucht).
Firefox schreibt Sicherheitskopien des aktuellen Zustandes zum schnellen Restore, Evolution hat immer etwas zu schreiben, der Musikplayer liest die Musikdaten, Nautilus überwacht das aktuell angezeigte Verzeichnis auf Veränderung etc. Wenn die Prozesse bei diesen Aufgaben nicht gleich Bandbreite auf dem Bus bekommen werden sie natürlich in den WAIT Modus versetzt.
Den Punkt, dass diese Prozesse auf dem Wege indirekt Wait aufgebrummt bekommen könnten, habe ich noch gar nicht bedacht.
Danke & Beste Grüße Fabian
lug-dd@mailman.schlittermann.de
-
Fabian Hänsel -
Tobias Koenig