En af de ting, der samtidig er fantastisk og forfærdeligt ved internettet, er, at når først noget bliver lagt ud i æteren, forsvinder det stort set aldrig. (En dag vil politikerne indse dette. Vi kan nemt kontrollere deres konsistens.) På grund af lang levetid for indhold, der er lagt ud på internettet, bliver mange emner til justering af ydeevne "zombier". Vi skyder dem ihjel, men de bliver ved med at komme tilbage!
Med andre ord, de gamle anbefalinger var en foreslået bedste praksis for længe siden, for en specifik version af SQL Server, men er nu upassende til den nyere version. Det er ikke ualmindeligt, at jeg, når jeg taler til en konference, støder på nogen, der stadig klamrer sig til indstillinger og teknikker, som ikke har været god praksis siden dagene med SQL Server 2000. SQL Server 2000 Operations Guide on Capacity/Storage indeholder mange " bedste praksis", som var meget versionsspecifikke og ikke længere gælder i dag.
Så her er et eksempel. % Disk Time og Disk Queue Length PerfMon-tællere blev stærkt anbefalet som nøglepræstationsindikatorer for I/O-ydelse. SQL Server kaster en masse I/O på diskene ved hjælp af scatter/gather for at maksimere udnyttelsen af det diskbaserede I/O-undersystem. Denne tilgang fører til korte udbrud af lange kødybder under kontrolpunkter og read-aheads for en forekomst af SQL Server. Nogle gange er serverens arbejdsbyrde sådan, at din disk ikke kan følge med den I/O, der er skubbet til den, og når det sker, vil du også se lange kølængder. Det korte scenarie er ikke et problem. Scenariet med forlængelse af kølængde er normalt et problem. Så er det en god praksis?
Med et ord, ikke så meget.
Disse tællere kan stadig være nyttige på en forekomst af SQL Server, som kun har én harddisk (selvom det er overdrevent sjældent i disse dage). Hvorfor?
PerfMon-tælleren % Disk Time er en falsk præstationsmåling af flere årsager. Den tager ikke højde for asynkrone I/O-anmodninger. Den kan ikke fortælle, hvad den reelle ydeevneprofil for et underliggende RAID-sæt kan være, da de indeholder flere diskdrev. PerfMon-tælleren Disk Queue Length er også for det meste ubrugelig, undtagen på SQL-servere med en enkelt fysisk disk, fordi harddiskens controller-cache slører, hvor mange I/O-operationer, der rent faktisk venter i køen eller ej. Faktisk har nogle harddiske endda også bittesmå skrivecacher, hvilket yderligere gør vandet til, om I/O'en virkelig er i kø, i en cache et sted mellem operativsystemet og disken eller endelig har nået det hele. til CMOS på disken.
Bedre I/O PerfMon-tællere
I stedet for at bruge disse PerfMon-tællere, skal du bruge Avg Disk Reads/sec , Avg Disk Writes/sec , og Avg Disk Transfers/sec at spore ydeevnen af diskundersystemer. Disse tællere sporer det gennemsnitlige antal læse-I/O'er, skrive-I/O'er og kombinerede læse- og skrive-I/O'er, der opstod i det sidste sekund. Af og til kan jeg godt lide at spore de samme målinger efter mængden af data snarere end hastigheden af I/O-operationer. Så for at få disse data kan du prøve disse volumenspecifikke PerfMon-tællere: Avg Disk Transfer Bytes/sec , Avg Disk Read Bytes/sec , og Avg Disk Write Bytes/sec .
For SQL Server I/O-ydeevne skal du bruge Dynamic Management Views (DMV)
Og medmindre du har boet i en hule, bør du sørge for at bruge SQL Servers Dynamic Management Views (DMV'er) til at kontrollere I/O-ydeevne for nyere versioner af SQL Server. Nogle af mine foretrukne DMV'er til I/O inkluderer:
- 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å hvordan sporer du I/O-ydeevnemålinger? Hvilke bruger du?
Jeg ser frem til at høre tilbage fra dig!
God fornøjelse,
-Kev
–Følg mig på Twitter!