Brent Ozar, Microsoft Certified Master, nedávno diskutoval o paralelismu na SQL Serveru, konkrétně o čekacích typech CXPACKET a CXCONSUMER ve své poslední části seriálu Quest’s Database Training Days Fall Series. Brent svým obvyklým vtipným a přístupným způsobem demystifikoval koncepty paralelismu a vysvětlil, jak s ním zacházet, když vidíte příliš mnoho statistik čekání CXPACKET a CXCONSUMER.
Za prvé, co je paralelismus a proč SQL Server provádí dotazy paralelně?
Jednoduše řečeno, SQL Server automaticky rozpozná, že konkrétní dotaz má velké pracovní zatížení, a určí, že práci lze provádět efektivněji na více procesorech než pouze na jednom. Toto je obecně chytré rozhodnutí, ale může nastat problémy, když SQL Server nevyváží zátěž napříč vlákny provádějícími daný úkol.
Porozumění typům čekání CXPACKET a CXCONSUMER
CXPACKET a CXCONSUMER jsou typy čekání, které naznačují, že práce není rovnoměrně vyvážená. Když na svém serveru uvidíte tyto statistiky čekání, budete vědět, že SQL Server spouští dotazy paralelně, ale nedělá skvělou práci při jejich distribuci mezi dostupné procesory.
Každý databázový profesionál zná pojem „náklady“, který vyjadřuje, jak drahé je provedení dotazu z hlediska spotřeby zdrojů. Tyto „dotazy“ jsou přibližným měřítkem práce a důležitým signálem, zda dotaz poběží paralelně nebo ne. Nenákladný dotaz nebude muset běžet paralelně, ale drahý ano. Cílem je provést dotaz co nejrychleji a nejefektivněji, aby mohl začít další v řadě. SQL Server označí vlákno jako plánovač a toto vlákno, které Brent považoval za „vládce robota“, přiřadí části paralelní pracovní zátěže pracovním vláknům neboli „robotským přisluhovačům“.
Paralelismus a vládce robotů
Brent se ponořil do dema, aby ukázal, jak to funguje. Pomocí databáze Stack Overflow vytvořil levné vyhledávání databáze, které bylo velmi rychlé díky přítomnosti indexu. Prováděcí plán byl docela jednoduchý a nevyžadoval paralelní běh.
Když však zavedl vyhledávání něčeho, co nebylo v indexu, věci se změnily tím, že vynutil vyhledávání klíče pro každý řádek v shlukovém indexu tabulky. SQL Server rozpoznal, že by to bylo hodně práce, a tak zavedl paralelismus a jako takový to označil ikonou na plánu provádění. Pokud by plán provádění byl trojrozměrný, mohli byste vidět několik vláken naskládaných, ale protože tomu tak není, musíte si prohlížet statistiky, abyste viděli informace, jako jsou logická čtení prováděná každým vláknem CPU.
SQL Server však přidělil tento úkol pouze několika vláknům, ne všem. Brent vysvětlil, že vše, co se děje mimo paralelní ikonu, se děje pouze na přiřazených procesorech. Takže vlákna, která provedla počáteční čtení, jsou nyní jediná, která také provádějí vyhledávání klíčů. Vládce robotů pouze požádal několik přisluhovačů, aby provedli celý úkol, místo aby požádal všechny přisluhovače, aby se zapojili.
Dále vysvětlil, že SQL Server musí odpovídat za to, co vlákna dělají, a také sledovat, co dělá vládce robota. V prvních dnech byla všechna tato práce reprezentována jednou statistikou čekání, ale to nedávalo smysl, protože bez ohledu na to musí vládce stále čekat, dokud všechna vlákna fungují. Byl tedy představen nový typ čekání – byl to CXCONSUMER a sleduje, co dělá vlákno plánovače/overlord, zatímco CXPACKET sleduje, co dělají vlákna worker/minion.
Brent se vrátil k dotazu, aby byl ještě složitější přidáním řazení. Nyní je ještě jasnější, že paralelismus spíše způsobuje problém, než aby provoz zefektivnil. Práce se stala ještě nevyváženější na několika málo pracovních vláknech a některým dochází paměť a přelévají se na disk. Přidal spojení, čímž ještě více zatížil pracující jádra, která nedostávají žádnou pomoc od těch nepracujících. Statistiky CXPACKET nadále stoupaly.
Co můžete v této situaci dělat? K rozhodnutí o paralelismu dochází na úrovni serveru a nikoli na úrovni dotazu, takže bude vyžadovat určité změny konfigurace.
Posouzení klíčových konfigurací
Již jsme zjistili, že pokud jsou náklady na dotaz vyšší než určitá úroveň, způsobí to paralelizaci SQL Serveru. Malé dotazy jsou omezeny na jedno vlákno. Ale co kontroluje práh? Jde o vlastnost zvanou Cost Threshold for Parallelism (CTFP). Ve výchozím nastavení, pokud plán provádění určí, že náklady jsou vyšší než 5 babek dotazu, bude dotaz paralelizován. I když neexistuje žádný návod, jak to nastavit, Brent doporučuje číslo větší než 50. Tím se zbavíte paralelismu u triviálních dotazů.
Další konfigurací je maximální stupeň paralelismu (MAXDOP), který popisuje počet vláken, která SQL Server přiřadí dotazu. Výchozí hodnota je zde nula, což znamená, že SQL Server může ke spuštění dotazu použít všechny dostupné procesory, až 64. Nastavení možnosti MAXDOP na 1 omezuje SQL Server na použití pouze jednoho procesoru – ve skutečnosti vynutí provedení dotazu sériovému plánu. SQL Server doporučí hodnotu MAXDOP na základě počtu jader serveru, která máte, ale obecně má smysl nižší MAXDOP, protože nebude tolikrát, že budou potřeba všechna jádra.
Brent provedl úpravy těchto dvou konfigurací a znovu spustil svůj dotaz. Tentokrát jsme mohli vidět, že do paralelního provozu bylo zapojeno více jader. Čekací statistiky CXPACKET byly nižší, což znamenalo, že zátěž byla rovnoměrněji vyvážena mezi více jádry než dříve.
Tipy pro boj s čekacími statistikami CXPACKET a CXCONSUMER
Brent doporučuje následující kroky, pokud vidíte nadměrné statistiky čekání CXPACKET a CXCONSUMER:
- Nastavte CTFP a MAXDOP podle osvědčených postupů v oboru a poté nechte tato nastavení několik dní péct. Tím se vymaže mezipaměť plánu a přinutí SQL Server znovu sestavit plány provádění dotazů (přehodnotit náklady).
- Proveďte vylepšení indexu, která zkrátí dobu, kdy dotazy procházejí souběžně s prohledáváním a řazením. Nechte nové indexy upéct a pak hledejte dotazy, které ještě dělají hodně práce.
- Vylaďte tyto dotazy a nechte je několik dní péct.
- Nakonec, pokud je paralelismus stále vážným problémem, začněte hledat konkrétní dotazy s problémy s paralelismem.
Pro ještě lepší přehled můžete na vyžádání sledovat celý Brentův trénink na CXPACKET a CXCONSUMER statistiky čekání na vyžádání níže.