[Hyper-V 2012] MySQL traag in Linux VM

[Priet]

Tijdens het opzetten van een aantal Linux VM's (OpenSUSE) constateerde ik dat een import script voor MySQL data erg traag was bij het opzetten van de data tabellen. Op dat moment heb ik er verder geen aandacht aan besteed, de insert's verliepen verder op de te verwachten snelheid.
Later merkte ik dat de web applicatie die op de VM draait op sommige punten ook erg traag was, tot enkele seconden per page request. Toen ben ik er maar eens ingedoken om de oorzaak te achterhalen...

Nu blijkt dat sommige queries erg traag zijn. Bij een doorsnee SELECT of INSERT valt het niet zo op, het hangt van het aantal af of het opvalt. Wat wél altijd traag blijkt is het aanpassen van de AUTO_INCREMENT waarde van een tabel, of de volgende query:

SQL:

ALTER TABLE t ENGINE=MyISAM;
-- Query OK, 0 rows affected (0.23 sec)
ALTER TABLE t ENGINE=InnoDB;
-- Query OK, 0 rows affected (0.52 sec)

Normaal gesproken duurt het wijzigen naar MyISAM 0,00 seconden, naar InnoDB doorgaans iets van 0,02 seconden (getest op meerdere servers). Op deze Linux VM's nam de MyISAM-query zo'n 0,30s en InnoDB query zo'n 0,50s - 0,80s in beslag. De waarden schommelen, maar zijn altijd significant meer dan de 0,00s - 0,02s die je mag verwachten.

Configuratie van de server:

Windows Server 2012 Hyper-V (Intel Core i7 3770 @ 3.4Ghz)
-------------------------------------
OS: Suse 12.2 x64
Harddisk: 32GB IDE
Memory: 1024MB
CPU: 1 core
Network: Network Adapter
-------------------------------------
Setup: 
Dekstop: Minimal Server Selection (Text Mode)
Partitioning:
  - Create swap volume /dev/sda1 (1.46GB)
  - Create root volume /dev/sda2 (30.54 GB) with ext4
Firewall: disabled
SSH: enabled

Na installatie is het volgende uitgevoerd om MySQL te installeren:

Bash:

# reboot
# zypper up
# zypper in mysql-community-server
# service mysql start
# mysql

Om te testen voor ik vervolgens de volgende queries in:

SQL:

DROP DATABASE IF EXISTS test;
CREATE DATABASE test;
USE  test;
CREATE TABLE t (
  id INT(11) default NULL auto_increment,
  s char(60) default NULL,
  PRIMARY KEY (id)
) ENGINE=MyISAM;
ALTER TABLE t ENGINE=MyISAM;
ALTER TABLE t ENGINE=InnoDB;

Ik heb van alles geprobeerd: de configuratie van InnoDB, Hyper-V, Linux, waaronder:

• Configuratie InnoDB geoptimaliseerd
• Meer VM geheugen
• Meer VM cores
• Ext2 ipv ext4
• LVM
• /boot op IDE, / op SCSI
• OS: OpenSUSE 12.2 / Debian / CentOS 6.3 / SLES

SLES en Debian zijn iets sneller, maar komen niet in de buurt van de 0,02s.

Het mag allemaal niet baten. Wanneer ik exact dezelfde stappen herhaal op een stand alone, Proxmox of ESXi server zijn de queries wel snel. En dat is met een default MySQL installatie en standaard Linux installatie.

Op een tweede Hyper-V 2012 server (Core i5-2400 @ 3.1Ghz) zijn de resultaten nagenoeg gelijk aan de eerste Hyper-V server.

Wanneer ik dezelfde VM aanmaak op een Hyper-V 2008 R2 server gaat het wel goed De resultaten zijn dan gelijk aan die onder Proxmox/ESXi/Stand alone. Dit blijkt het geval te zijn op meerdere 2008 servers die ik getest heb.

Ik heb de test ook uitgevoerd onder Windows Azure met SLES (small: 1 core/1.75GB). En daar worden de ALTER TABLE queries uitgevoerd in zo'n 0,04s.

Ik heb de testen meerdere malen uitgevoerd en herhaald op verschillende servers en elke keer blijkt dan alleen de VM's onder 2012 schrikbarend traag zijn. Je zou toch verwachten dat de Linux support onder 2012 verbetert is ten opzichte van 2008?

Heeft iemand enig idee hoe dit mogelijk is? Is onder 2012 ook de performance van 2008/ESXi/Proxmox te behalen?

[Meekoh]

Integration services wel geinstalleerd?

[Priet]

Yup (doet Suse standaard):

code:

# zypper search hyper-v
S | Name    | Summary                 | Type
--+---------+-------------------------+-----------
i | hyper-v | Microsoft Hyper-V tools | package
  | hyper-v | Microsoft Hyper-V tools | srcpackage

code:

# lsmod | grep hv_
hv_utils               13493  0
hv_netvsc              31355  0
hv_storvsc             17524  2
hv_vmbus               42608  4 hid_hyperv,hv_utils,hv_netvsc,hv_storvsc

[Priet]

Op een tweede server heb ik een extra schijf toegevoegd en deze toegekend aan een nieuwe VM as phyical hard disk (passthrough). Verder zonder andere schijven.

De installatie van OpenSUSE verloopt stukken sneller, vergelijkbaar met Proxmox/KVM of op een fysieke PC. Ook het booten gaat nu een stuk sneller. Vooral om dat er niet meer gewacht wordt na de 'mount -o rw,acl,user_xattr -t ext4 /dev/root /root' regel, voor de regel 'SMBus base address unitialized - upgrade BIOS or use force_addr=0xaddr'. Dat wachten duurt nu één seconde ipv een halve minuut

MySQL is ook een stuk sneller. De query 'ALTER TABLE t ENGINE=InnoDB;' wordt nu in 0,10s - 0,20s uitgevoerd, de MyISAM variant onder 0,10s.

Hoewel dat stukken beter is, is dat nog steeds 10x zo traag als je zou mogen verwachten.

Het kan best zo zijn dat andere zaken op de VM ook traag uitgevoerd worden. Echter is dit het enige waar dit mij zo opviel.

Ik werd ook nog gewezen op de unbuffered IO, dat wellicht oorzaak was van het probleem. Maar volgens mij is dat op deze situtatie niet van toepassing aangezien de server stand alone draaien.

Iemand een hint in de goede richting?

[Priet]

Niemand?

Geen mensen met Windows 2012 Server en een Linux VM?

[Razwer]

nee over het algemeen draai je geen linux op hyper-v ivm de sumiere support er van en de vaak brakke performance
er zijn soms wel wat kleine tweaks die je kan proberen tbv de integration tools, maar dan nog ben je beter af met vmware oid.

[Crazymonkey]

Heb hier een WS2012 met HyperV en een linux server op draaien. (dan wel op een ssd)

mysql> DROP DATABASE IF EXISTS test;
Query OK, 1 row affected (0.01 sec)

mysql> CREATE DATABASE test;
Query OK, 1 row affected (0.00 sec)

mysql> USE  test;
Database changed
mysql> CREATE TABLE t (
    ->   id INT(11) default NULL auto_increment,
    ->   s char(60) default NULL,
    ->   PRIMARY KEY (id)
    -> ) ENGINE=MyISAM;
Query OK, 0 rows affected (0.00 sec)

mysql> ALTER TABLE t ENGINE=MyISAM;
Query OK, 0 rows affected (0.00 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> ALTER TABLE t ENGINE=InnoDB;
Query OK, 0 rows affected (0.00 sec)
Records: 0  Duplicates: 0  Warnings: 0

[Brahiewahiewa]

Razwer schreef op zaterdag 12 januari 2013 @ 17:00:
nee over het algemeen draai je geen linux op hyper-v ivm de sumiere support er van en de vaak brakke performance
....

Niet iedereen verkeert in de luxueuze positie om die keuze te mogen maken...

@TS: 't Ziet eruit alsof het disk gerelateerd is (op Crazymonkey's SSD wel snel)
Kun je die databases of die virtuele machien een eigen spindle geven?

[Razwer]

Brahiewahiewa schreef op zondag 13 januari 2013 @ 13:40:
[...]

Niet iedereen verkeert in de luxueuze positie om die keuze te mogen maken...

Mjah maar dan moet je niet zeuren of slechte performance. Als IT pro deel ik hier mijn kennis en ervaring. De issue ligt niet zo zeer aan de storage maar aan de integration tools en hoe de storage wordt aangesproken. Crazymonky zal vast geen OpenSuse gebruiken bijvoorbeeld en is dus waarschijnlijk de implementatie van de integration tools net iets anders (zoals vaak met Linux, het heet hetzelfde, maar het werkt toch ff net wat anders).
Ik durft te wedden (is trouwens meteen ook een goede test) dat als je vmware workstation op je hyper-v host zet en die mysql bak in vmware knikkerd dat de performance een stuk beter is. Zo niet moet je het in de hardware/host OS kant zoeken

[Priet]

Brahiewahiewa schreef op zondag 13 januari 2013 @ 13:40:
[...]

Niet iedereen verkeert in de luxueuze positie om die keuze te mogen maken...

Razwer schreef op zondag 13 januari 2013 @ 15:23:
[...]

Mjah maar dan moet je niet zeuren of slechte performance. Als IT pro deel ik hier mijn kennis en ervaring.

En die wordt zeker gewaardeerd We draaien helaas Hyper-V hier. Het viel mij op dat MySQL op 2012 erg traag draait, terwijl het op 2008 (en oudere hardware) wel fatsoenlijk loopt.

Razwer schreef op zondag 13 januari 2013 @ 15:23:
Crazymonky zal vast geen OpenSuse gebruiken bijvoorbeeld

Ik ben benieuwd welke Linux distro Crazymonky gebruikt

Brahiewahiewa schreef op zondag 13 januari 2013 @ 13:40:
@TS: 't Ziet eruit alsof het disk gerelateerd is (op Crazymonkey's SSD wel snel)
Kun je die databases of die virtuele machien een eigen spindle geven?

Razwer schreef op zondag 13 januari 2013 @ 15:23:
Ik durft te wedden (is trouwens meteen ook een goede test) dat als je vmware workstation op je hyper-v host zet en die mysql bak in vmware knikkerd dat de performance een stuk beter is. Zo niet moet je het in de hardware/host OS kant zoeken

Ik heb ESXi 4.1 eens aangetrapt en een VM op de SSD schijf aangemaakt: gaat als de brandweer. Resultaten in 0.00s. Echter op de HD (NFS van NexentaStor/ZFS) gaat het ook weer traag. Hmmm...

Wellicht moet ik meer in de richting van de drive cache zoeken. Misschien moet het aan, of juist uit? Even wat testen draaien...

[Meekoh]

Op de hardware Intel VT-D aangezet in de BIOS? (als je dat hebt)
En gebruik je VHD schijven of de nieuwe VHDX schijven?

edit: als ik tijd heb zal ik even op mijn hyper-v 2012 server proberen dit te reproduceren.

[ Voor 28% gewijzigd door Meekoh op 14-01-2013 11:40 ]

[Crazymonkey]

distro is Ubuntu 12.04 LTS

[ Voor 11% gewijzigd door Crazymonkey op 14-01-2013 15:22 ]

[Zwelgje]

maak je wellicht gebruik van de oudere integration services die suse wellicht meelevert in dat geval kan je eens de nieuwste linux integration componenten downloaden bij Microsoft en die eens proberen.

http://www.microsoft.com/...oad/details.aspx?id=34603

[Priet]

Excuses voor de late reactie, de SSD op m'n desktop had het begeven dus dat werd lastig testen...

Meekoh schreef op maandag 14 januari 2013 @ 11:38:
Op de hardware Intel VT-D aangezet in de BIOS? (als je dat hebt)
En gebruik je VHD schijven of de nieuwe VHDX schijven?

edit: als ik tijd heb zal ik even op mijn hyper-v 2012 server proberen dit te reproduceren.

Ik heb vandaag ook op een andere PC getest: Core 2 Duo 6600 (m'n destop die in puin lag): met een nieuwe SSD en een 'normale' 500 GB HD. Deze heeft geen VT-D, de andere servers wel en daar staat het ingeschakeld.

Echter zijn de resultaten niet erg verschillend tussen de servers. Het installeren op de Core2Duo gaat wel een stuk langzamer, maar MySQL laat dezelfde resultaten zien.

Ik heb VHD en VHDX geprobeerd, zowel dynamisch als statisch. Dat maakt geen verschil in snelheid.

Wanneer ik de VHD(X) op een SSD zet, of wanneer ik de VM de volledige SSD als physical disk toewijs zijn de resultaten bijna gelijk aan een fysieke server en ESXi/Proxmox/VirtualBox. Het is net iets trager, maar het blijkt in honderdsten van een seconde (0,01 t/m 0,08s) ipv de tienden van een seconde (0,1 t/m 0.8) wanneer de VM's op de normale HD geplaatst worden.

Crazymonkey schreef op maandag 14 januari 2013 @ 15:20:
distro is Ubuntu 12.04 LTS

Ook maar even geïnstalleerd (Ubuntu Server). En ook daar dezelfde resultaten als met Suse.

Powershell schreef op maandag 14 januari 2013 @ 21:06:
maak je wellicht gebruik van de oudere integration services die suse wellicht meelevert in dat geval kan je eens de nieuwste linux integration componenten downloaden bij Microsoft en die eens proberen.

http://www.microsoft.com/...oad/details.aspx?id=34603

Ik gebruik de nieuwste LIS die OpenSUSE meelevert (zie ook Priet in "\[Hyper-V 2012] MySQL traag in Linux VM"). De link wijst naar 3.4, maar die is alleen onder CentOS te installeren. Ik heb CentOS ook getest met deze versie, maar dat maakt geen verschil tov Suse.

Het lijkt erop dat de HD de bottleneck is. Wat doet een Hyper-V waar een andere hypervisor totaal niet moeilijk over doet

[Priet]

Ik ben verder gegaan met het testen op verschillende machines met verschillende configuraties. Een aantal bevindingen:

• Het probleem doet zich voor op zowel Hyper-V 2008 als Hyper-V 2012 machines
• Het VM OS maakt geen verschil
• Versies van kernel en Linux Integration Tools maken geen verschil
• Het probleem doet zich niet voor op ESXi/KVM/bare metal
• Het probleem doet zich niet voor op Hyper-V met een RAID controller

Een aantal servers waarop ik heb kunnen testen zijn van het type Dell PowerEdge T110 met een Perc S100 RAID controller. Een andere server is een verouderde Dell PowerEdge 840 met een Perc 5i controller. Beiden types doen hun werk erg snel, vergelijkbaar met ESXi/KVM.

In die oude PowerEdge 840 heb ik een externe harde schijf via USB 2.0 aangesloten. De VHD heb ik naar deze schijf (NTFS) verplaatst. De resultaten zijn niet zo snel als op de normale schijf, maar met honderdsten van een seconde zijn dit alleszins zeer redelijke resultaten

Tot zover mijn theorie dat het aan de RAID controller zou liggen. Want de USB schijf zou deze toch niet gebruiken?

Ik neig naar de conclusie dat het probleem door een of andere disk write cache veroorzaakt wordt. Waarom en wanneer is mij op dit punt nog een raadsel. Ik snap ook nog te weinig van de materie... dus we duiken er weer in...

[Priet]

GEVONDEN!!

Op het tabblad Write-caching policy (eigenschappen van de harddisk) staan twee vinkjes:

code:

[x] Enable write caching on the device
[ ] Turn off Windows write-cache buffer flushing on the device

Dat tweede vinkje heb ik nu ook aangezet en de resultaten zijn direct zichtbaar: de queries worden nu in 0.00s uitgevoerd

Op de Dell servers stond dat tweede vinkje ook uit. Kan het zijn dat de RAID controller uit zichzelf de buffer flushing uitschakelt ondanks verzoeken van Windows?

[Razwer]

Normaal gesproken wil je ook geen write cache op een array. Dit kan namelijk zeer kwalijke gevolgen hebben bij een spontane reboot/power cut/bsod. De write cache wordt geregeld door je array controller (transparant voor je OS) en daarvoor heb je (meestal) weer BBWC voor nodig. Zonder BBWC zit je weer met dezelfde gevaren als ik eerder noemde.
In principe helpt windows je dus door write cache uit te zetten op je array

[ Voor 3% gewijzigd door Razwer op 17-01-2013 14:59 ]

[Priet]

Mocht dit topic ooit nog naar boven komen in een zoektocht: ik wilde hetzelfde configureren op een Hyper-V Server 2012. Zonder GUI heb je de tool dskcache.exe nodig (download op Microsoft Support).

Vervolgens draaien met dskcache om info te zien. Als het goed is staat de tweede regel op disabled. Om op enabled te zetten: dskcache.exe +p. Of geef extra parameters op om een enkele schijf te selecteren ipv allemaal.

Zie ook: http://social.technet.mic...d3-495b-b384-6c0a9e9b01be

[Razwer]

tof van die tool, die kende ik nog niet, maar het mooie aan Server 2012 is natuurlijk dat je tijdelijk de GUI gewoon terug kan knallen en als je klaar bent die er weer af smijten

[Priet]

Niet met de Hyper-V Server versie ;-)

Werken met de core-versie vergt toch wel enige gewenning. Even de hardware-lijst uitlezen is er niet bij, of even het huidige CPU en geheugen gebruik opvragen ook niet. Het zou handig zijn als je ook in de taskmanager een andere server op kon geven dan de lokale computer.

/Edit: wat ik nog niet snap: dat tweede vinkje (Turn off Windows write-cache buffer flushing on the device), hoe doen andere OS-en dat? Hebben die automatisch het gedrag wat Windows vertoont als het vinkje aan staat? Ik lees overal dat het vinkje potentieel gevaarlijk is, maar is uitzetten een extra beveiliging ten opzichte van andere OS-en?

[ Voor 36% gewijzigd door Priet op 23-01-2013 19:24 ]