[debian] VMware performance

[Boudewijn]

Hoihoi


Ik heb de laatste tijd een server die echt pokketraag wordt; vanmiddag was het weer zover.
Zeer hinderlijk.

Specs:

2x Opteron 275
10GB mem
Areca 1120 met 8x 1TB @Raid6 , write back cacheing enabled


Disks zijn als volgt ingedeeld:

code:

ragbak:/home/vm# fdisk -l

Disk /dev/sda: 498 MB, 498597888 bytes
255 heads, 63 sectors/track, 60 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000421d0

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          60      481918+  83  Linux

Disk /dev/sdb: 99.9 GB, 99999547392 bytes
255 heads, 63 sectors/track, 12157 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00048a05

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       11550    92775343+  83  Linux
/dev/sdb2           11551       12157     4875727+  82  Linux swap / Solaris

Disk /dev/sdc: 5899.4 GB, 5899498291200 bytes
64 heads, 32 sectors/track, 5626200 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Disk identifier: 0x00000000

Disk /dev/sdc doesn't contain a valid partition table
ragbak:/home/vm#

Ja /dev/sdc heeft geen valide partitie tabel: het kreng is 5.9tb groot en dat gaat niet met fdisk.
Ik heb direct op de disk een ext3 partitie aangemaakt , zonder tabel.


Goed, dit is een redelijk dikke setup voor wat er momenteel mee gebeurt:

3 debian VMs, elk 128-256megabyte memory en 1 CPU.
In totaal 46GB aan data.


Nu valt het me op dat ondanks dat die 3 VMs weinig doen (1 mail, 1 web en 1 sql server zonder significante load) de load van die machine soms > 25 of zelfs >50 gaat.
In top zie je geen boosdoeners op VMware, kjournald en pdflush na... die laatste 2 wijzen op IO gerelateerde issues. Iostat levert mij dit op:

code:

ragbak:/home/vm# iostat 
Linux 2.6.26-2-amd64 (ragbak.boudewijnector.nl)     03/06/2010  _x86_64_

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.23    0.00    2.25   19.03    0.00   78.49

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               0.01         0.12         0.00       1538          2
sda1              0.00         0.09         0.00       1194          2
sdb               2.76        27.98        62.29     366792     816712
sdb1              2.75        27.90        62.29     365777     816712
sdb2              0.00         0.05         0.00        711          0
sdc              21.12       203.69       334.50    2670586    4385672

We zien hier dat het ook nogal wat IO acties op /dev/sdc (waar de VMs zich bevinden).
Volgens vmware zijn de dingen echter niet heel actief, en dat klopt... ze staan niet te swappen ofzo.


Wat kan hier nou efficient aan doen qua debugging? Deze setup heeft vele malen beter gewerkt. Ligt dit aan mijn brakke indeling van /dev/sdc? Ligt dit aan VMware?

Ik draai een standaard kernel, en standaard vmware2.


Ik zette net op 1 van de VMs apachetop aan, dat duurde 5 seconden eer het startte en ik zag de load op het host systeem van 9 naar 15 oplopen. Dat niveau van bagger is het momenteel....

[ Voor 3% gewijzigd door Boudewijn op 06-03-2010 23:42 ]

[Room42]

Je hebt die machines wel behoorlijk weinig geheugen gegeven. Mijn eerste gedachte gaat toch naar swappen uit. Kun je niet achterhalen wat ie leest/schrijft dus waar ie precies z'n I/O's aan besteed?

Mag ik ook eens een 'mount' zien?

[ Voor 3% gewijzigd door Room42 op 07-03-2010 04:22 ]

[Boudewijn]

Op zich hebben ze of geen swap of maar een paar meg aan geswapte data.
Zal dat eens vergroten zo.

Wat voor mount wil je zien?
Achterhalen waar hij zijn IO aan besteedt? Geen idee hoe... lsof?


Hmm de areca lijkt ook in tosti-mode te zijn gegaan:

code:

[44807.508083] arcmsr0: abort device command of scsi id = 0 lun = 2
[44812.098913] arcmsr0: scsi id = 0 lun = 2 ccb = '0xffff810037861e40'
poll command abort successfully
[44813.969566] arcmsr0: abort device command of scsi id = 0 lun = 2
[44813.969654] arcmsr0: abort device command of scsi id = 0 lun = 2
[44813.969741] arcmsr0: abort device command of scsi id = 0 lun = 2
[44813.969828] arcmsr0: abort device command of scsi id = 0 lun = 2
[44813.971067] arcmsr0: abort device command of scsi id = 0 lun = 1
[44813.971155] arcmsr0: abort device command of scsi id = 0 lun = 1
[44813.971242] arcmsr0: abort device command of scsi id = 0 lun = 1

dmesg staat vol met deze meuk.


De areca zelf ziet geen issues in zijn log; de disks zijn op normale temperatuur, en de fan draait netjes met een kleine 3k rpm.

[ Voor 71% gewijzigd door Boudewijn op 07-03-2010 09:43 ]

[Verwijderd]

Boudewijn schreef op zondag 07 maart 2010 @ 09:31:

Achterhalen waar hij zijn IO aan besteedt? Geen idee hoe... lsof?

atop

En zijn de VMware tools wel up-to-date?

[ Voor 10% gewijzigd door Verwijderd op 07-03-2010 09:47 ]

[Boudewijn]

Op zich zou het zonder VMware tools ook prima moeten draaien, dat heeft het namelijk altijd gedaan (en ja , met is beter ik weet het).

Echter lijkt het hier toch een raidkaart issue te zijn, gezien de enorme hoeveelheid arcmsr errors (areca kaartje...).

[FireDrunk]

Heb je ergens paravirtualization aan gezet ofzo?

[ Voor 3% gewijzigd door FireDrunk op 07-03-2010 13:54 ]

[Boudewijn]

Neen, hoezo dat? Waar zou ik dat moeten zoeken, host of guest?

[WiebeV]

Gebruik anders iotop om te achterhalen welk process er zoveel aan het schrijven is. (is vast wel te apt-get'en).

Je zou dit eerst op je host kunnen doen zodat je ziet welke VM veel aan het schrijven is.
Dan op de VMs die veel lopen te schrijven om te achterhalen welk process.

[ Voor 36% gewijzigd door WiebeV op 07-03-2010 17:24 . Reden: tiepfaud ]