Nervige Probleme unter KDE 4

Nach einem früheren Beitrag zu KDE 4 möchte ich nun nach ca. 1 Monat produktiver Arbeit unter dieser Oberfläche eine Reihe von Einschränkungen bzgl. des Einsatzes in einem produktiven Umfeld machen. Ich schicke voraus, dass ich KDE 4.1.3 unter Opensuse 11.0 verwende. Das System wird bzgl. KDE 4 auf sehr aktuellem Stand gehalten. Als Graphikkarte kommt einen Nvidia-Karte zum Einsatz. Ich möchte auch betonen, dass ich vorher mit KDE 3.5.10 sehr zufrieden war.

Problembereich Konqueror
Konqueror unter KDE 4 erscheint mir in vielerlei Hinsicht unausgereift. Die nervigsten Punkte, die ein produktives Arbeiten verhindern, sind:

  • Regelmäßige Abstürze bei Multimedia-lastigen Seiten (u.a. mit Flash-Elementen, man gehe nur mal auf die Nvidia-Seiten oder die Seiten der Telekom oder von Vodafone und probiere dort alle Optionen aus),
  • Falsche Behandlung und Darstellung von Seiten mit halb-opaquen Designelementen (wie halbtransparenten Menüpunkten); die Darstellung ist z.T. katastrophal bei dynamischen halbtransparenten Objekten. Man sollte solche Elemente lieber noch eine Weile völlig intransparent darstellen als den experimentellen Murks anzubieten, der im Moment vorhanden ist.
  • Fehler oder Unsauberkeiten in der Javascript-Engine – im Besonderen bei Querbeziehungen zwischen mehreren geöffneten Fenstern einer Applikation (so kann man PhpMyAdmin z.B. wegen dieser Probleme nicht in vollem Umfang benutzen – wahnsinnig nervig)
  • Eine falsche und z.T. chaotische Behandlung von “textarea”-Elementen auf Formularseiten im Zusammenhang mit Mausinteraktionen (falsche Cursordarstellung bei scrollbaren Feldern über dem Scrollbar, falsches Einsprungverhalten bei Maus-Klick auf den Text – vermutlich wg. Fehlberechnung der Scrollposition, etc.) Das macht den Einsatz im Zusammenhang mit formularlastigen Datenbankapplikationen zur Nervensache ….)
  • Falsche Breitenberechnung von Input-Elementen bei der Inhaltsdarstellung – zuminest bei verwendung des Oxygen-Designs für die KDE-Oberfläche – auch dies wieder nervig bei formularlastigen Web-Applikationen

All diese Schwierigkeiten tauchen in anderen Browsern (Firefox, Opera) nicht oder nicht in dem Ausmaß auf wie in KDE4’s Konqueror.

Problembereich CPU-Belastung
Generell erscheint mir die CPU-Belastung im Schnitt deutlich höher zu sein als unter KDE 3.5.10.
Ich muss aber dazu sagen, dass ich Compiz im Einsatz habe und hier spielen evtl. auch die Nvidia-Treiber eine Rolle. Auffällig ist z.B., dass aktive, geöffnete Amarok-Fenster zu einem Anstieg der CPU-Belastung von über 10% führen im Gegensatz zu einer Situation, in der das Amarok-Fenster minimiert ist. Die laufenden Bildschirmupdates kosten unter KDE4 scheinbar erhebliche CPU-Zeit.
Dieses Problem gab es früher auch schon mal unter KDE 3.5, war dann aber eine ganze Weile beseitigt.
Aber auch Applikationen wie das neue Ksysguard sind wahre Ressourcenfresser – reale Messungen der CPU-Belastung sind damit fast nicht mehr möglich, weil Ksysguard oft selbst mehr Ressourcen als andere Applikationen schluckt.

Problembereich GTK-basierte Applikationen (Openoffice, VMware Wokstation, etc. )
Es ist wirklich nervig, dass das Arbeiten in und mit GTK-Applikationen zu störenden Nebeneffekten auf der KDE4-Oberfläche führt – u.a. Überdeckung der KDE4 Kontroll-Leiste durch Artefakte. Diese verschwinden wieder, wenn man die Maus in den gestörten Bildschirmbereich bewegt – ärgerlich ist das aber trotzdem. Zumal durch die Artefakte auch Bereiche überdeckt werden, die Informationen beinhalten.
Ob auch dies mit Nvidia-Treibern zusammenhängt konnte ich nicht prüfen; es hängt aber sicher nicht mit Compiz zusammen, sondern ist ein reines Problem zwischen der KDE-Oberfläche und GTK-
Applikationen. Das haben auch andere bestätigt.

Probleme mit Notizbüchern unter Kontact
Leider muss ich sagen, dass das Arbeiten mit Notizbüchern unter Kontact ein Glücksspiel ist. Mir sind bereits mehrfach Einträge verlorengegangen. Es fehlt eindeutig eine Option zum Zwischenspeichern eines erarbeiteten Eintrags. Notizbücher sind ein schönes Feature, aber leider noch viel zu unsicher für den produktiven Einsatz.

Als Anwender kann man nur hoffen, dass die Konqueror-Probleme und das generelle Problem mit GTK-Applikationen unter KDE 4 umgehend gelöst werden.

3ware Controller Status und Raid Rebuild

Wegen diverser Nachfragen: Hier ein paar kurze Hinweise zur Statusüberprüfung eines 3ware-Raid-Systems unter Linux und Informationen zum Rebuild eines Platten-Arrays, nachdem eine der Platten ausgefallen ist.

Ich beschränke mich nachfolgend auf die Situation eines Raid 1- Verbundes aus 2 gespiegeltem Platten ohne Hot-Swap-Umgebung.

Zunächst ist interessant, wie man überhaupt erkennt, dass ein Problem vorliegt.

Achte bereits beim Booten des Systems auf Störmeldungen

Bzgl. der Statusüberprüfung eines Raid-Systems möchte ich zunächst auf die 3ware BIOS-Meldungen beim Hochfahren eines Systems hinweisen. Dies betrifft vielleicht weniger Server in Dauerbetrieb; es ist aber dennoch ein interessanter Punkt für Arbeitsstationen. Mir ist selbst schon passiert, dass sich mal ein Kabel gelöst hatte und dass eine Platte im Verbund nicht zur Verfügung stand. Merkt man dies bereits beim Hochfahren und bevor neue Daten auf die noch verfügbare Platte des Arrays geschrieben wurden, so umgeht man ein zeitintensives Rebuild des gesamten Systems.

Ein Array wird beim Booten als “Degraded” gemeldet. Was tun ?

Eine Störungsmeldung wird beim Booten rechts neben der Auflistung der vorhandenen 3ware-Raid-Arrays angezeigt.

Ein ausgefallenes und nicht mehr Fault-tolerantes Raid-Array wird in den BIOS-Status-Meldungen es als “Degraded” beschrieben. Die betroffene defekte oder ggf. abgetrennte Platte erhält im Fehlerfall das Attribut “not in use”.

Je nach Bios-Einstellungen stellt der Controller das defekte Array immer noch als “Exportable” für das darauf enthaltene Betriebssystem zur Verfügung. Solange nicht auch die zweite Platte ausfällt, ist das auch kein Problem.

Ist ein Raid-Array nicht in Ordnung, so sollte man als erstes alle Kabelverbindungen prüfen. Gibt sich das Problem dann, so hat man Glück gehabt.

War die Platte jedoch bereits in der vorhergehenden laufenden Sitzung ausgefallen, so ist ein “Rebuild” des Arrays unvermeidbar – weil bereits Daten im nicht gespiegelten Zustand auf die noch verfügbare Platte geschrieben wurden. Die Platten sind dann also in keinem Fall mehr in einem konsistenten Zustand. Geht man mit ‘Alt-3’ in das Bedienungsmenü des Controllers (3ware-Bios-Manger, 3BM), so erhält man auch eine entsprechende Meldung zur Notwendigkeit des “Rebuilds”.

Bei einem “Rebuild” baut der Controller auf einer neu eingebauten Austausch-Platte ( oder auf der alten Platte, falls nur ein Kabeldefekt zum Ausfall führte ) die Spiegelinformationen von Grund auf neu auf – und zwar auf Basis der noch laufenden Platten des Arrays. Das gilt neben Raid 1 auch für Raid5 oder Raid10 – Systeme.

In einem produktiven Umfeld ist es fast unmöglich, sich nach dem Ausfall zuerst um die Ursachen des Plattendefekts im Detail zu kümmern. Ich persönlich nehme in einem solchen Fall lieber gleich eine Austauschplatte, checke und sichere (!) die Kabelverbindungen und untersuche erst im Nachhinein und in Ruhe, ob und welche Schäden die ausgefallene Platte aufweist. Dann kann man immer noch entscheiden, ob man die wieder einsetzen kann und will.

Also, falls kein “Hot-Swap” vorhanden: Rechner runterfahren, Platte austauschen und beim Booten erneut in das 3BM BIOS-Management-Systems des 3ware-Controllers gehen. An den Fehlermeldungen ändert sich durch den Plattenaustausch übrigens nichts. Dann das Rebuild-Verfahren durch Auswahl des Arrays (Pfeiltasten oder Tab-Taste und Enter im 3BM) und Bedienung der entsprechenden Menüpunkte (Button “Maintain Unit” -> “Rebuild”) einleiten. F8 drücken und dann das vorhandene (oder ein anderes; s.u.) Linux-System booten.

Der Rebuild-Vorgang findet nun im Hintergrund des laufenden
Betriebssystems und evtl. über mehrere Stunden hinweg statt.
Hierzu erhält man übrigens in den Hinweis-Texten des 3BM Menüs keine Information – der Prozess beeinträchtigt die Systemperformance u.U. in so geringem Maße, dass man davon fast nichts merkt. Das verwirrt Anfänger regelmäßig und man braucht tatsächlich Zusatztools, um etwas über den Status der Restaurierung zu erfahren.

Sicherungen nicht vergessen

Je nach Umgebung und verfügbaren Tools sollte man in die Reparaturarbeiten eine außerplanmäßige Sicherung einplanen. Ist auch die zweite Platte nicht mehr die jüngste, zählt evtl. jede Minute.

Ich habe aus diesem Grund immer zwei gespiegelte Raid-Systeme am Laufen. Auf beiden steht mir jeweils ein bootfähiges Linux-System zur Verfügung. Um die Schreibbelastung während der Restaurierung auf dem defekten Array so gering wie möglich zu halten, boote ich meist das System auf dem anderen Raid-Verbund und führe eine Sicherung der Partitionen des defekten Arrays durch, die ich der Reihe nach mounte. Sicherung und Restaurierung behindern sich gegenseitig – aber ohne Sicherung finde ich das Risiko nach einem Plattenausfall zu hoch.

Hat man nicht den Luxus eines Ersatz-Operativsystems, so meine ich, dass man noch während der Restaurierung mit der Sicherung unverzichtbarer Daten im laufenden System auf externe Medien beginnen sollte. Hierüber kann man sich aber vielleicht streiten.

Statusinformationen zu den 3ware Raid-Systemen im laufenden Betrieb

Spätestens im Fall der Restaurierung eines Raid-Arrays möchte man über den Stand des Rebuilds im laufenden Betrieb informiert werden.
Aber auch sonst liegt es ja nahe, unter Linux immer mal wieder Informationen zu den Raid-Arrays oder Platten anzufragen. (Bzgl. des “Smart”-Tools zur Überwachung des Zustands einzelner Platten an einem 3ware-Controller siehe einen früheren Blogbeitrag.)

Im laufenden Betrieb kann man mit folgenden Tools von 3ware einen Blick auf den Zustand des Raid-Systems werfen:

  • tw_cli (Command Line Interface)
  • 3DM2 (Daemon mit Java und Browser – Interface)

Beide Tools kann man sich von der 3ware-Website (www.3ware.com) herunterladen und problemlos nach dem Entpacken der Tar-Dateien installieren.

Im Fall von 3DM2 durchläuft man dabei eine Installationsroutine, die die notwendigen Dinge abfragt. Alle notwendigen Informationen zur Installation findet man auf den 3ware Dokumentations-Seiten. Die Tar-Verzeichnisse enthalten zudem umfängliche Info-Dateien im HTML-Format. 3DM2 installiert übrigens auch “tw_cli” mit. Die 3DM2- Installation landet standardmäßig im Verzeichnis “/opt/AMCC“.

Alle Einstellungen von 3DM2 kann man später auch über entsprechende Menüpunkte vornehmen oder verändern.

Zugriff auf 3DM2, Anfangspasswörter und Konfiguration für Benachrichtigungen

Den Zugriff auf die Oberfläche von 3DM2 erhält man bei Standardeinstellungen über einen Browser und die Adresse

https://localhost:888

– also über Port 888.

Hinweis: Die Anfangspasswörter für 3DM2 sind für User und Administrator “3ware”. Die 3DM2 Accounts haben übrigens nichts mit den normalen Linux-User-Accounts zu tun!

Ich habe mir 3DM2 so konfiguriert, dass ich per Mail über Probleme des 3ware-Controllers informiert werde. Dazu beantwortet man am besten schon die entsprechenden Fragen zum entsprechenden Mailserver und zum Mailaccount während der Installation. Später kann man das Benachrichtigungsverhalten unter dem Menüpunkt “3DM2-Settings” einstellen.

So ausgerüstet bekommt man den Ausfall einer Platte in einem Raid-Verbund im laufenden Betrieb automatisch mit.

Informationen
zu den 3ware-Raidsystemen mit tw_cli

Mit tw_cli kann man sich als root praktisch alle Statusinformationen zum Raidverbund anzeigen lassen und Maintenance-Maßnahmen einleiten.

Nach dem Starten von tw_cli landet man an einem eigenen Prompt. Dort lässt man sich zunächst mit “show” die Kurzbezeichnung “cX” des Controllers anzeigen und erhält anschließend mit

“/cX show”, in meinem Fall mit “/c6 show”

mehr Informationen. “X” steht dabei für die Nummer – in meinem Fall eine 6.

tw_cli

U.a. erhält man hier Informationen zum Status eines “Rebuild-Prozesses”.

Erste Informationen mit 3DM2

Unter 3DM2 sieht die Statusinformation wie folgt aus

3dm2

Hier habe ich die Seite “Management->Maintenance” aufgerufen. Man erkennt auch hier den aktuellen Stand eines “Rebuild-Prozesses”.

Für weitere Informationen und mögliche Kommandos zu beiden Tools sei auf die umfängliche Information verwiesen, die unter “/opt/AMCC/Documentation” mit installiert wird.

Plattenausfall im laufenden Betrieb

Das Vorgehen nach einem Plattenausfall im laufenden Betrieb ist übrigens das gleiche wie oben beschrieben: Hat man kein “Hot-Swap” so muss man das System ordentlich herunterfahren, Platte austauschen und den Rebuild nach dem erneuten Booten über 3BM oder die anderen Tools (3DM2 und tw_cli) starten.

Ksysguard, harddisks und diskstats

Gestern bekam ich von Michael die Frage, wie man denn unter Linux für die “kryptischen” Plattenbezeichnungen in Ksysguard die zugehörigen Partitionen herausfinden könne. Er hatte ein Performance-Problem und wollte sehen, auf welche Platte bzw. Partition das System besonders häufig schreibend zugreift.

Mit “kryptischen” Plattenbezeichnungen waren etwa nachfolgende Einträge im Sensor-Bereich von Ksysguard unter dem Punkt Festplattendurchsatz gemeint :

Ksysguard – Ausschnitt aus dem Sensor-Browser

Festplattendurchsatz

+ 2:0 + 7:0 … … + 7:7 + 8:0 + 8:1 … … + 8:28 + 11:0 + 11:1 (s. Abbdg.)

kys_600

Nun, hinter den Nummern verbergen sich die “major” und “minor” device numbers. Dieses Wissen allein hilft aber auch nicht direkt weiter. Wichtig war Michael ja die Zuordnung dieser Device-Nummern zu den Plattenpartitionen. Letzere sind dem Administrator natürlich besser geläufig.

Auf einem meiner Systeme gibt es z.B. 11 reguläre Linux-Partitionen (Ext3 und ReiserFS) und 3 NTFS-Partitionen in relativ harmonischer Eintracht. Auf die NTFS-Partitionen wird u.a. von VMware-Instanzen aus zugegriffen. Ist man auf einem solchen System an einer partitionsspezifischen Beobachtung des Plattendurchsatzes interessiert, muss man bei Ksysguard schon wissen, wohin genau man schauen sollte.

Zusatz-Informationen aus dem /proc-FS : /proc/diskstats

Woher bekomme ich nun also die Informationen zum Zusammenhang zwischen “device number” und Partition?

Antwort: Aus dem Kernel, oder besser dem /proc – File-System. Moderne Kernel schreiben nämlich statistische Werte für den Plattendurchsatz mit. (Solche Werte werden z.B. von “sar” ausgewertet.) Harddisk-relevante Informationen findet man unter “/proc/diskstats”.

Nachfolgend ein typischer Auszug des Ergebnisses von “cat diskstats” oder “cat /proc/diskstats”:

user@machine:/proc> cat diskstats
8 0 sda 354415 43112 7631712 3704336 269025 782582 8477712 65951972 0 2135876 69736240
8 1 sda1 784 799 0 0
8 2 sda2 4 8 0 0
8 5 sda5 84 520 0 0
8 6 sda6 515 4114 21 168
8 7 sda7 4225 101288 6085 48624
8 8 sda8 826 841 0 0
8 9 sda9 384 778 0 0
8 10 sda10 390174 7518090 1046963 8375680
8 16 sdb 98498 45267 3730694 1115992 194344 559016 6057920 8996952 0 1112700 10123120
8 17 sdb1 2111 2622 0 0
8 18 sdb2 4 8 0 0
8 21 sdb5 36929 293990 72507 580056
8 22 sdb6 384 778 0 0
8 23 sdb7 1078 1093 0 0
8 24 sdb8 436 780 9 16
8 25 sdb9 814 3450 3 16
8 26 sdb10 1877 2374 0 0
8 27 sdb11 95005 3414382 682211 5457664
8 28 sdb12 4309 5184 0 0

Und nun eine Beschreibung der Felder (die ich übrigens großteils dem ersten unten angegebenen Link entnommen habe):

Feld 1 — major device number
Feld 2 — minor device number
Feld 3 — device name (partition)
Feld 4 — # of reads issued
Feld 5 — # of reads merged,
Feld 6 — # of sectors read
Feld 7 — # of milliseconds spent reading
Feld 8 — # of writes completed
Feld 9 — # of writes merged
Feld 10 — # of sectors written
Feld 11 — # of milliseconds spent writing
Feld 12 — # of I/Os currently in progress
Feld 13 — # of milliseconds spent doing I/Os
Feld 14 — weighted # of milliseconds spent doing I/Os

Man sieht:
Hier ist eine Menge Information enthalten – im besonderen eben auch die Zuordnung der Device-Nummern zu den Partitionen.

Datenaufbereitung in Ksysguard

Das Schöne ist, dass Ksysguard einen Teil dieser Informationen in netter Weise aufbereitet. Im besonderen wird einem die Umrechnung in Bytes/s abgenommen. Man kann nun gezielt Ksysguard-Datenblätter für die Parttionen anlegen, die einen besonders interessieren (s. die Abbildung). Zusammenfassende Informationen liefert übrigens auch das Tool “gkrellm”.

Viel Spaß beim Analysieren des Plattenzugriffs !

gkrellm_1

Links

http://ubuntuforums.org/showthread.php?t=31213
http://www.meinews.net/festplattenbenutzung-t17640.html
http://utcc.utoronto.ca/~cks/space/blog/linux/DiskIOStats
http://en.opensuse.org/Monitor_your_hard_disk_activity_with_KSysGuard

Generell zum “procfs”:
http://en.wikipedia.org/wiki/Procfs