Änderung des Beitrags am 07.06.2009:
Der nachfolgende Beitrag hat sich inzwischen in wesentlichen Punkten als haltlos entpuppt:
Ursache der Abstürze ist eindeutig ein fehlerhafter Speicherbaustein – also ein Hardware-Fehler in der betroffenen Maschine. Die unten beschriebene Verringerung des Swap-Bereiches hatte evtl. trotzdem positive Wirkung, als die Wahrscheinlichkeit, den defekten Speicherbereich zu treffen möglicherweise verringert wurde.
Es bleibt als Befund lediglich der fühlbare Geschwindigkeitsunterschied bei der Verringerung des SWAP-Bereiches und die Erkenntnis, das man bei statistisch auftretenden Fehlern der Klasse “General Protection Fault” zunächst mal den RAM auf Funktionstüchtigkeit prüfen sollte, bevor man sich in Spekulationen verliert.
********************************************
Alter Beitrag
Am letzten Wochenende musste ich mit einem Problem auseinandersetzen, dessen Ursache letztlich wohl im SWAP-Bereich lag. Das Ganze ist aber irgendwie komisch und deshalb aus meiner Sicht einen Blog-Beitrag wert. Zumal ich im Internet gefunden habe, das auch andere Leute mit verschiedenen Kernelversionen unter Opensuse 11.1 unregelmäßige Abstürze erlebt haben.
Ich hatte ein neues System mit 8GB DDR3-RAM und einem Intel Quadcore Q9550 Prozessor aufgesetzt (Opensuse 11.1 – x86_64). Das ist gleichzeitig die RAM-Grenze des Mainboards. Das System hat vier 1TB Platten in 2 Raid-1-Arrays. Da auf diesem System i.d.R. 2 VMware-Maschinen mit je 2GB Hauptspeicher und ein Samba-Server sowie Datenbank-Server laufen sollen, ist die Kalkulation des SWAP-Speichers nicht ganz einfach – zumal man hierzu im Internet durchaus unterschiedliche Philosophien finden kann.
Ich hatte auf der einen Partition eine SWAP-Partition von 4GB eingerichtet, auf der anderen einen Bereich von 8GB – letzteres nur testweise. Mein Motiv war, einfach mal auszuprobieren, ob im Alltag überhaupt Unterschiede feststellbar wären. (Generell glaube ich, dass bei 8GB Hauptspeicher selbst 4GB Swap völlig überdimensioniert sind, da ausgelagerte Bereiche komprimiert werden. In der Praxis zeigte sich, dass der Swap-Bereich lediglich beim parallelen Handtieren mit mehreren großen Dateioperationen eine Rolle spielte).
Egal:Zuletzt hatte ich den 8GB Swap Bereich mit “swapon” aktiv auf swap eingehängt. Im Zuge diverser anderer Ereignisse hatte ich dies aber vergessen und danach die Maschine mit dieser Einstellung produktiv benutzt.
Dann kam es zu unregelmäßigen, nicht nachvollziehbaren Abstürzen oder einem Einfrieren des ganzen Systems. Dies war für mich insofern erschütternd, als mir alle wesentlichen Einstellungen identisch mit einer fast gleich konfigurierten Maschine erschienen, die sich seit Wochen fehlerfrei im Dauerbetrieb befindet. Die Abstürze geschahen vor allem dann, wenn ich viele Dateien kopierte – ob unter VMware oder unter Linux.
Nach einer Beobachtung und Auswertung von /var/log/messages kam ich dann dahinter, dass die meisten der Abstürze an einen “General Protection Fault” gebunden waren. Dies versetzte mich bereits in gehörige Unruhe.
Als nächstes tauchten bei der Installation eines Programmpaktes plötzlich Meldungen auf, dass das System auf illegale Speicherbereiche jenseits der Parttionsgrenzen zugreifen wolle. Nun dachte ich an Speicherfehler – und ließ memcheck mal über mehrere Stunden laufen – ohne Fehlermeldungen.
Noch schlimmer wurde es, als ich danach einen systematischen Test der mehr als 10 Partitionen des Systems mit fsck durchführte – Fehler über Fehler trotz Recovery Journal des Ext3-Systems. Hier rächte sich übrigens die Aktivierung des Write-Cachings auf dem Raid Controller bitter. Der hat mehrere hundert MByte Caching Speicher. Bei den festgestellten Abstürzen findet hier kein sync des Writecaches mehr auf die Platten statt – das Filesystem kann deshalb nach dem Hochfahren auch über das Journaling Fehler ggf. nicht mehr ausbügeln – und man
merkt es nicht einmal !
Merke: Nach Abstürzen und aktiviertem Write-Caching trotzdem fsck-Prüfungen fahren !
Nun erklärt das aber nicht die Ursache der Abstürze – es macht höchstens ein systematisches Anwachsen der Filesystem-Probleme plausibel, wenn fsck nicht angewendet wird. Ich bereinigte also die Filesysteme über “fsck -f” . Danach prüfte ich alles Mögliche und verglich die Konfiguration meiner Maschinen – ergebnislos.Ich installierte einen älteren Kernel, deinstallierte überflüssige Pakete – alles vergebliche Mühe.
Durch Kopieren großer Dateimengen konnte ich den Fehler inzwischen systematisch provozieren. Und irgendwannmal gelang es mir nach einem Protection fault die Maschine noch weitgehend geordnet herunterzufahren. Dabei fiel mir auf, dass die Swap-Partiton nicht mehr freigegeben werden konnte. Nun erinnerte ich mich wieder an meine eigentlich “testweisen” SWAP-Einstellungen und aktivierte die kleinere SWAP-Partition statt der großen. 4GB SWAP waren übrigens auch auf dem Vergleichsystem eingestellt !
Und siehe da, das System lief danach
1. fehlerfrei
2. deutlich schneller als zuvor.
Kann Opensuse 11.1 mit dem aktuellen Kerne 2.6.27 nun einfach nicht mit 8GB SWAP arbeiten ? Ich weiss es nicht – komisch ist die Sache schon.
Interessant ist auch, dass der “testweise” Swap-Bereich minimal gößer als 8GB war. Zusammen mit den 8GB Ram wurde also evtl. ein irgendwo existierendes 16GB-Limit überschritten.
Der Kernel ist übrigens der aktuell für Opensuse 11.1 im Update Repository angebotene 2.6.27.21-0.1-default #1 SMP x86_64 .
Wenn einer eine Idee dazu hat, was hier los war, möge er mich informieren !