En av de saker som samtidigt är fantastiska och hemska med Internet är att när något väl har publicerats i etern så försvinner det i princip aldrig. (En dag kommer politikerna att inse detta. Vi kan enkelt kontrollera deras konsistens.) På grund av lång livslängd för innehåll som läggs upp på Internet, blir många ämnen för prestationsjustering "zombies". Vi skjuter ihjäl dem, men de kommer tillbaka hela tiden!
Med andra ord, de gamla rekommendationerna var en föreslagen bästa praxis för länge sedan, för en specifik version av SQL Server, men är nu olämplig för den nyare versionen. Det är inte ovanligt att jag, när jag talar på en konferens, stöter på någon som fortfarande håller fast vid inställningar och tekniker som inte har varit god praxis sedan SQL Server 2000:s dagar. SQL Server 2000 Operations Guide on Capacity/Storage innehåller många " bästa praxis" rekommendationer som var mycket versionsspecifika och inte längre gäller idag.
Så här är ett exempel. % Disk Time och Disk Queue Length PerfMon-räknare rekommenderades starkt som nyckelprestandaindikatorer för I/O-prestanda. SQL Server kastar mycket I/O på diskarna med hjälp av scatter/gather för att maximera utnyttjandet av det diskbaserade I/O-undersystemet. Detta tillvägagångssätt leder till korta skurar av långa ködjup under kontrollpunkter och läs framåt för en instans av SQL Server. Ibland är serverns arbetsbelastning sådan att din disk inte kan hålla jämna steg med I/O som trycks på den och när det händer kommer du också att se långa kölängder. Det korta scenariet är inget problem. Scenariot för att förlänga kölängden är vanligtvis ett problem. Så är det en bra praxis?
Med ett ord, inte så mycket.
Dessa räknare kan fortfarande vara till viss nytta på en instans av SQL Server som bara har en hårddisk (även om det är överdrivet mycket sällsynt nuförtiden). Varför?
PerfMon-räknaren % Disk Time är ett falskt prestandamått av flera anledningar. Den tar inte hänsyn till asynkrona I/O-förfrågningar. Den kan inte säga vad den verkliga prestandaprofilen för en underliggande RAID-uppsättning kan vara, eftersom de innehåller flera hårddiskar. PerfMon-räknaren Disk Queue Length är också mestadels värdelös, förutom på SQL-servrar med en enda fysisk disk, eftersom hårddiskkontrollerns cache fördunklar hur många I/O-operationer som faktiskt väntar i kön eller inte. Faktum är att vissa hårddiskar även har små skrivcacher också, vilket ytterligare gör vattnet smutsigt för om I/O verkligen är i kö, i en cache någonstans mellan operativsystemet och disken, eller äntligen har tagit sig hela vägen till CMOS på disken.
Bättre I/O PerfMon-räknare
Istället för att använda dessa PerfMon-räknare, använd Avg Disk Reads/sec , Avg Disk Writes/sec och Avg Disk Transfers/sec för att spåra prestandan för diskundersystem. Dessa räknare spårar det genomsnittliga antalet läs-I/O, skriv-I/O och kombinerade läs- och skriv-I/O som inträffade under den sista sekunden. Ibland gillar jag att spåra samma mätvärden efter datavolym snarare än hastigheten för I/O-operationer. Så för att få den informationen kanske du vill ge dessa volymspecifika PerfMon-räknare ett försök: Avg Disk Transfer Bytes/sec , Avg Disk Read Bytes/sec , och Avg Disk Write Bytes/sec .
För SQL Server I/O-prestanda, använd Dynamic Management Views (DMV)
Och om du inte har bott i en grotta bör du se till att använda SQL Servers Dynamic Management Views (DMV) för att kontrollera I/O-prestanda för de senaste versionerna av SQL Server. Några av mina favorit DMV för I/O inkluderar:
- sys.dm_os_wait_stats
- sys.dm_os_waiting_tasks
- sys.dm_os_performance_counters
- sys.dm_io_virtual_file_stats
- sys.dm_io_pending_io_requests
- sys.dm_db_index_operational_stats
- sys.dm_db_index_usage_stats
Så hur spårar du I/O-prestandastatistik? Vilka använder du?
Jag ser fram emot att höra från dig!
Njut,
-Kev
–Följ mig på Twitter!