9.9.2010 von rmo.

Wenn man mit einer oder mehreren VMware-Workstation unter Linux hantiert, ist man froh über einen guten I/O. Gestern hat mich jemand in diesem Zusammenhang auf meine Erfahrungen mit 3ware-Controllern angesprochen.

Pauschal konnte und kann ich darauf nicht antworten - man müsste für eine solide Einschätzung systematische Vergleiche mit anderen Controllern durchführen. Dazu fehlen mir im Moment schlicht die Ressourcen. Es gibt aber interessaante Diskussionen im Internet. Ich empfehle den folgenden Beitrag

http://makarevitch.org/rant/raid/

Siehe auch die dortigen Links mit wirklich interessanten Statements und Erfahrungen zu 3ware-Controllern unter Linux. Hochinteressant finde ich vor allem die Vergleiche mit SW-Raid-Konfigurationen unter Linux, die mich ab und zu doch an meinen Investitionen in HW-Raid für Desktops zweifeln lassen.

Dennoch und aus dem Bauch heraus: Meine Erfahrungen sind im Mittel nicht schlecht, aber gerade mit laufenden VMware-Workstations wird der Platten I/O auf meine Opensuse Kisten bisweilen für kurze Momente zu einem echten, spürbaren Engpass. Zumindest, wenn man sich nicht ein wenig um die (begrenzten) Einstellmöglichkeiten des Controllers und auch des Linux-Systems kümmert.

Aufgefallen ist mir in der Praxis auch, dass auf meinen Opensuse-Systemen mit Quadcore-Prozessoren unter Last irgendwie immer (oder vor allem) der erste Core hohe WAIT I/O-Werte aufweist. Ich gehe mal davon aus, dass die 3ware-Treiber in Kombination mit dem Kernel den Controllerzugriff und den Datentransfer über genau einen Core handhaben. Auch dazu gibt es Hinweise in einschlägigen Diskussionen im Internet.

Der von mir auf den Desktop-Systemen verwendete Controller “9650SE-4LPML” ist ferner nicht ein System, bei dem man die Performance über große Raid-Stapel mit 12 oder 24 Platten hochziehen könnte. Mit 4 Platten sind die Möglichkeiten halt begrenzt.

Also fängt man an, ein wenig herumzuprobieren und vor ein paar Monaten habe ich tatsächlich mal ein wenig Zeit investiert, um mir mit “Bonnie++” verschiedene Konfigurationen anzusehen. Allerdings nur mit EXT3/Ext4 als Filesystem. Wenn ich auf dieser Basis Empfehlungen geben sollte, dann wären es folgende:

1) 4 Platten - Raid 10

2) Wenn man es sich leisten kann : Eher kein LVM einsetzen.

3) Controller-Parameter: Read-Cache auf “Intelligent” setzen und Write-Cache aktivieren (Battery Unit zur Vermeidung von Datenverlusten/Inkonsistenzen einkalkulieren). StorSave auf “Balance” oder “Performance” setzen. Verwendung von “Queuing” (NTQ Feature der Platten, wenn vorhanden) anschalten.
(Zum Einstellen von Controller-Eigenschaften kann man übrigens gut das übersichtliche “3DM2″ benutzen.)

4) Linux-Einstellungen - z.B. für ein Raid-Device, das unter “/dev/sda” anzusprechen ist:

echo “512″ > /sys/block/sda/queue/nr_requests

und danach (!):

blockdev   −−setra 16384 /dev/sda

5) VMware-Workstation (konfiguriert für 2 CPU-Cores eines Quad-Core-Systems):
Zuweisung des “vmware-vmx”-Prozesses an zwei andere Prozessor-Cores als den ersten, auf dem zumeist der I/O kontrolliert wird. Also z.B.:

taskset -pc 2,3 <pid des vmware-vmx-Prozesses>

Testet man die Performance unter diesen Bedingungen etwa mit zwei Raid 1 Units, die bei mir unter Linux als “/dev/sda” und “/dev/sdb” erscheinen, so erhält man mit Bonnie++ recht gute Werte für sequentielles Lesen und Schreiben (ca. 10% unter den theroretischen Maximalwerten der Platten). Aber es lohnt sich, auch andere Parameter-Werte - vor allem für blockdev - unter Linux auszuprobieren. Hier konnte ich durchaus messbare Unterschiede feststellen. Hat man gute Werte gefunden, hinterlegt man sich die Einstellungen in einem kleine Startup-Script. Der Wechsel auf Raid 10 führt dann nochmals zu einer signifikanten Steigerung der I/O-Werte.

Mit unterschiedlichen Schedulern habe ich auch rumgespielt. Irgendwie erschienen mir die Unterschiede aber nicht so signifikant zu sein.

Ich hoffe, ein paar von den Hinweisen helfen auch anderen weiter.

Geschrieben in Hardware, Treiber, Erfahrungsberichte, VMware Workstation | Keine Kommentare »

9.9.2010 von rmo.

Es gibt Dinge, da enden das Verständnis und die Nachvollziehbarkeit. Und man fragt sich, wie der Open Source Betrieb inzwischen eigentlich funktioniert.

Offenbar immer mehr nach dem Motto: Der User ist zu doof …. und deshalb nehmen wir ihm nützliche Dinge weg, weil einige Leute ihre Vorurteile und ihren Einfluss geltend machen.

Bis KDE 4.4 gab es ein nettes ansprechendes Feature in den KDE Systemeinstellungen - nämlich eine hinreichend umfassende Möglichkeit, sich Profile für das “power management” (hier CPU governor) zusammenzuklicken. Eigentlich genau das, was man sich als Normal-User, aber auch als Entwickler so wünscht, wenn man auf einem Desktop oder Laptop unter wechselnden Bedingungen arbeitet und nicht jede Einstellung zum “power management” über die Konsole eingeben will. Eine runde und wie ich finde auch durchdachte Sache rund um HAL und power-devil …

Aber H. mag das nicht … und H. findet anscheinend, dass die Anwender zu blöd sind, die Folgen ihres Tuns abzuschätzen. Also dringt H. darauf, dass ein halbwegs komfortables Tool zur Einstellung des CPU-Frequenzverhaltens und andere Schrauben für das Energieverhalten eines Systems aus KDE entfernt wird. H. weiss: Das ist nix für eine GUI, denn der GUI-Benutzer ist einfach zu dumm. Und weil H. die KDE-Anwender und moderne CPUs kennt, weiss er auch, dass solche Features zu 99,8% überflüssig ist. So ein Laptop weiss schon, wann er sich drosseln muss ….und überhaupt die Energieveschwendung ….und die Wunder einer effizienten “On Demand” Welt ….

Anstatt aber etwas tun, um den “Dummen” die Folgen ihres Handelns z.B. in Hilfetexten oder an Beispielen in der GUI zu erläutern - nein, da nehmen wir ihnen die Möglichkeit was einzustellen lieber gleich ganz weg. Per Patch - und schon sind bewährte Einstellmöglichkeiten, die der User aber sicher ganz falsch verwenden wird, in KDE 4.5 nicht mehr drin. Am besten wäre es allerdings, auch noch die Einstellmöglichkeiten an der Konsole - sprich die “solid-powermanagement”-Optionen zu beschneiden ….. Blöd irgendwie nur, dass das im Patch beabsichtigte reine On/Off-Schalten von Energiespar-Einstellungen für die CPU-Frequenz auch nicht so recht funktioniert ….

An was erinnert mich diese Art der “Argumentation” doch noch? Wie hies doch gleich das System mit der GUI, bei der der User so wenig wie möglich mit Nachdenken belastet werden soll ? Wollte man mit Linux nicht weg von einer solchen Politik?

Die Phantasie von H. reicht offenbar nicht so weit, dass er sich vorstellen kann, dass es KDE-Nutzer gibt, die grafische Oberflächen nicht nur zum Üben von Openoffice auf einem Laptop einsetzen. Dass man z.B. bei Bedarf (und bequem) ein bestimmtes Power-Management-Profile aktivieren möchte, wenn mehrere VMware Workstations auf einer Linux-Workstation zeitweise mit konstanter Frequenz auf unterschiedlichen CPU-Cores laufen sollen und müssen - sowas kommt in in der Welt von H. nicht vor. Und dass man manchmal die Frequenz konstant auf das niedrigst mögliche Niveau setzen will, um die Performance von Programmen für solche Verhältnisse zu testen - neh’ das braucht es in der on demand Welt nicht. Und dass es einen Bedarf für Powermanagement-Profile bei Anwendern mit älteren Laptops geben mag, die sich nicht alle 2 Jahre ein neues Gerät leisten können? Egal …. Und dass man bei manchen Laptops gezielt die niedrigste CPU-Frequenz einstellen mag, weil sonst die Lüfter unter Linux und KDE laufend anspringen? Egal ….

Und selbst wenn - der typische Linux- und KDE-User kann die Folgen seines Klickens auf all die schönen bunten Features auf dem KDE-Schirm ja eh’ nicht einschätzen ….

Hinweisen wollte ich die anderen dummen 0,02% KDE-Mitbenutzer, die die früheren Möglichkeiten zum Einstellen von Powermanagement-Profilen eventuell doch vermissen, noch auf die Möglichkeit von

solid-powermanagement query cpufreq
und
solid-powermanagement set cpufreq <value>

Ich meine für die Zeit, bis H. auch das zum Wohle der Anwender, im Sinne des Fortschritts und einer heilen “on demand” Welt eliminiert hat.

Bliebe noch die Diskussion um die Zukunft von HAL - aber auch in einer Zukunft ohne HAL sollte die Frage, ob und warum man dem User Kontroll-Möglichkeiten entzieht, vielleicht in einem anderen Stil diskutiert und evtl. auch über andere Verfahren zur Entscheidung gebracht werden.

Links

http://forum.kde.org/viewtopic.php?f=22&t=88774&p=167797#p167797
http://kubuntuforums.net/forums/index.php?topic=3113359.0
http://osdir.com/ml/kde-devel/2010-03/msg00055.html

http://dot.kde.org/2007/04/24/road-kde-4-solid-brings-hardware-configuration-and-control-kde?page=1
http://wiki.ubuntuusers.de/Solid
http://en.wikipedia.org/wiki/Solid_%28KDE%29

https://bugzilla.redhat.com/show_bug.cgi?id=550486

http://forum.kde.org/viewtopic.php?f=66&t=31708

Geschrieben in KDE, Erfahrungsberichte | Keine Kommentare »