[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: System killt sich selbst



On Mon, Mar 09, 2009 at 10:35:58AM +0100, "Körte, Jens" wrote:

> Wir betreiben hier einen ESXi auf einer SUN mit 
> einem RAID5, einem QuadCore und 12GB RAM.

Welcher RAID-Controller? Wieviele Platten?

> Auf dem ESXi sind mehrere Rechner installiert, u.a. 
> 4 Debian-Installationen 
> (Linux version 2.6.18-6-686 (Debian 2.6.18.dfsg.1-24))
> und noch 2 Windows-Kisten.

Wieviel RAM und vCPUs pro VM?

> Das Ganze endet damit, dass der Kopiervorgang quasi stehen
> bleibt (ca. 1MB/Sekunde) und die Kiste extremst ausgelastet
> ist (Befehle in die Konsole tippen geht ganz langsam ...)

I/O-starvation? Die neueren Linuxkernel kommen mit hoher I/O-Last
nicht sonderlich gut zurecht.

> nicht mehr ausliefern können. Damit warten sie auf die Daten
> und für weitere Anfragen werden weitere Prozesse gestartet.
> dadurch wird der Kopiervorgang langsamer, da Prozesse nach-
> geladen werden müssen - ihr merkt, die Katze beisst sich in 
> den Schwanz.

Kann auch sein, daß es nur zufällig den Apache trifft bzw. dass
es bei Apache am offensichtlichsten ist.

> Um dann Daten kopieren zu können, müssen wir den Rechner
> neustarten und direkt danach den Kopiervorgang starten.

Den ganzen Server oder nur die VM?

> In diesem Fall läuft die Kiste problemlos weiter und die Daten
> wurden kopiert.

Seltsam... Was für Daten sind das? Habt ihr da vielleicht irgendwelche
Rekursionen drin oder werden die Daten von einem Prozess geblockt?

> Eine Kontrolle des Raid brachte keine Erkenntnisse. Das Raid
> hat keine Fehler und ist eher gelangweilt.

Hmm... Klingt seltsam, aber ohne weitere Details würde ich vermuten, 
dass Euer RAID5-System der Flaschenhals ist.

> Als nächstes hatten wir einer Debian-Installation mehr Ressourcen
> zur Verfügung gestellt. Das hatte jedoch keine Auswirkungen auf
> das Verhalten. Alles in allem zeigen die Systemmonitore des ESXi,
> dass der Rechner nur wenig ausgelastet ist 
> (CPU ca. 30%, RAM 20%, ...).

Mehr Ressourcen können unter ESX(i) auch einen gegenteiligen Effekt
haben: bei 4 Cores gesamt sollten jeder VM maximal 2 vCPUs zugewiesen
werden, sonst hat der ESX keinen Dampf mehr für seine eigenen Aufgaben.
In so einer Umgebung sind VMs mit 1 oder 2 vCPUs schneller als mit 4
vCPUs. RAM sollte man ebenfalls erst over-committen, wenn man sicher
ist, dass es funktioniert.

> Hatte jemand schon mal das gleiche Problem? Oder kann da jemand
> einen Ansatz geben, wie wir hier das Problem beheben können?

Sorry, mehr fällt mir bei den gegebenen Informationen nicht ein.
Notfalls müsst Ihr Euch jemanden einladen, der sich auskennt und
der sich der Sache systematisch annimmt.

Gruss,
Uwe


Reply to: