Odstraňování problémů s výkonem je umění a věda. Umění pochází ze zkušeností (a učení se ze zkušeností ostatních) a věda vychází ze známých pokynů o tom, co dělat v jakých scénářích.
Nebo si to alespoň rád myslím a učím.
Ve skutečnosti mnoho správců databází a vývojářů praktikuje to, čemu říkám „odstraňování problémů s výkonem v koleni“. To se běžně stává, když problém s výkonem dosáhne kritické fáze, například vyprší časový limit dotazů, procesy běží pomalu nebo selžou, uživatelé jsou nespokojení a management chce rychlé odpovědi a akce!
„Kleknutí“ pochází z provedení nějaké povrchní analýzy problému a unáhleného závěru (ve skutečnosti je to stébla stébla), že nejrozšířenějším příznakem musí být hlavní příčina, a pokusu o nápravu, bez nebo jen s malým výsledkem, často používají zavádějící nebo zcela nesprávné rady nalezené online. To vede ke spoustě frustrace a plýtvání časem a často vede k vyhozeným penězům, když se organizace rozhodne pokusit se problém vyřešit pomocí hardwaru upgradováním serveru a/nebo I/O subsystému, jen aby zjistila, že problém stále existuje. , nebo se znovu velmi rychle objeví.
Analýza statistiky čekání je jednou z oblastí, kde je nejsnazší trhnout kolenem, a v tomto příspěvku budu mluvit o několika běžných typech čekání a chybách, které lidé kolem nich dělají. V článku, jako je tento, není prostor zacházet do hloubky o tom, co dělat v každém případě, ale poskytnu vám dostatek informací, které vás nasměrují správným směrem.
LCK_M_XX
Většina lidí předpokládá, že pokud je nejrozšířenější čekání na zamykání, pak to musí být nějaký problém s blokováním. Často tomu tak je, jako je nedostatek vhodného indexu bez klastrů způsobující prohledávání tabulky v úrovních izolace REPEATABLE_READ nebo SERIALIZABLE, které eskaluje na zámek tabulky S. (A jako rychlá nápověda, pokud si nemyslíte, že někdy používáte SERIALIZABLE, uděláte, pokud používáte distribuované transakce – vše je pod krytem převedeno na SERIALIZABLE, což může vést k neočekávanému zablokování a uváznutí.)
Často se však stává, že blokování je způsobeno něčím jiným. Na výchozí úrovni izolace READ_COMMITTED jsou zámky pokrývající změny drženy, dokud se transakce nepotvrdí, a zablokují čtení a další aktualizace stejných řádků. Pokud něco brání transakci v potvrzení, může to způsobit, že se objeví blokování.
Pokud je například databáze synchronně zrcadlena, pak transakce nemůže potvrdit a uvolnit své zámky, dokud nebudou záznamy protokolu odeslány do zrcadla a zapsány na disk protokolu zrcadlení. Pokud je síť vážně přetížená nebo na zrcadle dochází k masivnímu I/O sporu, může to vážně zpozdit operaci zrcadlení, a tak bude trvat mnohem déle, než se transakce potvrdí. To by vypadalo jako blokování, ale hlavní příčinou je spor o zdroje týkající se zrcadlení.
V případě čekání na zamykání, pokud není příčina zřejmá z pohledu na plán dotazů, zamkněte zdroj (např. úroveň tabulky označující eskalaci uzamčení nebo úroveň izolace, postupujte podle blokovacího řetězce (pomocí skriptu, který prochází sloupcem blocking_session_id v sys.dm_exec_requests a poté podívejte se, na co vlákno v čele blokovacího řetězce čeká. To ukáže na hlavní příčinu.
ASYNC_NETWORK_IO
Název tohoto způsobuje spoustu zmatků. Na jaké slovo se zaměřujete? SÍŤ. Příčina tohoto typu čekání obvykle nemá nic společného se sítí. Mělo by se to skutečně jmenovat WAITING_FOR_APP_ACK (nowledgement) nebo něco podobného, protože přesně to se děje:SQL Server odeslal nějaká data klientovi a čeká, až klient potvrdí, že data spotřeboval.
Jednou z mých oblíbených ukázek při výuce o statistikách čekání je spustit dotaz, který vrací velkou sadu výsledků v Management Studio a sledovat, jak server načítá čekání ASYNC_NETWORK_IO. Zjevně se nejedná o žádnou síť – jen SSMS trvá dlouho, než odpovídá na SQL Server. Dělá to, co je známé jako RBAR (Row-By-Agonizing-Row), kdy je z výsledků vytahován a zpracováván vždy pouze jeden řádek, namísto ukládání všech výsledků do mezipaměti a následné okamžité odpovědi na SQL Server a pokračování ve zpracování řádky uložené v mezipaměti.
Toto je hlavní příčina čekání ASYNC_NETWORK_IO – špatný návrh aplikace. Pak bych se podíval na to, zda server, na kterém běží kód aplikace, má problém s výkonem, i když je samotný kód aplikace dobře navržen. Občas je to síť, ale to je podle mých zkušeností vzácné.
OLEDB
Obvyklou prudkou reakcí je přirovnat tento typ čekání k propojeným serverům. Tato čekací doba se však stala běžnější, když byl dodán SQL Server 2005, protože rok 2005 obsahoval řadu nových DMV a DMV většinou používají pod krytem OLE DB. Než budu hledat problémy s propojeným serverem, zkontroloval bych, zda monitorovací nástroj na serveru neustále spouští DMV.
Pokud máte propojené servery, pokračujte v odstraňování problémů tak, že přejdete na propojený server a prohlédnete si tam statistiky čekání, abyste zjistili, jaký je nejčastější problém, a poté pokračujte ve stejné analýze.
Jedna další věc, která může způsobit čekání OLEDB, je DBCC CHECKDB (a související příkazy). Ke komunikaci informací mezi svými subsystémy Query Processor a Storage Engine používá sadu řádků OLE DB.
Další čekání
Některá z dalších čekání, která způsobují trhavé reakce, jsou CXPACKET, PAGEIOLATCH_XX, SOS_SCHEDULER_YIELD a WRITELOG a těm se budu věnovat ve svém příspěvku příští měsíc.
Shrnutí
Když máte problém s výkonem, věnujte čas tomu, abyste porozuměli datům, na která se díváte, a proveďte další šetření, která vám pomohou zúžit se na hlavní příčinu problému. Nechytejte se jen toho, co se zdá být nejlepší čekací statistikou, a řiďte se první radou, na kterou narazíte online (pokud nepochází ze známého a renomovaného zdroje), jinak váš problém pravděpodobně nevyřešíte, a dokonce aby to bylo horší.
Pokud jde o obecné statistiky čekání, více informací o jejich použití pro odstraňování problémů s výkonem naleznete v:
- Série příspěvků na mém blogu, počínaje statistikou čekání, nebo mi prosím řekněte, kde to bolí
- Moje knihovna typů čekání a tříd Latch zde
- Můj online školicí kurz Pluralsight SQL Server:Odstraňování problémů s výkonem pomocí statistiky čekání
- Poradce pro výkon SQL Sentry
Toto byl první ze série příspěvků, které budu dělat v průběhu tohoto roku a které hovoří o prudkých (re)akcích kolem SQL Serveru a o tom, proč jsou špatné. Do příště přejeme hodně štěstí při odstraňování problémů!