IOWait näher untersuchen

[merz]

Hi @all,

ich betreue bei einem Kunden mehrere debian Instanzen unter VMware ESX. Speicher bekommen diese Instanzen per NFS von einigen
NetApp Filern. Die debian Instanzen hosten einen WebServer, wobei ich leider keinen tieferen Einblick bekommen kann. Jetzt zeigen
einige Instanzen seit einiger Zeit stellenweise sehr hohe IOwait Werte (80-90%). Dies kann ich mir nicht erklären, da die CPUs ansonsten
geringe Last zeigen. Auch die Latenzzeiten auf den Storagesystemen zeigen keine Auffälligkeiten.
Nun meine Frage: Gibt es eine Möglichkeit, nachzuvollziehen, welche Prozesse diese hohen IOwait Werte verursachen ? Eine Art CPU
Auslastung pro Prozess. Wichtig wäre es für uns in einem ersten Schritt eine grobe Richtung zu herauszubekommen, ob es sich also
um einen lokalen Prozess handelt, eine Applikation oder einen NFS Zugriff ...

Ich hoffe Ihr könnt mir helfen ... Danke im Vorraus ... Frank ...

[gms]

da gibts zumindest zwei Tools die das können: atop und Systemtap. Beide sind sehr mächtig, atop braucht jedoch einen Kernelpatch und Systemtap hat noch eine fürchterliche Usability und braucht ( glaube ich ) einen 2.6.24 er Kernel
dann gibt es auch noch ein sehr leicht zu bedienendes Python Script "iotop.py", welches nur Python >2.5 und ein Kernel ab 2.6.20 benötigt:
http://www.jebriggs.com/blog/tech/linux-iotop.html

Gruß
gms

edit: den Namen vom Python-Script ausgebessert auf "iotop.py" ( "iostat.py" war falsch )

[thorben]

moin,
welchen i/o scheduler setzt du ein?

gruß
thorben

[ckoepp]

Das Verhalten tritt bei uns auf dem ESX-Server auch ab und an mal auf - schreib bitte wenn du Details herausgefunden hast. Würde mich auch interessieren.
Danke!

[thorben]

moin,
ich habe den tip bekommen, den ioscheduler auf deadline oder noop(?) zu stellen, weil es keinen sinn macht io zu optimieren wenn man vmfs und vielleicht noch n halbes gig cache vom raidcontroller dazwischen hat.

ich habs aber noch nicht probiert, da wir erst in der evaluierungsphase sind.

gruß
thorben

[merz]

Hallo zusammen,

erstmal Danke für eure Antworten, hier nun wieder meine Comments dazu:

@thorben: danke für den Tipp, werd mal in die Richtung suchen. Welcher I/O Scheduler hier eingesetzt wird kann ich dir leider im Moment noch nicht sagen, hab ich aber erfragt *waitin-for-response*

@gms: Hab mir die beiden Tools mal angeschaut. Soweit ich das verstanden habe, würde uns atop nicht helfen, da wir zwar eine Aufteilung von syscpu und usrcpu pro Prozess bekommen, aber eben halt leider kein iowait oder wa pro Prozess. Ausserdem scheinen beide Tools einen höheren Kernel zu benötigen als derzeit im Einsatz.

Noch jemand weitere Ideen in welche Richtung man suchen sollte ? Ich hab erste NMON Ergebnisse der Maschinen bekommen, wobei mich die Ergebnisse überhaupt nicht weiterbringen. CPU Last ist sehr gering, keinerlei IOWaits sind aufgetreten. Ich vermute, dass wir hier seltene aber dann hohe IOWaits haben, die uns bei den Messungen im NMON durch die Lappen gegangen sind ...
Habt ihr vieleicht spezielle Werte für mich, die ich mir in den NMON Analysen anschauen sollte, um ein Performanceproblem zu erkennen oder sogar eingrenzen zu können ? Anhand der Werte im NMON wie ich sie verstehe würde ich derzeit davon ausgehen, dass die Maschine keinerlei Probleme hat und noch dazu absolut oversized ist.

Danke für eure Hilfe ...

[gms]

Soweit ich das verstanden habe, würde uns atop nicht helfen, da wir zwar eine Aufteilung von syscpu und usrcpu pro Prozess bekommen, aber eben halt leider kein iowait oder wa pro Prozess.

mit dem Kernelpatch würdest du den Disk I/O und die Netzwerkaktivität pro Prozeß bekommen. Einen "iowait" pro Prozeß wird dir aus technischen Gründen kein Tool dieser Welt liefern können, aber wenn du zum Zeitpunkt eines hohen iowaits auf obige Prozeßliste schaust, bekommst du die Verursacher des hohen iowaits

Ausserdem scheinen beide Tools einen höheren Kernel zu benötigen als derzeit im Einsatz.

welcher Kernel ist denn im Einsatz ?

[merz]

Hi zusammen,

danke zuerst für eure vielen Antworten.

@gms: Ich werde nochmal im Detail prüfen, ob wir atop hier einsetzen können, aktuell ist hier der Kernel 2.6.19 im Einsatz.

@thorben: Laut Aussage des Admin ist der I/O Scheduler hier ausser Betrieb (elevator=noop)

Für weitere Hinweise bin ich sehr dankbar, ansonsten muss ich jetzt erstmal hoffen, dass wir den Einsatz von atop durchsetzen können und hier wie von gms beschrieben einen Hinweis auf den Übeltäter bekommen ...

Danke an alle ...

P.S. Ich werde euch natürlich im Fall einer Problemlösung informieren

[gms]

Für weitere Hinweise bin ich sehr dankbar

mit Spekulationen rücke ich zwar ungern raus, aber gerade im Zusammenhang von Web- bzw Applicationservern, wenn dort vielleicht noch ein Datenbank-Server im Spiel ist, habe ich oft die Erfahrung machen müssen, daß eine ungeschickt formulierte Abfrage zu solchen unerwartet hohen IO Aktivitäten führt.
Dabei muß man natürlich auch berücksichtigen, daß der Datenbank-Client ( in diesem Fall der Webserver-Prozeß ) , oft nur eine kleine Teilmenge von den Daten bekommt, die der Datenbank-Server für diese Abfrage verwurschteln muß. In einem Trace scheint dann natürlich der falsche Patient auf und auf den tatsächlichen Verursacher, die Webanwendung, kann dann nur indirekt geschlossen werden.
Langer Rede kurzer Sinn, bevor ich großartig zum Tracen anfange, schau ich mir einmal an, was hat sich webserverseitig ( und auch sonst, z.B Backup, usw.. ) zu den Zeiten mit den hohen IO-Waits getan, oft genügt das schon.

Gruß
gms