PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Ursachenforschung: IO blockiert



Dellerium
26.05.08, 08:58
Hallo,

ich hatte am Wochende ein "kleines" Problem. Das habe ich zwar lösen können - allerdings gefiel mir die Lösung nicht wirklich. Daher mal eine Frage in die Runde wie man das in Zukunft (was hoffentlich nicht der Fall sein wird) besser lösen könnte.

Ich habe hier einen Datenbank Server. Zum Einsatz kommt PostgreSQL 8.2.5. Eben jener Server wollte am Wochende nicht mehr so wie er sollte. Das DBMS lief zwar noch und lies sich auch ansprechen (shell tools), allerdings war der Zugriff auf die eigentliche Datenbank blockiert. Ein schneller Blick mit ps aux und top förderte zu Tage, das sämtliche Prozesse auf IO warteten(so ~50, was auch den hohen Load erklärte ;)). Top zeigte dann auch, dass einer der Prozessoren zu 100% mit IO beschäftigt war. Allerdings wurden, wie vmstat dann zeigte, keinerlei Blöcke über das betreffende Device ausgetauscht.

Als nächste wollte ich dann ausschliessen, dass die Partition ausgestiegen ist. Also das Dateisystem angesehen - das funktioniert noch. Offene Dateien via lsof anzeigen lassen ging dann nicht mehr - lsof hing und wartete fortan ebenfalls auf IO wie ps aux auf der anderen Shell zeigte. Ein neuerliches ls auf dem betreffenden Dateisystem ging nach dieser Aktion ebenfalls nicht mehr.

Da sich keiner der Prozesse abschiessen lies - zuerst sanft und danach mit kill -9 blieb mir im Endeffekt keine andere Wahl, als den Server hart auszuknipsen. Denn Beenden lies sich die DB nicht und damit konnte auch der Server nicht heruntergefahren werden. :mad:

dmesg und auch die sonstigen Logfiles lieferten keinerlei Einträge die auf irgendwelche Probleme hindeuten. An der Hardware liegt es nicht. Neben das DB liegen auf dem SAN weitere Partitionen - alle liessen sich Problemlos ansprechen.
Im Augenblick vermute ich eine Art Deadlock auf Dateisystem Ebene - das ist allerdings auch nur geraten....

Jemand von auch nen Tip oder ne Idee?

Gruß Dellerium

marce
26.05.08, 09:34
In solchen Fällen hilft manchmal nur Monitoring aller relevanten Daten - und hoffen, daß man das Verhalten reproduzieren kann. Dann nach und nach den oder das Schuldige(n) eingrenzen.

Wenn man dann eine "schuldige Aktion" gefunden hat - evtl. noch über strace, Auditd, ... weiter suchen...

bla!zilla
26.05.08, 09:46
Tja, jetzt lässt sich der Fehler natürlich schlecht nachvollziehen. Ich tippe auf ein Problem mit der DB, nicht mit der Partition oder dem Storagesystem. Ist natürlich auch nur geraten. Da kannst du jetzt nur noch Logs sichten und hoffen etwas zu finden.

Dellerium
26.05.08, 12:23
@bla!zilla

Logs haben wir soweit schon gesichtet - schon während der Server (bzw. die Datenbank) stand. Zu diesem Zeitpunkt war es wichtiger, die Ursache zu finden als den Server sofort wieder flott zu bekommen - da das Problem abends aufgetreten ist und kaum noch jemand darauf gearbeitet hat, haben wir uns dazu entschlossen erstmal nach der Ursache zu fahnden um das Problem auch für die Zukunft zu beseitigen. Allerdings konnten uns die Logdateien keine Fehlermeldungen liefern. Bis auf die Tatsache, dass die DB Prozesse in einem nicht unterbrechbaren IO standen waren keine Informationen zu finden.

Interessant war aber, dass auch Datenbank Prozesse betroffen waren, die im State idle standen... Im Prinzip hatte sich die komplette DB festgefahren. Das hätte ich auf PostgreSQL geschoben, was mich dann aber wunderte, war die Tatsache, dass auch lsof und am Ende sogar ein einfaches ls blockierte... Selbst nach dem Kappen der SSH Verbindung blieb der Prozess in der Prozesstabelle zurück, weil alle Prozesse als Status "nicht unterbrechbarer IO" besaßen.
Wäre natürlich möglich, dass PostgreSQL da irgendwas auf der Partition blockiert hat und lsof und ls deshalb ebenfalls warten mussten...

@marce

Im Prinzip loggen wir schon so ziemlich alles was wir loggen können (auf Systemebene) - noch mehr liesse sich nur vom DBMS loggen (z.B. alle SQL Statements). Das ist aber nicht drin, weil die Maschine schon nahe des Limits läuft... Und was das Controlling zu neuer Hardware sagt... :rolleyes: Ich wüsste schon, wo man noch rationalisieren könnte ohne das es der Firma weh tut ...

Das Problem zu reproduzieren dürfte nahezu unmöglich sein. Insofern habe ich keine große Hoffnung, dass wir rausbekommen, was da exakt passiert ist :(

bla!zilla
26.05.08, 13:14
Bootet die Maschine von dem Storage? Hast du den ls, der sich festgefressen hat, auf einer Partition auf den lokalen Platten, oder einer LUN vom Storagesystem losgelassen?

Dellerium
26.05.08, 13:26
Die Maschine bootet von lokalen Platten. Das Storage (SCSI Anbindung) hält nur Datenbank + Applikation vor. (ServiceGuard ist dir ja ein Begriff ;))

Das ls hab ich auf der LUN losgelassen auf der die Datenbank Logs liegen. Genau diese LUN war nicht mehr ansprechbar nachdem ich lsof gestartet hatte. Vorher konnte ich mich auf der LUN noch normal durch die Verzeichnisse bewegen und mir den Inhalt der Verzeichnisse anzeigen lassen. In den Logfiles oder dmesg war unterdessen nicht zu finden.

bla!zilla
26.05.08, 13:36
Okay, was für ein Dateisystem nutzt ihr für die LUN und was für Storage hängt dahinter? Ich hatte mal lustige Effekte mit ext3 und einer MSA1500, wo einzelne LUNs sporadisch auf einmal read-only waren. Nach einem Neustart war wieder alles cool.

Dellerium
03.06.08, 07:39
Ist eine MSA500 mit xfs als Filesystem.

Hast du die Ursache für das Problem im Zusammenhang mit ext3 finden können?

bla!zilla
03.06.08, 15:42
Nein, nach dem Update auf die aktuelle Firmware 7.00 war der Fehler verschwunden.