Usel skrivprestanda i ESXi med M1015 (IT)

Jag fick den dåliga idén att flytta en VM som är runt 400GB från ett datastore till ett annat. Eftersom det går så långsamt att flytta eller kopiera mellan lokala datastores så tänkte jag först suga ner den till en annan dator och sedan kopiera upp den igen. Ner gick det med ~50MB/s och på slutet, alltså typ sista 20GBen, hoppade det upp till 80MB/s av någon outgrundlig anledning.

När jag sedan skulle kopiera upp den igen så gick det med runt 4MB/s! Provade till en annan likadan disk (Seagate 7200.11 1TB) med samma resultat. Provade till ytterligaren en annan disk och där gick det lite snabbare, runt 10MB/s tror jag, men den är också snabbare (Hitachi 7K3000). Provade med ytterligare en disk, en WD Green 2TB och återigen 4MB/s. Alla dessa diskar var alltså kopplade till M1015 (IT-mode). Provade olika kontakter på SAS->SATA -kablaget.

Googlade lite och provade att skruva på Disk.DiskMaxIOSize. Provad bl a 128KB, 256KB, 512KB osv osv. Kanske borde ha testat 255KB och 511KB etc med tanke på att maxvärdet (default) är 32767KB och inte 32768KB. Det enda jag lyckades med var att sänka prestandan ytterligare.

När jag däremot kopplar samma diskar mot moderkortets SATA kommer jag upp i ~30MB/s på långsamma diskar och knappt 70MB/s mot SSD. Moderkortet är ett ASUS M4A88TD-V EVO/USB3 (SB850). Det märks att diskprestandan är bättre på denna controller.

Glömde skriva att jag provat båda PCIe-slotarna.

Jag TROR inte att den uppförde sig såhär före ESXi 5.5 :-/

Det hela blir ju ännu märkligare av att en VM (W2k8R2) på Hitachi 7K3000 ger bra skrivprestanda (runt 80MB/s kontinuerligt, högre peakar) på disken när den är kopplad till M1015 :-S Det skulle ju ev. kunna förklaras av att VMen då buffrar.

ESXi cachar ju inte skrivningar (gissningsvis inte läsningar heller) utan det är helt upp till controllern och VMens OS. Mina teorier är:

1. M1015 -HBAn ser på något vis till att disken inte använder sin inbyggda cache och ESXi väntar på att varje skrivning ska bli klar och bekräftas. Alternativt ESXi's driver för HBAn gör detta.

2. Kablaget eller HBAn är trasig, känns ganska osannolikt eftersom läsning från disk funkar ganska bra.

Hoppas inlägget blev lite begripligt iaf. Ägnade halva natten åt ovanstående :-/

Jepp, det är via ESXi så att säga (överföring via vSphere Client alltså).

Jag förstår din tanke men tyvärr kommer jag inte komma upp i några 450MB/s eftersom det rör sig om långsammare SSD:er, bl a en Intel X25-M G2 120GB

Tänkte inte ens på att jag kunde boota burken på något annat och testa Borde jag ha tänkt på...

Funkar det verkligen med gratis ESXi (dvs spärrade storage API:er)?

Here we go, det var ju ganska intressant faktiskt, samtliga diskar kopplade till moderkortet, enbart en VM igång per datastore. Nu har jag visserligen kopplat ur M1015-kortet men detta bekräftar ju att det inte är något knas med prestandan när diskarna är kopplade till moderkortets kontroller. Att överföringarna via vSphere Client inte går glimrande fort känner jag till men 4MB/s som jag fick mot datastore på M1015 är ju helt åt h*lvete.

W2k8R2 på Hitachi 7K3000 3TB:

W2k12 Intel X25M G2 120GB:

W2k12 Seagate 7200.11 1TB:

W2k12R2 Seagate 7200.11 1TB (inte samma disk som ovan):

Samma kronologiska ordning som ovan. Detta bekräftar ju att VMarna funkar bra. MEN, nu när jag återigen försöker ladda upp en fil med vSphere Client så har hastigheten på diskarna kopplade till denna HBA sjunkit till löjligt låga nivåer. 4-5MB/s. Detta gör att jag misstänker att HBAn på något vis hindrar disken från att använda sin cache eller dylikt, anledningen till att det funkar annars skulle ju kunna vara att VMen buffrar. Blir inte klok på det här - såvitt jag vet buffrar ju inte moderkortets inbyggda controller i RAM heller - så den kan inte låtsas ha någon cache...

Kablaget är ju däremot helt och HBAn är ju inte heller trasig. Det lutar åt att något är mysko med hypervisorn eller dess drivisar.

Det går löjligt långsamt att deploya en Appliance på diskar kopplade till M1015 också, likaså kändes det bra slött att installera upp en ny VM. Frågan är om VMware Tools har något med saken att göra...

Edit: håller på att sätta upp en maskin jag ska benchmarka med och utan VMware Tools - runt 5MB/s får jag när W2k12R2 kopierar filer under installationen... Bra prestanda i en VM även utan VMware Tools...

W2k8R2 på Hitachi 7K3000 3TB @ M1015(IT):

W2k12 Intel X25M G2 120GB @ M1015(IT):

W2k12 Seagate 7200.11 1TB @ M1015(IT):

W2k12R2 Seagate 7200.11 1TB @ M1015(IT) (inte samma disk som ovan):

Nej, alltså alla VMar kan vara avstängda och så fort hypervisorn själv ska skriva till diskar/SSDer kopplade till M1015 så är skrivprestandan katastrofal. När VMarna skriver går det som synes prima oavsett vilken kontroller jag sätter dom på. Det "känns som om" (snygg beskrivning för att komma från en tekniker) hypervisorn behandlar diskarna olika beroende på vilken kontroller dom är kopplade till.

Jag noterade att diskar kopplade till M1015 detekteras som "ATA Serial Attached SCSI Disk" (utom Intel SSDn) medan SSDerna kopplade till moderkortets controller detekteras som "Local ATA Disk". Inte konstigt eftersom det är en SAS HBA men frågan är om det är förklaringen.

Är det någon annan som skulle kunna testa att ladda upp en större fil mot en disk kopplad till M1015 och se om ni också får horribla prestanda? Har provat att skapa om datastore på diskarna och allt möjligt men det gör ingen skillnad. Nästa steg blir att flytta M1015 till en annan burk och installera ESXi på den bara för att se om problemet följer med HBAn.

Ja, när jag kopierar upp ISOs när diskarna sitter på moderkortets controller går det ju i 30MB/s (megabyte alltså)... Men 4 när samma diskar sitter på M1015.

Tror jag hittat svaret, om han har rätt så bekräftar det min teori (se nedre delen av inlägget):

https://communities.vmware.com/message/2057088#2057088

Nu är bara frågan VARFÖR moderkortets controller är betrodd att använda cachen men inte M1015...

Om detta är korrekt så har vi ju en rimlig förklaring iaf. Tyvärr

https://communities.vmware.com/message/2343104#2343104

Får se om det kanske är läge att sälja M1015 istället. Har ingen större nytta av det pga "handikappet".

Tyvärr tvivlar jag starkt på att det hjälper, jag tror det måste till en cache eller i vart fall att disken tillåts använda sin egen. Teoretiskt lär man väl max få dubbla farten (med två diskar). Nu har jag löst min lagring med en NAS sedan M1015 införskaffades så jag klarar mig egentligen med de 6st SATA som sitter på moderkortet och där får jag ju bra prestanda.

Iofs får jag ju bra prestanda på VMarna när väl OS och sånt är installerat även om datastoret är kopplat till M1015 men det är ju lite irriterande att man isf måste koppla om disken fysiskt.

Jag vet, men det är den enda rimliga förklaringen jag kan se Dock verkar de flesta köra passthrough till en VM och isf får man ju inte det här problemet - såvida inte VMen behandlar disken på samma sätt som ESXi (dvs helt utan buffert).

Ganska enkelt - jag har inte för avsikt att köra mjukvaruRAID utan skaffade M1015 för att få fler SATA-anslutningar, så det skulle inte lösa mitt problem. Tänker inte göra det så komplext att jag har en VM som övriga VMar på host:en är beroende av, det motverkar syftet med virtualisering litegranna kan jag tycka.

Jag kör bara "tjockisar".

Jepp - såvida inte VMens OS inte heller använder egen cache för skrivning till disk för då får man ju samma effekt.