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

AW: System killt sich selbst



Hallo!

> -----Ursprüngliche Nachricht-----
> Von: uwe@laverenz.de [mailto:uwe@laverenz.de]
> 
> Welcher RAID-Controller? Wieviele Platten?

8 Platten a 1TB SATA an einem Sun StorageTek Ultra320 
SCSI-Hostbus-Adapter für PCIe mit zwei Kanälen.

> 
> > 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?

Die beiden WebServer haben jetzt 2 vCPUs und mind. 2GB RAM und 
max. 4GB RAM. Die anderen Server jeweils 1 vCPU und max. 4GB RAM
Einer der beiden Webserver (der "Größere") hat höhere Prio für 
Plattenzugriff bekommen.

> 
> > 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.

Kann sein. Wie könnte ich das Problem beheben? Downgrade?

> 
> > 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.

Natürlich. Ich bin für alle Sachen offen. Wir haben hier schon 
ganz andere (kuriose) Dinge vermutet.

> 
> > 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?

Nur die VM. Der Server, also ESX läuft ohne Probleme weiter. 
Auch andere VMs sind nicht betroffen, wenn das Problem auftritt.

> 
> > 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?

Eigentlich nicht. Nur ein paar Symlinks. 
Ich habe bis jetzt immer die Daten in dieser Art kopiert. Da gab es 
auf anderen Servern keine Probleme (und auch früher auf dieser
speziellen Kiste nicht).

> 
> > 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.

Du meinst, dass beim Übertragen der Daten es zu einem Engpass kommt?
Das würde den langsamen Server und das gelangweilte RAID erklären.
Hast Du da vielleicht auch ne Diagnostik-Methode zur Hand oder vielleicht
gleich ein Lösungsvorschlag?

> 
> > 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.

Die aktuelle Config sollte jedoch diese Probleme nicht auslösen, s.o.

> 
> > 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.

Das war aber schon sehr viel, was Dir eingefallen ist.
Danke schonmal dafür.

> 
> Gruss,
> Uwe
> 
> 

Grüße
Jens


Reply to: