Performance bricht nach 1 bis 2 Wochen massiv ein

[schroem]

Hallo zusammen,

hier erstmal grob meine Konfiguration:

- Dell PowerEdge R900
- 4x3Ghz CPUs
- 64GB RAM
- Datastore liegt auf den internen Platten (Raid 5 mit 4 Platten + 1 hotspare)
- ESXi 4.1

Vorab: Die Kiste habe ich nur vorrübergehend im Einsatz(hatte ich noch rumstehen), da mir 2 physikalische Server um die Ohren geflogen sind. Diese sind jetzt virtualisiert.

Mein Problem: Es läuft alles wunderbar, doch nach ca. 1 - 2 Wochen bricht die Performance derart ein. Der Zugriff auf den Datastore ist sehr langsam. Die CPUs langweilen sich. Ein Arbeiten ist fast unmöglich.
Starte ich den ESX neu läuft wieder alles wunderbar. In den logs steht nichts besonderes, daher keine Fehler/Komplikationen oder Ähnliches. Auf allen Partitionen ist genügend freier Speicher, hier sollte also auch nichts voll laufen.

Hat jemand eine Idee?


Gruß

[deathrow]

Evtl. zu wenig RAM für die Konsole?

Geh mal Konfiguration->Zuteilen von Systemressourcen.

Gib ihm mal so 800MB RAM und starte neu.

[schroem]

Meinst du hier die Anteile oder Reservierung hoch schrauben? Bislang ist hier die Standardeinstellung aktiv. Anteile 500 ; Reservierung 0MB

[deathrow]

Mach mal die Reservierung auf 800MB

[schroem]

ok, danke für den Tipp. Werde ich heute Abend mal einstellen und die Kiste neu starten sobald keiner mehr arbeitet.

[schroem]

Ist nun konfiguriert und neu gestartet. Jetzt heißt es wohl abwarten...

[schroem]

gleiches Problem wieder...total langsam alles. Bin noch am verzweifeln.

[kastlr]

Hallo,

bist du sicher, das der Zugriff auf den Datenstore das Problem ist?
Wie verhält sich denn die Performance, wenn du die VM's einfach mal durchstartest?

Hast du mit esxtop mal die Werte überprüft, wenn das System so langsam ist?
Using esxtop to identify storage performance issues
I/O Statistics in vSphere 4.1

Vielleicht liegt das Problem ja an einer ganz anderen Stelle.

Gruß
Ralf

[irix]

Also wenn es Langsam ist dann gibt es primaer 2 Sachen

1. Speicher bzw. Limits für die VM
2. Disk Latency/IOPS

Das erste bekommt man mit den Stats bzw. esxtop sehr schnell heraus und das andere sollte ja eigentlich von Anfang an auftreten und nicht erst nach 2 Wochen, sofern alle VMs gleich gestartet sind.

Gruss
Joerg

[PeterDA]

Hi,
mal so ganz Profan, weil ich das mal hatte: Snapshots sind keine auf den VMs. Hatte mal das gleiche Problem. Es stellte sich dann heraus, dass wir vergessen hatten nach einem Update einen Snapshot zu löschen...

Gruß Peter

[schroem]

Vielen Dank erstmal für die Tipps. Werde das mit esxtop mal überprüfen wenn es wieder mal langsam ist. Im Moment läuft alles deshalb kann ich noch keine Aussage machen.
Wegen der Statistik, das geht ja glaube ich nur über vCenter Server. Ich kriege hier zumindest im vSphere Client nur die Echtzeit Statistik angezeigt. Kann also nicht mal ne Woche oder so zurückschauen. Bei einer anderen ESX 3,5 Umgebung kann ich auf benutzerdefiniert gehen und Zeitraum auswählen.

[irix]

Vielen Dank erstmal für die Tipps. Werde das mit esxtop mal überprüfen wenn es wieder mal langsam ist. Im Moment läuft alles deshalb kann ich noch keine Aussage machen.
Wegen der Statistik, das geht ja glaube ich nur über vCenter Server. Ich kriege hier zumindest im vSphere Client nur die Echtzeit Statistik angezeigt. Kann also nicht mal ne Woche oder so zurückschauen. Bei einer anderen ESX 3,5 Umgebung kann ich auf benutzerdefiniert gehen und Zeitraum auswählen.

Mittels Konfiganweisung laesst sich wohl der Zeitraum bei "Standalone" Hosts auf 36h ausweitern. Allerdings wuerde ja Realtime ausreichen. Ich vermute eher das die VMs swappen und darum sich träge anfühlen.

Du kannst auch mal eine VM mit einem IOmeter vorbeiten wo das ein Benchmark durchführst um dann im Problemfall dieses zuwiederholen um zugucken ob sich die Werte arg unterscheiden.

Gruss
Joerg

[schroem]

Nun ist wieder der Zeitpunkt eingetreten, wo die Kiste total langsam ist. Habe nun ein bisschen mit esxtop herumgespielt. Die Werte bei DAVG/cmd und GAVG/cmd liegen bei etwa 100 - 130, KAVG/cmd bei etwa 0,02. Ich galube bis 10ms wären normal. Wie ich nachlesen konnte: Wenn DAVG hoch ist und KAVG niedrig, dann deutet das normal auf eine Problem im Storage Bereich hin. Diese Vermutung hatte ich ja bereits.
Sämtliche Firmwares etc. sind auf dem neuesten Stand. Was kann ich hier noch tun? Das einzige was mir spontan einfällt: Vor etwa 2 Monaten ist eine Festplatte ausgefallen. Festplatte wurde getauscht, RAID hat sich wieder aufgebaut ohne Probleme. Das Problem bestand jedoch schon vor dem Zeitpunkt des Wechsels. Die "neue" Fesplatte hat nicht die Firmwareversion der Anderen. Könnte das was sein?

[irix]

Frage: Geht die BBU des Kontrollers in den Lernzyklus oder schaltet sich warum auch immer ab? Das haette zumind. auf die Schreibrate einen Einfluss.

Auch fuer den ESXi gibts ein OMSA in Form eines VIB welches sich dann von einem Remote OMSA abfragen laesst.

Dagegen spricht aber das du sagst das nach einem Neustart die Performance wieder OK ist. Weil gerade nach einem Neustart geht die BBU immer in einen Lernzyklus bei den LSI Kontrollern.

Gruss
Joerg

[schroem]

Wenn ich den ESXi neu starte, dann steht für eine kurze Zeit unter Systemstatus im vSpehre Client ein gelbes Ausrufungszeichen bei "Battery on Controller 0" --> charging. Selbst während dieser Zeit ist die Performance einwandfrei. Nach ein paar Minuten ist dann alles wieder auf grün --> Fully Charged. Dieser Status bleibt auch wenn nach ein paar Tagen später die Performance-Probleme kommen. OMSA ist derzeit nicht installiert. Mir kommt das Ganze so vor, als laufe der Cache vom RAID Controller voll. Ich habe jetzt das Bios nicht vor Augen aber vielleicht gibt es hier noch bessere Einstellungen.

[Tschoergez]

Hi!
ich schließ mich da mal dem anderen Jörg an
Hört sich so an, als würde sich der Cache abschalten, wahrscheinlich wg. Problemen mit der Batterie...

"Volllaufen" kan ein Cache in dem Sinn eigentlich nicht, denn dafür gibts ja entsprechende Algorithmen, die alten Einträge wieder rauszuschmeißen. Und das macht der Controller automatisch.
außerdem würde das Ding besonders langsam werden, wenn Du viele IO-lastigen Workloads laufen lässt.

viele grüße,
jörg

[irix]

Bischen komisch ist das schon. Mach doch mal Benchmarks mit IOmeter und installier OMSA. Wenn du dir das Serverlog anschaust steht da irgendwas drin?

Dann kannst du mal die Cache Policy von WriteBack auf Writethrough umstellen und schauen ob dann die Performance von Anfang an so schlecht ist.

Anmerk.
- WriteBack kann man im Controller BIOS erzwingen (Will man aber nicht, ausser man hat eine USB und autom. Shutdown am ESX)
- Der Controller hat noch eine Option (Name entfallen wo man als Parameter "ReadAHead, Adaptive, No" einstellen kann. Wir haben das immer auf NO weil das war fuer RandomIO hier das beste.

Gruss
Joerg

[schroem]

sorry erstmal , konnte mich in letzter Zeit wegen Zeitmangels leider nicht melden.

@irix: Konnte leider noch nicht ins Bios schauen, da ich den Server erst immer gegen spät abends runterfahren kann und sich die Kiste an einem anderen Standort befindet. Möchte aber demnächst auf jeden Fall hinfahren. Ich gehe mal davon aus, dass die Einstellungen des Raid Controller auf default stehen. Demnach sollten nicht die Advanced Settings aktiv sein. Was spricht also dagegen das Write Back zu erzwingen? Eine Batterie zur Pufferung auf dem Raid Controller ist ja vorhanden. Außerdem hängt das Ganze an einer USV. Die Einstellungen wären dann: Element Size: 64KB; Read Policy: No Read Ahead; Write Policy: Write Back.
Durch ändern dieser Einstellungen sollte mir ja nicht das RAID um die Ohren fliegen?

[schroem]

zu schnell auf senden gedrückt...

du meinst bestimmt die Option "Force WB with no battery"?

[irix]

Ja meinte ich.

Auf einer Windowskiste mit installiertem OMSA kann man ueber die WebGUI im lfd. Betrieb die Cacheregeln aendern... sehr praktisch das Ganze.

Ich habe OMSA hier auch auf den ESXi Hosts laufen... allerdings haben die nur den SAS6iR Kontroller und da ist nur RAID1 ohne Extras weil der Rest kommt vom SAN. Die frage also wenn du auf deinem ESXi OMSA installiertst, aktivierts und dann mittels Remote Zugriff ueber ein vollwärtiges OMSA (Linux/Windows) zugreifst ob du dort auch die Regeln beeinflussen kannst. Auf jeden Fall hat man Zugriff auf LOGs, RAID Status usw. Selbst wenn das bei deinem aktl. Problem nicht weiterhilft ist es sehr Praktisch fuer den Normalbetrieb.

Ich habe hier PE2800/PE2950 mit PERC6i und Localstorage und hab solche Probleme noch nicht erlebt.

Gruss
Joerg