Unendlich hohe Load

[stehlampe]

Hallo zusammen!
Vielleicht hat jemand eine Idee warum folgendes Szenario auftritt:

Ich habe auf einem Root debian 5 und VMware-Server 2.01 ohne weitere Software laufen. Die Maschine dient nur als Host für virtuelle Maschinen. Soweit läuft alles super, nur wenn die (bisher einzige) VM unter Last steht, steigt die Load des Hosts auf 20+ und irgendwann quittiert die VM Ihren Dienst. Dies tritt allerdings nicht während des normalen Betriebs auf, sondern scheinbar nur wenn extrem viel auf den Festplatten gelesen / geschrieben wird. Der Start von imapsync (10 Konten, 25000 Mails) bzw. rsnapshot (6 Websites, 25GB) von einer anderen Linux Maschine reicht hierzu schon aus.

Den Logs ist nicht viel zu entnehmen und ich stochere deshalb im Dunkeln herum.

Sicher ist auf jeden Fall, dass wenn die Load auf dem Host steigt, in iotop pdflush 99,9% des IO in Anspruch nimmt und sich das ganze dann scheinbar hochschaukelt. Kann es vielleicht damit zusammen hängen, dass die virtuelle Festplatte in 50 x 2GB große Teile gesplittet ist?

Ich bin für jeden Tipp dankbar,

Stehlampe

[cane]

IMO ist pdflush dafür zuständig Datenmüll zwischen RAM und Swap zu jonglieren.

--> Swappen das Hostsystem oder die VM?

Wie sieht die Hardware generell aus?

mfg
cane

[L00NIX]

Suche mal nach Prozessen mit Zustand D (wait for I/O). Pro D gibt's bei der Load einen drauf.

Also für 5 Ds hat der Server schon eine Load von mind. 5.0

Von den Namen der zugrhörigen Prozessen kann man ggf. auf mehr schließen.

Ist die Virtuelle Platte pre-alloziert, also die Teile alle 2GB groß? Oder etwa dieses wachsende Format, das kannste gleich knicken und die Platte neu anlegen.

Gruß
L00NIX

[stehlampe]

Hallo Männers!

Erstmal vielen Dank für euer Bemühen! :)

Zur Euren Postings:

@cane
Weder der Host, noch die VM swappt. Die Speicher ist voll, aber fast ausschließlich gecachte Sachen laut htop.

Zur Hardware:
Ein EQ6 von Hetzner mit Core i7 und 12GB RAM. Die VM läuft unter VMware-Server 2.01 mit 2GB RAM. OS ist in beiden Fällen Debian 5 64bit im letzten Patchlevel.


@loonix
Ich werde mal gleich für ein bisschen Load auf der Maschine sorgen und dann berichten.

Die virtuelle Platte der VM ist 100GB groß und auf der physikalischen Platte des Hosts in 2GB große Teile aufgeteilt. Und ja, es handelt sich um dieses wachsende Format. Also:
[ ] Allocate all disk space now
[x] Split disk into 2GB files

Hast du schlechte Erfahrungen mit diesem wachsenden Format gemacht?

Wenn dem so ist, gibt es eine Möglichkeit diese Platte entsprechend umzuwandeln?

Stehlampe

[stehlampe]

Ich nochmal mit ein paar Zahlen:

Ich habe für ein bisschen Load auf der Maschine gesorgt und kann folgende Zahlen angeben:

top:


top - 09:17:39 up 20:00, 3 users, load average: 11.42, 10.23, 6.69
Tasks: 141 total, 1 running, 140 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.9%us, 1.0%sy, 0.0%ni, 48.2%id, 49.6%wa, 0.2%hi, 0.0%si, 0.0%st
Mem: 12330784k total, 12263212k used, 67572k free, 158692k buffers
Swap: 4200888k total, 808k used, 4200080k free, 11430780k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8201 root 20 0 60100 7584 2996 S 3 0.1 23:58.21 iotop
31698 root 20 0 59568 7100 2996 S 1 0.1 1:49.51 iotop
3999 root 20 0 1875m 66m 40m D 1 0.5 214:22.48 vmware-vmx
8046 root 20 0 1862m 64m 51m S 1 0.5 18:34.57 vmware-vmx
15356 root 20 0 19476 1480 984 S 1 0.0 5:11.42
1 root 20 0 10312 748 620 S 0 0.0 0:01.70 init
2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0 0.0 0:00.44 migration/0
4 root 15 -5 0 0 0 S 0 0.0 0:03.26 ksoftirqd/0
5 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/0
6 root RT -5 0 0 0 S 0 0.0 0:00.22 migration/1
7 root 15 -5 0 0 0 S 0 0.0 0:01.66 ksoftirqd/1
8 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/1
9 root RT -5 0 0 0 S 0 0.0 0:00.04 migration/2
10 root 15 -5 0 0 0 S 0 0.0 0:01.06 ksoftirqd/2
11 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/2
12 root RT -5 0 0 0 S 0 0.0 0:00.42 migration/3
13 root 15 -5 0 0 0 S 0 0.0 0:03.24 ksoftirqd/3
14 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/3
15 root RT -5 0 0 0 S 0 0.0 0:00.10 migration/4
16 root 15 -5 0 0 0 S 0 0.0 0:01.36 ksoftirqd/4
17 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/4
18 root RT -5 0 0 0 S 0 0.0 0:00.00 migration/5


ps aux


root 1120 0.0 0.0 0 0 ? D 09:15 0:00 [pdflush]
root 1516 0.0 0.0 0 0 ? D< May27 0:02 [md2_raid1]
root 1524 0.0 0.0 0 0 ? D< May27 0:17 [md3_raid1]
root 1629 0.0 0.0 0 0 ? D< May27 0:00 [kjournald]

[marce]

wie viele Platten hat denn das Ding und unter welchem Raid-Level laufen die?

[stehlampe]

wie viele Platten hat denn das Ding und unter welchem Raid-Level laufen die?

Der Host hat zwei 1,5TB Platten im Software-Raid1. Die VM hat nur eine virtuelle Platte mit den genannten 100GB.

[cane]

Hallo Männers!

Erstmal vielen Dank für euer Bemühen! :)

Zur Euren Postings:

@cane
Weder der Host, noch die VM swappt. Die Speicher ist voll, aber fast ausschließlich gecachte Sachen laut htop.

Zur Hardware:
Ein EQ6 von Hetzner mit Core i7 und 12GB RAM. Die VM läuft unter VMware-Server 2.01 mit 2GB RAM. OS ist in beiden Fällen Debian 5 64bit im letzten Patchlevel.

Gut, dann scheints schonmal nicht am Swappen zu liegen.

Bitte generier doch mal Last auf der VM (Viele Dateien anlegen) und schau mal per vmstat ob Du iowait hast.



Die virtuelle Platte der VM ist 100GB groß und auf der physikalischen Platte des Hosts in 2GB große Teile aufgeteilt. Und ja, es handelt sich um dieses wachsende Format. Also:
[ ] Allocate all disk space now
[x] Split disk into 2GB files

Hast du schlechte Erfahrungen mit diesem wachsenden Format gemacht?

Die wachsenden Platten verursachen auf jeden Fall viel mehr Overhead wenn man massiv Daten schreibt.



Wenn dem so ist, gibt es eine Möglichkeit diese Platte entsprechend umzuwandeln?

Ja, googel mal - hab ich schon mal gemacht

[stehlampe]

Hallo!
Die gepostenten Werte des Hosts resultieren auf der Migration einer Website mit dem Plesk-Migrationsmanagers.

vmstat:


VM während der Migration (load ca.4)

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 3 2968 20540 30944 1646224 0 0 317 341 23 151 1 2 69 28





Die wachsenden Platten verursachen auf jeden Fall viel mehr Overhead wenn man massiv Daten schreibt.

Ja, googel mal - hab ich schon mal gemacht

Okay, werde mal danach suchen. Habe gerade schon überlegt ob man mit Hilfe einer vom ISO gebooteten Live-CD nicht die Sache mit dd überführen kann.

Manno und das am Freitag!

Stehlampe

[L00NIX]

Die wachsenden Platten verursachen auf jeden Fall viel mehr Overhead wenn man massiv Daten schreibt.


Und Fragmentieren ist ihre Natur.

Für den Produktiven Betrieb gänzlich ungeeignet also am besten die VMDK neu anlegen in Zukunft das Format nur noch als Backup oder Export für den Transport nutzen, wofür es auch gedacht ist.

Das 2GB-Split kannst du dir auch, je nach Größe der VMDK und dem verwendeten Dateisystem (maximale Dateigröße beachten!) des Hostsystems, sparen.

Gruß
L00NIX

[L00NIX]

Hast du schlechte Erfahrungen mit diesem wachsenden Format gemacht?

Wenn dem so ist, gibt es eine Möglichkeit diese Platte entsprechend umzuwandeln?


Du kannst den vmware-vdiskmanager benutzen:


$ vmware-vdiskmanager
VMware Virtual Disk Manager - build 80187.
Usage: vmware-vdiskmanager OPTIONS diskName
Offline disk manipulation utility
Options:
-c : create disk; need to specify other create options
-d : defragment the specified virtual disk
-n <source-disk> : rename the specified virtual disk; need to
specify destination disk-name
-q : do not log messages
-r <source-disk> : convert the specified disk; need to specify
destination disk-type
-x <new-capacity> : expand the disk to the specified capacity

Additional options for create and convert:
-a <adapter> : (for use with -c only) adapter type (ide, buslogic or lsilogic)
-s <size> : capacity of the virtual disk
-t <disk-type> : disk type id

Disk types:
0 : single growable virtual disk
1 : growable virtual disk split in 2Gb files
2 : preallocated virtual disk
3 : preallocated virtual disk split in 2Gb files

The capacity can be specified in sectors, Kb, Mb or Gb.
The acceptable ranges:
ide adapter : [100.0Mb, 950.0Gb]
scsi adapter: [100.0Mb, 950.0Gb]
ex 1: vmware-vdiskmanager -c -s 850Mb -a ide -t 0 myIdeDisk.vmdk
ex 2: vmware-vdiskmanager -d myDisk.vmdk
ex 3: vmware-vdiskmanager -r sourceDisk.vmdk -t 0 destinationDisk.vmdk
ex 4: vmware-vdiskmanager -x 36Gb myDisk.vmdk
ex 5: vmware-vdiskmanager -n sourceName.vmdk destinationName.vmdk


Du willst ein convert der Disk:


$ vmware-vdiskmanager -c quelle.vmdk -t 2 ziel.vmdk


Gruß
L00NIX

[stehlampe]

Und Fragmentieren ist ihre Natur.

Für den Produktiven Betrieb gänzlich ungeeignet also am besten die VMDK neu anlegen in Zukunft das Format nur noch als Backup oder Export für den Transport nutzen, wofür es auch gedacht ist.

Das 2GB-Split kannst du dir auch, je nach Größe der VMDK und dem verwendeten Dateisystem (maximale Dateigröße beachten!) des Hostsystems, sparen.

Gruß
L00NIX

Hallo!
Ich hoffe das hier wirklich der Hund begraben ist. Ich hatte bisher allerdings keine Probleme auf diversen anderen Maschinen damit, muss aber zugeben das diese a) nicht so stark frequentiert werden wie diese und b) eine deutlich geringe Größe der virtuellen Platte aufwiesen.

Ein Grund für meine Vorgehensweise war eben das die Dateien mit 2GB eben deutlich "handlicher" sind als eine große Datei von 100GB.

Der Tipp mit dem Konvertieren war übrigens ein guter!

Mit


vmware-vdiskmanager -r alt.vmdk -t 0 neu.vmdk


vmware-vdiskmanager -r neu.vmdk -t 2 neu1.vmdk

konnte ich die Platte in das gewünschte Format (single / preallocated) konvertieren. Ich teste es gerade in einer parallelen VM und sehr froh darüber das es so einfach möglich ist! :)

Vielen Dank für Eure Tipps und Hinweise,

Stehlampe

[stehlampe]

Ah, habe deinen zweiten Post erst nach meiner Antwort gesehen.
Genau die Informationen habe ich auch gefunden und gleich angewendet.

Der Konvertierungsprozess ist gleich durch und ich bin gespannt ob die Maschine startet...

Stehlampe

[marce]

noch als Tipp: SW-Raid1 ist bei hohem Write-Anteil der beteiligten Filesysteme nicht gerade optimal - man sollte also möglichst versuchen, den zu reduzieren - und da kann man sowohl in der VM selbst als auch dem Hostsystem optimieren...

[stehlampe]

Hallo Männers!
Zwischenzeitlich hatte ich noch andere Probleme mit der VM, so dass ich keine Zeit hatte hier zu antworten.

Zum derzeitigen Zwischenstand:
Die Konvertierung ist durchgelaufen und die VM kam mit der neuen virtuellen Platte hoch. Ich hatte aber noch keine Zeit das System freizuschalten, also in den Livebetrieb zu nehmen. Dies schaffe ich erst kommende Woche und werde dann berichten.

@marce
Da gebe ich dir Recht, allerdings ist das Verhalten meiner Meinung nach schon untypisch, denn so stark wird die VM nicht in Anspruch genommen. Komisch ist, das auf einem anderen System (Server bei Strato) mit der gleichen Config alles reibungslos (mit zwei VMs) läuft und ich mittlerweile überlege ob nicht der Host oder dessen Einstellungen auch eine Rolle in diesem Szenario spielen.

Ein Punkt der hierfür spricht:
Während der Konvertierung der virtuellen Festplatte bekam der Host recht schnell eine Load von 22 durchgehend mit Spitzen von bis zu 24. Die Load der VM stieg unmittelbar auf bis zu 8 mit. Ist das nicht ein bisschen viel?


noch als Tipp: SW-Raid1 ist bei hohem Write-Anteil der beteiligten Filesysteme nicht gerade optimal - man sollte also möglichst versuchen, den zu reduzieren - und da kann man sowohl in der VM selbst als auch dem Hostsystem optimieren...

Welche Optimierungen meinst du hier? Gibst du mir einen Tipp?

Viele Grüße,

Stehlampe