Hello again,
ich bekomme seit kurzem folgende, unschöne Meldung im vSphere angezeigt:
Device mpx.vmhba1:C0:T0:L0 performance has
deteriorated. I/O latency increased from average
value of 6267 microseconds to 306514
microseconds.
Das verunsichert mich etwas. Dieser Artikel hilft zur Ursachenforschung auch nicht direkt:
http://kb.vmware.com/selfservice/micros ... Id=2007236
Wie gehe ich vor um den Auslöser ausfindig zu machen?
Danke,
Hape
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Warning, Performance has deteriorated
-
mbreidenbach
- Experte
- Beiträge: 1006
- Registriert: 30.10.2004, 12:41
Latenz heißt die Antwortzeit ist langsamer geworden.
Da ist jetzt die Frage - was beschäftigt die Storage so daß sie langsamer antwortet ?
- irgendwas kaputt
- irgendwas macht 'Streß' und verursacht mehr Last als früher
Ich hatte mal ein Fall da haben gleichzeitig alle ESXe Storage Latenz gemeldet und es stellte sich heraus daß gerade größere Testsysteme geklont wurden. Ich habe die Meldung auch schonmal bei Storage vMotion gesehen.
Man müßte halt mal den Zustand des Storagesystems prüfen und schauen was das denn gerade so tut.
Da ist jetzt die Frage - was beschäftigt die Storage so daß sie langsamer antwortet ?
- irgendwas kaputt
- irgendwas macht 'Streß' und verursacht mehr Last als früher
Ich hatte mal ein Fall da haben gleichzeitig alle ESXe Storage Latenz gemeldet und es stellte sich heraus daß gerade größere Testsysteme geklont wurden. Ich habe die Meldung auch schonmal bei Storage vMotion gesehen.
Man müßte halt mal den Zustand des Storagesystems prüfen und schauen was das denn gerade so tut.
-
MarcelMertens
- Member
- Beiträge: 360
- Registriert: 13.07.2011, 15:33
-
Dayworker
- King of the Hill
- Beiträge: 13657
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Schau auf der Adaptec-Seite mal nach CIM-Providern für vSphere5.
Ohne Monitoring würde ich mir sogar den Einsatz eines Raids sparen. Eine akustische Controller-Alarmmeldung ist im RZ ja nutzlos. Das RZ betritt man höchstens mal zur Nachrüstung und ansonsten tut man sich den Geräuschpegel nicht freiwillig an.
Ohne Monitoring würde ich mir sogar den Einsatz eines Raids sparen. Eine akustische Controller-Alarmmeldung ist im RZ ja nutzlos. Das RZ betritt man höchstens mal zur Nachrüstung und ansonsten tut man sich den Geräuschpegel nicht freiwillig an.
Die 5er Serie soll erst ab Februar unterstützt werden....
http://tiny.cc/brdik
Wird es daran liegen mit der Fehlermeldung?
http://tiny.cc/brdik
Wird es daran liegen mit der Fehlermeldung?
Hi,
also am RAID Controller liegt es nicht.
Die Meldung kommt aber weiterhin täglich von 4 Uhr morgens bis ca. 5 Minuten nach 4. Also in 5 Minuten kommt 4-5 Mal die Meldung
Wobei die Zahlenwerte schwanken.
Sehr seltsam, jemand noch eine Idee?
Danke
Hape
also am RAID Controller liegt es nicht.
Die Meldung kommt aber weiterhin täglich von 4 Uhr morgens bis ca. 5 Minuten nach 4. Also in 5 Minuten kommt 4-5 Mal die Meldung
Code: Alles auswählen
Device mpx.vmhba1:C0:T0:L0 performance has
deteriorated. I/O latency increased from average
value of 6267 microseconds to 306514
microseconds.Wobei die Zahlenwerte schwanken.
Sehr seltsam, jemand noch eine Idee?
Danke
Hape
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Hape,
du könntest den Zeitraum entweder mit esxtop oder vScsiStats überwachen.
Außerdem muß das gar nicht zwingend auf ein Problem hinweisen, vielleicht hast du um diese Zeit mit IO Peaks zu tun.
Und je nachdem, wie die IO Zeiten ermittelt werden kommen auch mal solche Werte raus.
Wenn z.B bei einem IO Burst 1000 IO's erzeugt werden und je IO eine Bearbeitungszeit von 3-4ms anfallen, geben einige Monitoring Tools schon mal eine Antwortzeit von 4 sec wieder.
Einfach weil der tausendste IO bis zur Bearbeitung sehr lange warten muß.
Das kannst du dann nur entkräften, wenn du auch noch die IO/sec prüfst.
Wenn nicht wirklich ein Problem vorliegt, hast du In so einem Fall ca. 250-300 IO/sec.
Und dann ist schnell klar, das einer der Werte berechnet wurde und nicht gemessen.
Schau dir einfach mal deine Gast Systeme an, vielleicht werden ja zu dieser Zeit immer Virenscans durchgeführt oder OS Patche installiert.
Zumindest in VMware View Umgebungen sind das immer die ersten Verdächtigen.
Viel Erfolg,
Ralf
du könntest den Zeitraum entweder mit esxtop oder vScsiStats überwachen.
Außerdem muß das gar nicht zwingend auf ein Problem hinweisen, vielleicht hast du um diese Zeit mit IO Peaks zu tun.
Und je nachdem, wie die IO Zeiten ermittelt werden kommen auch mal solche Werte raus.
Wenn z.B bei einem IO Burst 1000 IO's erzeugt werden und je IO eine Bearbeitungszeit von 3-4ms anfallen, geben einige Monitoring Tools schon mal eine Antwortzeit von 4 sec wieder.
Einfach weil der tausendste IO bis zur Bearbeitung sehr lange warten muß.
Das kannst du dann nur entkräften, wenn du auch noch die IO/sec prüfst.
Wenn nicht wirklich ein Problem vorliegt, hast du In so einem Fall ca. 250-300 IO/sec.
Und dann ist schnell klar, das einer der Werte berechnet wurde und nicht gemessen.
Schau dir einfach mal deine Gast Systeme an, vielleicht werden ja zu dieser Zeit immer Virenscans durchgeführt oder OS Patche installiert.
Zumindest in VMware View Umgebungen sind das immer die ersten Verdächtigen.
Viel Erfolg,
Ralf
@Joerg: Sorry, aber was soll mir Deine Antwort bringen?
@Ralf: Vielen Dank, du hast mir die Angst etwas genommen
Vermutlich sind Defragmentierungen und Backups in einem Win-Gast die Ursache...
Wie sieht diese Überwachung genau aus? Kann ich das in der Shell machen?
MfG
Hape
@Ralf: Vielen Dank, du hast mir die Angst etwas genommen
du könntest den Zeitraum entweder mit esxtop oder vScsiStats überwachen.
Wie sieht diese Überwachung genau aus? Kann ich das in der Shell machen?
MfG
Hape
-
irix
- King of the Hill
- Beiträge: 13063
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
hape66 hat geschrieben:@Joerg: Sorry, aber was soll mir Deine Antwort bringen?
Das hab ich mich bei deinem Post gefragt. Somit nochmal "Warum kannst du den RAID Controller ausschliessen?". Bei allen die mit der Meldung hier im Forum aufgeschlagen sind war die Loesung das sie die Batterie fuer ihren Cache, welcher sich beim Schreiben deaktiviert , nachgeruestet haben.
Gruss
Joerg
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Hape,
zuerst einmal kann ich Jörg nur zustimmen, im professionellen Einsatz von VMware sollte die eingesetzte Hardware gewisse Mindestanforderungen erfüllen.
Und ein Batterie gebufferter Adapter gehört definitiv dazu.
Bevor ich den fraglichen Zeitraum aktiv überwache, würde ich mir mal die im vCenter gespeicherten Performance Daten ansehen.
Wenn du aktiv überwachen möchtest, könntest du esxtop über einen cronjob starten.
Gathering esxtop performance data at specific times using crontab
Gruß,
Ralf
zuerst einmal kann ich Jörg nur zustimmen, im professionellen Einsatz von VMware sollte die eingesetzte Hardware gewisse Mindestanforderungen erfüllen.
Und ein Batterie gebufferter Adapter gehört definitiv dazu.
Bevor ich den fraglichen Zeitraum aktiv überwache, würde ich mir mal die im vCenter gespeicherten Performance Daten ansehen.
Wenn du aktiv überwachen möchtest, könntest du esxtop über einen cronjob starten.
Gathering esxtop performance data at specific times using crontab
Gruß,
Ralf
Zurück zu „vSphere 5 / ESXi 5 und 5.1“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 7 Gäste