Brent Ozar, Microsoft Certified Master, besprak onlangs parallellisme in SQL Server, met name de wachttypen CXPACKET en CXCONSUMER in zijn laatste aflevering van Quest's Database Training Days Fall Series. Op zijn gebruikelijke humoristische en toegankelijke manier demystificeerde Brent de concepten van parallellisme en legde uit hoe ermee om te gaan als je te veel CXPACKET- en CXCONSUMER-wachtstatistieken ziet.
Ten eerste, wat is parallellisme en waarom zorgt SQL Server ervoor dat query's parallel worden uitgevoerd?
Simpel gezegd, SQL Server herkent automatisch dat een bepaalde query een grote werklast heeft en bepaalt dat het werk efficiënter kan worden gedaan over meerdere processors dan door slechts één. Dit is over het algemeen een slimme beslissing, maar het kan in de problemen komen wanneer SQL Server de belasting niet verdeelt over de threads die de taak uitvoeren.
Inzicht in CXPACKET- en CXCONSUMER-wachttypen
CXPACKET en CXCONSUMER zijn wachttypes die aangeven dat het werk niet in evenwicht is. Als u deze wachtstatistieken op uw server ziet, weet u dat SQL Server parallel query's uitvoert, maar dat het niet goed is ze te verdelen over beschikbare processors.
Elke databaseprofessional is bekend met het concept 'kosten' om uit te drukken hoe duur een query is om uit te voeren in termen van resourceverbruik. Deze "query-dollars" zijn een geschatte hoeveelheid werk en een belangrijk signaal of de query parallel zal worden uitgevoerd of niet. Een goedkope zoekopdracht hoeft niet parallel te lopen, maar een dure wel. Het doel is om de query zo snel en efficiënt mogelijk uit te voeren, zodat de volgende in de rij kan beginnen. SQL Server wijst een thread aan als planner, en deze thread, die Brent als de 'robot-overlord' beschouwde, zal delen van de parallelle werklast toewijzen aan de worker-threads, of de 'robot-minions'.
Parallisme en de robotoverheerser
Brent dook in een demo om te laten zien hoe dit werkt. Met behulp van de Stack Overflow-database creëerde hij een goedkope database-lookup die erg snel was vanwege de aanwezigheid van een index. Het uitvoeringsplan was vrij eenvoudig en er was geen parallellisme voor nodig.
Maar toen hij een zoekopdracht introduceerde voor iets dat niet in de index stond, veranderden de dingen door een sleutelzoekopdracht te forceren voor elke rij in de geclusterde index van de tabel. SQL Server besefte dat dit veel werk zou zijn, dus introduceerde het parallellisme en gaf het als zodanig aan met een pictogram op het uitvoeringsplan. Als het uitvoeringsplan driedimensionaal was, zou je de meerdere threads op een rij kunnen zien, maar aangezien dit niet het geval is, moet je de statistieken bekijken om informatie te zien, zoals de logische uitlezingen die door elke CPU-thread worden uitgevoerd.
SQL Server heeft deze taak echter slechts aan een paar threads toegewezen, niet allemaal. Brent legde uit dat alles wat verder gaat dan het parallelle pictogram alleen gebeurt op de toegewezen processors. Dus de threads die de eerste reads hebben uitgevoerd, zijn nu de enige die ook de key-lookups doen. De robotoverheerser vroeg slechts een paar volgelingen om de hele taak uit te voeren in plaats van alle volgelingen te vragen om mee te helpen.
Hij legde verder uit dat SQL Server rekening moet houden met wat de threads doen en ook moet volgen wat de robot-overlord doet. Vroeger werd al dit werk vertegenwoordigd door één wachtstatistiek, maar dit was niet logisch, want wat er ook gebeurt, de opperheer moet nog steeds wachten terwijl alle threads werken. Er is dus een nieuw wachttype geïntroduceerd:dit was CXCONSUMER en het houdt bij wat de planner/overlord-thread doet, terwijl CXPACKET bijhoudt wat de worker-/minion-threads doen.
Brent ging terug naar de query om het nog complexer te maken door een sortering toe te voegen. Nu wordt het nog duidelijker dat parallellisme een probleem veroorzaakt in plaats van de operatie efficiënter te maken. Het werk is nog meer uit balans geraakt over de weinige werkthreads, en sommige hebben bijna geen geheugen meer en lopen over naar de schijf. Hij voegde een join toe, waardoor de werkende kernen die geen hulp krijgen van de niet-werkende kernen nog meer worden belast. CXPACKET-statistieken bleven stijgen.
Wat kunt u doen in deze situatie? De beslissing over parallellisme vindt plaats op serverniveau en niet op queryniveau, dus er zullen enkele configuratiewijzigingen nodig zijn.
Sleutelconfiguraties beoordelen
We hebben al geleerd dat als de querykosten hoger zijn dan een bepaald niveau, SQL Server parallel loopt. Kleine query's worden beperkt tot een enkele thread. Maar wat bepaalt de drempel? Het is een eigenschap genaamd Cost Threshold for Parallelism (CTFP). Als het uitvoeringsplan bepaalt dat de kosten hoger zijn dan 5 dollar voor zoekopdrachten, wordt de zoekopdracht standaard geparalleliseerd. Hoewel er geen richtlijnen zijn om dit in te stellen, raadt Brent een getal aan dat groter is dan 50. Hiermee wordt parallellisme voor triviale zoekopdrachten verwijderd.
Een andere configuratie is de maximale mate van parallellisme (MAXDOP), die het aantal threads beschrijft dat SQL Server aan de query toewijst. De standaardwaarde is hier nul, wat betekent dat SQL Server alle beschikbare processors, tot 64, kan gebruiken om de query uit te voeren. Door de MAXDOP-optie in te stellen op 1 wordt SQL Server beperkt tot het gebruik van slechts één processor, waardoor een serieel plan wordt gedwongen om de query uit te voeren. SQL Server beveelt een MAXDOP-waarde aan op basis van het aantal servercores dat u heeft, maar over het algemeen is een lagere MAXDOP logisch omdat het niet vaak voorkomt dat alle cores nodig zijn.
Brent maakte aanpassingen aan deze twee configuraties en voerde zijn query opnieuw uit. Deze keer konden we zien dat er meer kernen betrokken waren bij de parallelle operatie. De wachtstatistieken van CXPACKET waren lager, wat betekende dat de belasting gelijkmatiger was verdeeld over meer kernen dan voorheen.
Tips voor het bestrijden van CXPACKET- en CXCONSUMER-wachtstatistieken
Brent raadt de volgende stappen aan als u overmatige CXPACKET- en CXCONSUMER-wachtstatistieken ziet:
- Stel de CTFP en MAXDOP in volgens best practices uit de branche en laat deze instellingen een paar dagen bakken. Hierdoor wordt de cache van het plan gewist en wordt SQL Server gedwongen de uitvoeringsplannen voor query's opnieuw op te bouwen (de kosten opnieuw te evalueren).
- Breng indexverbeteringen aan die de tijd verkorten dat zoekopdrachten parallel lopen om scans en sorteringen uit te voeren. Laat nieuwe indexen bakken en zoek vervolgens naar zoekopdrachten die nog steeds veel werk doen.
- Stel die zoekopdrachten af en laat ze een paar dagen bakken.
- Ten slotte, als parallellisme nog steeds een serieus probleem is, ga dan op zoek naar de specifieke vragen met problemen met parallellisme.
Voor nog meer inzicht kun je de volledige trainingssessie van Brent op CXPACKET en CXCONSUMER wachtstatistieken hieronder on-demand bekijken.