V tomto příspěvku budu diskutovat o obecné metodice pro řešení problémů s výkonem CPU. Rád používám metodiky ve výchozím nastavení a také se mi líbí budování efektivity v tom, jak řeším problémy na základě minulých zkušeností. Bez obecného rámce je příliš snadné přehlédnout skutečnou příčinu uprostřed krize.
Kroky, které popíšu v tomto příspěvku, jsou následující:
- Definujte problém
- Ověřte aktuální podmínky
- Odpovězte „Je to SQL Server“?
- Identifikujte spotřebitele CPU
- Přizpůsobte vzor a vyřešte
Tento článek se bude zabývat každým z těchto kroků. Vycházím z předpokladu, že možná nepoužíváte monitorovací nástroj třetí strany. Pokud ano, zde uvedený rámec stále platí, ale zdroje dat a nástroje, které máte k dispozici, se budou lišit od toho, co popisuji.
Definujte problém
Nejprve musíme problém obsáhnout. Když za vámi někdo přijde a řekne, že vidí problém s výkonem CPU, může to znamenat mnoho různých věcí. Prvním úkolem je tedy pochopit, jaká je v současnosti povaha problému s výkonem CPU.
Některé běžné kategorie zahrnují:
- Dostupnost je ovlivněna „zavěšenými CPU“. Například – všechny plánovače běží na 100 % a propustnost je zastavena nebo výrazně snížena.
- Snížení výkonu v důsledku „vyššího než normálního“ využití procesoru. Nejsme tedy fixováni, ale vaše CPU běží na vyšší procento než je běžné a pravděpodobně to má vliv na výkon.
- Další běžnou kategorií problémů s výkonem procesoru je scénář „vítězové a poražení“, kdy si pracovní zátěže navzájem konkurují. Možná máte pracovní zátěž OLTP, která se potýká se sníženou propustností v důsledku paralelně spouštěného dotazu na sestavu.
- Dalším problémem může být nalezení bodu zvratu – kdy v určitém bodě narazí na celkovou kapacitu a omezení škálovatelnosti vašeho systému.
Zmiňuji tyto zastřešující kategorie jako výchozí bod, ale vím, že v těchto otázkách mohou často existovat silné závislosti a jedna kategorizace se může prolínat s druhou. Prvním krokem je tedy co nejjasněji definovat symptomy a problémy.
Ověřte aktuální podmínky
Ať už k problému došlo v minulosti nebo se děje právě teď, je důležité získat co nejvíce základních informací o systému, pracovní zátěži a konfiguracích. Pokud používáte základní linie a run-booky, v ideálním případě již většinu těchto informací sledujete. Pokud ne, zeptejte se sami sebe, jak rychle byste mohli dostat odpovědi na tyto otázky ve 2:00 uprostřed krize.
Následující podsekce pokrývají důležité datové body, které mě obvykle zajímají v souvislosti s problémem s výkonem CPU.
- Kolik soketů a jader?
- Je hyper-threading povolen?
- Jaký je model procesoru, architektura (32bitový/64bitový)?
- Je toto virtuální host?
- Pokud ano, nyní vás také budou zajímat podrobnosti o hostiteli a dalších virtuálních hostech, se kterými sdílíte zdroje.
- Jsou v platnosti nějaká nastavení související s CPU?
- Například procesor Hyper-V
- Kolik vCPU je přiděleno mezi hosty?
- Kolik vCPU má tento host?
- Byl host nedávno před problémem migrován na nového hostitele?
- Nastavení maximálního stupně paralelismu
- Práh nákladů pro možnost paralelismu
- Nastavení afinity procesoru
- Nastavení zesílení priority
- Nastavení maximálního počtu pracovních vláken
- Nastavení odlehčeného sdružování
- Jaké je nastavení možnosti napájení? (Úroveň operačního systému, řízeno hostitelem VM nebo BIOSem)
- Vysoký výkon, vyvážení, úspora energie?
- Je nakonfigurován nad rámec výchozího nastavení?
- Vidíte nějaká neobvyklá varování nebo chyby?
Podrobnosti fyzického serveru
Podrobnosti o virtuálním serveru
Rezerva, VMware CPU Reserve, Hyper-V CPU Relative Weight a VMware CPU Shares.
Nastavení konfigurace instance SQL Server
První tři konfigurace mohou vyžadovat další diskusi. Zřídka existují absolutní hodnoty týkající se těchto nastavení.
Pokud jde o poslední tři nastavení, jako je „posílení priority“, pokud uvidím, že jsou na jiných než výchozích hodnotách, rozhodně budu tlačit na další informace o pozadí a historii.
Nastavení možností napájení CPU
Nastavení možností napájení pod „Vysoký výkon“ jsou stále velmi běžná a neměla by být ignorována u serverů, které hostují instance SQL Server.
Konfigurace správce prostředků
Stále zjišťuji, že je vzácné se setkat se zákazníky, kteří tuto funkci vůbec používají, ale je snadné ověřit, zda je používána a bude stát za to v době, kdy je skutečně nakonfigurována nad rámec výchozího nastavení.
Protokol chyb serveru SQL Server a protokoly událostí systému Windows
Proč hledat problém s CPU v protokolech chyb a událostí? Problémy s odesíláním dat mohou někdy způsobit problémy s výkonem na serveru SQL Server. Nechcete ztrácet čas laděním dotazu nebo přidáváním nového indexu, když máte problém s hlavní příčinou problému degradace hardwarové komponenty.
Odpovězte „Je to SQL Server?“
Když se na to zeptám, zní to samozřejmě, ale opravdu nechcete trávit značné množství času řešením problému s vysokým CPU na serveru SQL Server, pokud viníkem není ve skutečnosti SQL Server.
Místo toho věnujte rychlou chvíli kontrole, který proces spotřebovává nejvíce CPU. Na výběr je několik možností, včetně:
- Proces:% času uživatele (uživatelský režim)
- Proces:% privilegovaného času (režim jádra)
- Správce úloh
- Proces Explorer
- Nejnovější informace o CPU prostřednictvím sys.dm_os_ring_buffers nebo relace stavu systému pro konkrétní instance SQL Server spuštěné v systému
Pokud se jedná o SQL Server a máte na výběr více instancí SQL Serveru, ujistěte se, že řešíte problémy se správnou instancí SQL Serveru na hostiteli. Existuje několik způsobů, jak toho dosáhnout, včetně použití SELECT SERVERPROPERTY('processid') získat PID a poté jej přiřadit ke Správci úloh nebo Process Exploreru.
Jakmile potvrdíte, že se jedná o SQL Server, vidíte vysoký uživatelský čas nebo privilegovaný (kernel) čas? Opět to lze potvrdit pomocí Process:% Privileged Time (objekt sqlservr) a také Správce úloh systému Windows nebo Průzkumník procesů.
I když by problémy s dlouhým časem jádra měly být vzácné, stále vyžadují jiné cesty k řešení problémů než standardní problémy s řešením problémů CPU s časem uživatele. Některé potenciální příčiny dlouhého času jádra zahrnují vadné ovladače filtrů (antiviry, šifrovací služby), zastaralé nebo chybějící aktualizace firmwaru a ovladačů nebo vadné I/O komponenty.
Identifikujte spotřebitele CPU
Jakmile ověříte, která instance SQL Server řídí využití procesoru uživatelem v systému, existuje na webu spousta předem připravených příkladů dotazů, které byste mohli použít.
Níže je uveden seznam DMV, které lidé běžně používají v různých formách během problému s výkonem. Strukturoval jsem to ve formátu Q&A, abych vám pomohl určit, proč byste k nim měli mít přístup.
- sys.dm_exec_requests
- sys.dm_exec_sql_text
- sys.dm_exec_sessions
- sys.dm_exec_connections
- sys.dm_exec_query_plan
- sys.dm_os_waiting_tasks
- sys.dm_exec_query_stats
- Agregovat podle total_worker_time
- Definujte průměry pomocí počtu spuštění
- Pokud dochází k zátěži ad hoc, můžete seskupit podle query_hash
- K získání plánu použijte plan_handle s sys.dm_exec_query_plan
- sys.dm_os_tasks
- Seřazeno podle session_id, request_id
- sys.dm_exec_query_plan
- Podívejte se na operátory plánu – ale mějte na paměti, že se jedná pouze o odhadovaný plán
- sys.dm_exec_query_stats
- Filtrujte total_elapsed_time méně než total_worker_time
- Uvědomte si však, že to může být falešně negativní pro scénáře blokování – kdy je trvání nafouknuté kvůli čekání na zdroj
Jaké požadavky se právě provádějí a jaký je jejich stav?
Co to provádí?
Odkud to je?
Jaký je její odhadovaný plán? (ale pozor na skartování xml na systému, který je již omezený CPU)
Kdo čeká na zdroj a na co čeká?
Které dotazy zabraly nejvíce času CPU od posledního restartu?
Používá tento dotaz paralelismus?
Přiřaďte vzor a vyřešte
Pravděpodobně se tomuto konkrétnímu kroku smějete – protože tento může být nejvíce zapojený (a je to další důvod, proč jsou profesionálové na SQL Server výdělečně zaměstnáni). Existuje několik různých vzorů a souvisejících řešení – takže tento příspěvek zakončím seznamem běžnějších ovladačů problémů s výkonem procesoru, které jsem za posledních několik let viděl:
- Vysoké I/O operace (a podle mých zkušeností je to nejběžnější ovladač CPU)
- Problémy s odhadem mohutnosti (a související špatná kvalita plánu dotazů)
- Neočekávaný paralelismus
- Nadměrná kompilace / rekompilace
- Výpočetně náročná volání UDF, operace skartace
- Operace řádků po řádcích
- Činnosti souběžné údržby (např. UPDATE statistiky pomocí FULLSCAN)
S každou oblastí, kterou jsem identifikoval, je spojen velký počet výzkumných prací. Pokud jde o konsolidované zdroje, stále si myslím, že jedním z těch lepších je technický článek „Odstraňování problémů s výkonem v SQL Server 2008“, který napsali Sunil Agarwal, Boris Baryshnikov, Keith Elmore, Juergen Thomas, Kun Cheng a Burzin Patel.
Shrnutí
Jako u každé metodiky i zde existují hranice pro její využití a oblasti, kde máte právo improvizovat. Vezměte prosím na vědomí, že nenavrhuji, aby kroky, které jsem popsal v tomto příspěvku, byly použity jako pevný rámec, ale místo toho to považuji za výchozí bod pro vaše úsilí o odstraňování problémů. Dokonce i velmi zkušení odborníci na SQL Server se mohou dopustit začátečnických chyb nebo být zaujatí svými novějšími zkušenostmi s řešením problémů, takže minimální metodika může pomoci vyhnout se řešení nesprávného problému.