Een van de meest voorkomende prestatieknelpunten die ik als adviseur zie, zijn de ontoereikende prestaties van het opslagsubsysteem. Er zijn een aantal redenen voor slechte opslagprestaties, maar het is altijd een nuttige oefening om het te meten en te begrijpen wat er moet worden gemeten en gecontroleerd.
Er zijn eigenlijk drie hoofdstatistieken die het belangrijkst zijn als het gaat om het meten van de prestaties van het I/O-subsysteem:
Latentie
De eerste statistiek is latentie, wat simpelweg de tijd is die een I/O nodig heeft om te voltooien. Dit wordt vaak responstijd of servicetijd genoemd. De meting begint wanneer het besturingssysteem een verzoek naar de schijf (of de schijfcontroller) stuurt en eindigt wanneer de schijf klaar is met het verwerken van het verzoek. Het lezen is voltooid wanneer het besturingssysteem de gegevens ontvangt, terwijl het schrijven is voltooid wanneer het station het besturingssysteem laat weten dat het de gegevens heeft ontvangen.
Voor schrijfbewerkingen kunnen de gegevens zich nog steeds in een DRAM-cache op de schijf of schijfcontroller bevinden, afhankelijk van uw cachingbeleid en hardware. Write-back-caching is veel sneller dan write-through-caching, maar er is een batterijback-up voor de schijfcontroller vereist. Voor gebruik van SQL Server moet u ervoor zorgen dat u, indien mogelijk, gebruikmaakt van terugschrijfcaching in plaats van terugschrijfcache. U wilt er ook zeker van zijn dat uw hardwareschijfcache daadwerkelijk is ingeschakeld, aangezien sommige hulpprogramma's voor schijfbeheer van leveranciers deze standaard uitschakelen.
Invoer-/uitvoerbewerkingen per seconde (IOPS)
De tweede statistiek is Input/Output Operations per Second (IOPS). Deze statistiek is direct gerelateerd aan latentie. Een constante latentie van 1 ms betekent bijvoorbeeld dat een schijf 1.000 IO's per seconde kan verwerken met een wachtrijdiepte van 1. Naarmate er meer IO's aan de wachtrij worden toegevoegd, neemt de latentie toe. Een van de belangrijkste voordelen van flash-opslag is dat het parallel kan lezen/schrijven naar meerdere NAND-kanalen, samen met het feit dat er geen elektromechanische bewegende delen zijn die schijftoegang vertragen. IOPS is in feite gelijk aan de wachtrijdiepte gedeeld door de latentie, en IOPS op zichzelf houdt geen rekening met de overdrachtsgrootte voor een afzonderlijke schijfoverdracht. U kunt IOPS vertalen naar MB/sec en MB/sec naar latentie, zolang u de wachtrijdiepte en overdrachtsgrootte kent.
Sequentiële doorvoer
Sequentiële doorvoer is de snelheid waarmee u gegevens kunt overbrengen, meestal gemeten in megabytes per seconde (MB/sec) of gigabytes per seconde (GB/sec). Uw sequentiële doorvoermetriek in MB/sec is gelijk aan de IOPS maal de overdrachtsgrootte. 556 MB/sec is bijvoorbeeld gelijk aan 135.759 IOPS maal een overdrachtsgrootte van 4096 bytes, terwijl 135.759 IOPS maal een overdrachtsgrootte van 8192 bytes 1112 MB/sec sequentiële doorvoer zou zijn. Ondanks het dagelijkse belang voor SQL Server, komt de sequentiële schijfdoorvoer vaak tekort in bedrijfsopslag, zowel door opslagleveranciers als door opslagbeheerders. Het komt ook vrij vaak voor dat de eigenlijke magnetische schijven in een direct aangesloten opslag (DAS)-behuizing of een Storage Area Network (SAN)-apparaat zo druk zijn dat ze niet hun volledige nominale sequentiële doorvoer kunnen leveren.
Sequentiële doorvoer is van cruciaal belang voor veel algemene databaseserveractiviteiten, waaronder volledige databaseback-ups en -herstel, het maken en opnieuw opbouwen van indexen en grote sequentiële leesscans van het type datawarehouse (wanneer uw gegevens niet in de SQL Server-bufferpool passen). Een prestatiedoel waar ik graag naar streef bij het bouwen van nieuwe databaseservers, is om ten minste 1 GB/sec sequentiële doorvoer te hebben voor elke afzonderlijke stationsletter of koppelpunt. Het hebben van dit prestatieniveau (of beter) maakt uw leven als databaseprofessional zoveel gemakkelijker. Het maakt zoveel van uw gewone databasetaken zoveel sneller, en het geeft u ook de vrijheid om vaker indexafstemmingen uit te voeren wanneer u een index op een grote tafel kunt maken in seconden of minuten in plaats van uren.
SQL Server I/O-werkbelastingstatistieken
Als het gaat om SQL Server- en I/O-prestaties, zijn er een aantal dingen die u in de loop van de tijd moet meten en bewaken. U moet de lees- versus schrijfverhouding kennen voor uw werkbelasting voor al uw gebruikersdatabasebestanden en voor tempdb. De verhoudingen zijn verschillend voor verschillende SQL Server-bestandstypen en workloads. U kunt mijn DMV-diagnosequery's gebruiken om dit te bepalen, en u kunt ook de schijfactiviteitsweergave in SQL Sentry Performance Advisor gebruiken om eenvoudig een vollediger beeld te krijgen van uw schijfactiviteit, van een algemeen beeld op hoog niveau, helemaal naar beneden naar individuele bestanden:
SQL Sentry Performance Advisor:schijfactiviteit
U moet ook de typische I/O-snelheden voor IOPS en sequentiële doorvoer meten. In Windows Performance Monitor (PerfMon) tonen lezen/sec en schrijven/sec IOPS, terwijl schijfleesbytes/sec en schijfschrijfbytes/sec de sequentiële doorvoer vertegenwoordigen. U moet PerfMon gebruiken om de gemiddelde schijfseconden/lezen en de gemiddelde schijfseconden/schrijven te meten, dit is lees- en schrijflatentie op schijfniveau. Ten slotte kunt u mijn DMV-diagnosequery's gebruiken om de gemiddelde lees- en schrijflatentie op bestandsniveau te meten voor al uw gebruikersdatabasebestanden en voor tempdb.
Methoden voor het meten van I/O-prestaties
U kunt de sectie Schijf in Windows Resource Monitor gebruiken om een snelle, realtime weergave te krijgen van enkele belangrijke schijfstatistieken voor al uw SQL Server-databasebestanden. Als u dieper gaat, kunt u PerfMon gebruiken om de kritieke prestatiemeteritems die ik eerder heb genoemd, te meten en te bewaken. Voordat u met een nieuwe databaseserver in productie gaat, moet u een aantal schijfbenchmarktests uitvoeren om te bepalen welke prestaties uw I/O-subsysteem daadwerkelijk kan leveren. Dit is eigenlijk niet zo moeilijk of tijdrovend (als je de juiste tools gebruikt), maar het wordt vaak vergeten wanneer een nieuwe databaseserver wordt ingericht en getest.
De eerste schijfbenchmark die u altijd moet uitvoeren, is CrystalDiskMark 4.0, die onlangs is herschreven om het relatief nieuwe schijfbenchmarkprogramma Microsoft DiskSpd te gebruiken. Met de gebruikersinterface van CDM 4.0 kunt u een breder scala aan testbestandsgroottes kiezen en kunt u ook de wachtrijdiepte en het aantal threads voor de testruns kiezen. Hierdoor krijgt u een meer serverachtige I/O-workload en kunt u nieuwere NVMe-flashopslagapparaten die wachtrijen van meer dan 32 aankunnen, beter belasten.
CrystalDiskMark 4.03 Resultaten met QD =32 en threads =1
Figuur 2:CrystalDiskMark 4.03 resultaten met QD =32 en threads =4
In tegenstelling tot eerdere versies van CDM, staan de twee meest relevante rijen voor SQL Server-gebruik in het midden van de resultatenweergave. Dit zijn de 4K willekeurige lees- en schrijfbewerkingen met een hoge wachtrijdiepte (standaard 32), en de sequentiële lees- en schrijfbewerkingen. Nadat u enkele opslagbenchmark-tests met CrystalDiskMark 4.0 hebt uitgevoerd, zou u wat meer uitgebreide tests moeten doen met Microsoft DiskSpd. In een toekomstig artikel zal ik bespreken hoe u DiskSpd kunt gebruiken om completere tests voor SQL Server uit te voeren.