Microsoft TechEd Europe - Del 7 - Optimizing Microsoft SQL server performande in a Virtual Environment

talare: Denny Cherry
presentation: DBI317

Anteckningarna nedan är mina anteckningar live från presentationen. Detta gör att det kan vara felstavningar, felsyftningar och liknande. Jag ber om ursäkt för alla eventuella felaktigheter.
Lämna gärna en kommentar i så fall så ser jag till att ändra. :)

Felsökning:
- tänk på hur hosten ser ut. Antal CPUer i hosten och antal vCPUer i VMen.
- kolla på hosten för "cpu thrashing". om ser bra ut i VMen men hosten går upp och ned hela tiden så kan det ge problem.
- Kolla host och gäster för disk I/O latency. Det intressanta här är oftast hur många millisekunder det tar att skriva och läsa till diskarna.

Ovanstående går utmärkt att få ut både i Hyper-V eller vSphere.
för hyper-v är det oftast Performance monitor som används. i vSphere är det vCenter och ESXTOP (kör SSH mot esx-servern och kör esxtop).


Memory reservations
- Tvingar fysiskt minne att vara tillgängligt för gästen.
- Bör sättas till ett värde som motsvarar den minsta mängden minne som servern behöver för att fungera (obs: "fungera", inte "fungera optimalt".)
(Här skall sägas att om man kör en msssa reserveringar i VMware så kan man strula till det för schedulern så det är inte rekommenderat att köra enorma mängder av reserveringar om man inte vet vad man gör. Det kan bli problem, det måste inte bli problem, men man kan få problem om man har otur och då är det en utmaning att hitta)

När det gäller Minnes Deduplicering så är det en jättebra funktion för operativsystemets minne, men för minne som används av SQL så funkar det inte alls (om det inte är så att flera SQL-servrar har samma sidor i cachen).

Vanligaste problemorsakerna när det gäller virtuella SQL servar är precis som på andra virtuella servrar. Det är disk I/O som är grunden.
Om man har flera maskiner som ligger på samma LUN så kommer alla dessa att få dela prestanda med varandra. Samma saker gäller när man designar lagring för en virtuell SQL-server som om den hade varit fysisk.. Helst bör OS, Data, Log och TempDB ligga på egna diskar (i egna VHD/VMDK filer).
Om det finns autoTiering i lagringslösningen så bör den användas för OS och Data (inte Transloggar). Normalt ger detta en prestandaförbättring.


Tänk på hur övervakning sker. För att få en samlad bild behöver man ha information från flera olika källor:
- SQL server
- Gäst
- Hypervisor
- Host
- Storage

En sak att tänka på om man i VMware har lagt in Paravirtualiserade drivrutinen för storage är att performance monitor inte kommer att visa rätt siffror när det gäller skrivning till disk.
För att få rätt siffror måste man välja VMdisk i perfmon.

Några perfmon räknare:;
- Read and Writes / sec
- Seconds / Read and Write
- Disk Queue
- Page Life Expectancy
- System processor Queue (bör vara så nära noll som möjligt)
- VM Disk (VMware)
- VM Memory (VMware)