Een van de dingen die tegelijkertijd geweldig en afschuwelijk zijn aan internet, is dat als iets eenmaal in de ether wordt gepost, het eigenlijk nooit meer weggaat. (Op een dag zullen politici dit beseffen. We kunnen eenvoudig hun consistentie controleren.) Vanwege de lange levensduur van inhoud die op internet wordt geplaatst, worden veel onderwerpen over prestatieafstemming 'zombies'. We schieten ze dood, maar ze blijven terugkomen!
Met andere woorden, die oude aanbevelingen waren een aanbevolen best practice lang geleden, voor een specifieke versie van SQL Server, maar zijn nu niet geschikt voor de nieuwere versie. Het is niet ongebruikelijk dat ik, wanneer ik op een conferentie spreek, iemand tegenkomt die zich nog steeds vastklampt aan instellingen en technieken die sinds de dagen van SQL Server 2000 geen goede gewoonte waren. De SQL Server 2000 Operations Guide on Capacity/Storage bevat veel " 'best practice'-aanbevelingen die erg versiespecifiek waren en vandaag niet meer van toepassing zijn.
Dus hier is een voorbeeld. De % Disk Time en Disk Queue Length PerfMon-tellers werden sterk aanbevolen als belangrijke prestatie-indicatoren voor I/O-prestaties. SQL Server gooit veel I/O naar de schijven met behulp van scatter/gather om het gebruik van het schijfgebaseerde I/O-subsysteem te maximaliseren. Deze aanpak leidt tot korte uitbarstingen van lange wachtrijen tijdens checkpoints en read-aheads voor een exemplaar van SQL Server. Soms is de serverbelasting zo groot dat uw schijf de I/O die erop wordt geschoven niet kan bijhouden en als dat gebeurt, ziet u ook lange wachtrijen. Het korte burst-scenario is geen probleem. Het scenario van langere wachtrijlengte is meestal een probleem. Dus is dat een goede gewoonte?
In één woord, niet zo veel.
Die tellers kunnen nog steeds enig nut hebben op een instantie van SQL Server die maar één harde schijf heeft (hoewel dat buitengewoon is zeldzaam tegenwoordig). Waarom?
De PerfMon-teller % Disk Time is om verschillende redenen een valse prestatiemaatstaf. Er wordt geen rekening gehouden met asynchrone I/O-verzoeken. Het kan niet zeggen wat het echte prestatieprofiel voor een onderliggende RAID-set kan zijn, omdat ze meerdere schijven bevatten. De PerfMon-teller Disk Queue Length is ook meestal nutteloos, behalve op SQL-servers met een enkele fysieke schijf, omdat de cache van de harde schijf-controller verdoezelt hoeveel I/O-bewerkingen daadwerkelijk in behandeling zijn in de wachtrij of niet. Sommige harde schijven hebben zelfs kleine schrijfcaches, wat het water verder vertroebelt om te bepalen of de I/O echt in de wachtrij staat, in een cache ergens tussen het besturingssysteem en de schijf, of het uiteindelijk helemaal heeft gehaald naar de CMOS op de schijf.
Betere I/O PerfMon-tellers
Gebruik in plaats van die PerfMon-tellers de Avg Disk Reads/sec , Avg Disk Writes/sec , en Avg Disk Transfers/sec om de prestaties van schijfsubsystemen te volgen. Deze tellers houden het gemiddelde aantal lees-I/O's, schrijf-I/O's en gecombineerde lees- en schrijf-I/O's bij dat in de laatste seconde heeft plaatsgevonden. Af en toe volg ik graag dezelfde statistieken op basis van het gegevensvolume in plaats van de snelheid van I/O-bewerkingen. Om die gegevens te krijgen, kunt u deze volumespecifieke PerfMon-tellers eens proberen: Avg Disk Transfer Bytes/sec , Avg Disk Read Bytes/sec , en Avg Disk Write Bytes/sec .
Gebruik Dynamic Management Views (DMV) voor SQL Server I/O-prestaties
En tenzij u in een grot hebt geleefd, moet u ervoor zorgen dat u de Dynamic Management Views (DMV's) van SQL Server gebruikt om de I/O-prestaties voor recente versies van SQL Server te controleren. Enkele van mijn favoriete DMV's voor I/O zijn:
- 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
Dus hoe houdt u de I/O-prestatiestatistieken bij? Welke gebruik je?
Ik hoor graag van je terug!
Veel plezier,
-Kev
–Volg mij op Twitter!