Pokud uživatelé vaší databáze reptali, že výkon SQL Serveru je v poslední době nevýrazný, je možné, že zažíváte účinky jednoho nebo více úzkých míst SQL Serveru. K těmto úzkým místům dochází z různých důvodů, ale často k nim dochází v důsledku problémů s pamětí, I/O nebo CPU.
Ačkoli není vždy snadné určit, zda problémy s výkonem pramení z úzkého místa SQL Serveru nebo z jiného zdroje, můžete vyhledat tyto běžné příznaky úzkých míst, které vám pomohou zúžit hledání zdroje problému.
Běžné příznaky úzkých míst serveru SQL Server
- SQL Server zatěžuje procesor
- Delší doby provádění dotazů
- Nadměrné I/O
- Protokol aplikace zobrazující zprávy o nedostatku paměti
- Extrémní aktivita na discích
- Dlouhé čekací doby na I/O
Náhlý výskyt jednoho nebo více z těchto příznaků je dobrým znamením, že máte někde v systému úzké místo SQL Server. Nyní je vaším úkolem to najít.
Typy úzkých míst serveru SQL Server
Existují tři hlavní typy úzkých míst serveru SQL Server:paměť, I/O a CPU. Je důležité, aby DBA znali příčiny, příznaky a opravy každého z nich, aby mohli rychle identifikovat a odstranit úzká hrdla a minimalizovat dopad slabého výkonu. Zahrnuli jsme také některé z nejlepších počítadel výkonu ke sledování, které pomohou okamžitě identifikovat úzká místa výkonu.
Úzká místa paměti
Úzká místa paměti jsou obvykle důsledkem nedostatečných paměťových prostředků nebo činností serveru SQL Server spotřebovávajících dostupnou paměť. Mezi příznaky, na které je třeba dávat pozor, patří delší doby provádění dotazů, nadměrné I/O, zprávy o nedostatku paměti v protokolu aplikace a časté pády systému.
Nejlepšími způsoby, jak se vyhnout úzkým místům souvisejícím s pamětí, je použít optimalizátor dotazů, který se zbaví zbytečných nebo zastaralých dotazů, a nakonfigurovat očekávanou životnost stránky ve spojení s poměrem zásahů do mezipaměti, aby se omezily výlety na disk. Pokud je příliš pozdě na to, abyste se vyhnuli úzkému hrdlu, zkuste zkontrolovat a vyladit dotazy, překonfigurovat paměť nebo přidat fyzickou paměť.
Čítače ke sledování:dostupná paměť, celková paměť serveru, paměť cílového serveru, stránky/s, poměr zásahů do mezipaměti vyrovnávací paměti
Úzká místa I/O
Pokud není k dispozici dostatek úložného prostoru pro podporu běžných databázových operací, jako je TempDB, pravděpodobně dojde k úzkým místům I/O. Dlouhé doby odezvy, zpomalení aplikací a časté prodlevy úkolů jsou klíčové indikátory toho, že máte I/O úzké místo.
Tomuto typu úzkého hrdla se můžete vyhnout nastavením monitorování pomocí alarmů a upozornění na prahové hodnoty, abyste zjistili, které činnosti využívají nadměrné množství úložiště. Pokud se objeví úzké místo I/O, omezte čtení a zápis databázových stránek na disk az disku. To bude vyžadovat, abyste zkontrolovali a opravili časté prohledávání indexů, neefektivní dotazy a zastaralé statistiky.
Čítače ke sledování:průměrná délka diskové fronty, průměrný disk s/čtení, průměrný disk s/zápis, % času na disku, průměrný diskový čtení/s, průměrný zápis na disk/s
Úzká místa CPU
Hlavní příčinou úzkých míst CPU jsou nedostatečné hardwarové zdroje. Je poměrně snadné identifikovat toto úzké hrdlo kontrolou protokolů, abyste zjistili, zda SQL Server nevyužívá nadměrné množství CPU.
V ideálním světě byste se mohli vyhnout úzkým hrdlům CPU tím, že budete mít vyhrazený server pouze pro SQL Server a veškerý ostatní software spustíte na jiném počítači. Protože to není možnost pro většinu DBA, budete muset vědět, jak uvolnit svůj CPU.
Prvním krokem je identifikace prasat CPU. Jakmile budete vědět, kde je problém, můžete vyladit dotazy, zlepšit plány provádění nebo překonfigurovat systém.
Čítače ke sledování:% času procesoru, dávkové požadavky/s, kompilace SQL/s, rekompilace SQL/s
Příběh o překážkách výkonu SQL Server
"Musíme se vypořádat s některými překážkami výkonu SQL Serveru," řekl můj šéf jednoho pátek pozdě.
"Jak to víš?" zeptal jsem se.
„Prodej si stěžuje, že se jejich databáze v poslední době zpomaluje. Musíme vidět, co se s tím děje.“
"OK. Zarezervuji konferenční místnost, abychom si mohli sednout a pracovat na tom.“
"Neobtěžuj se," řekl šéf. „Je pátek odpoledne. To znamená, že nejlepší způsob, jak studovat úzká místa, je s několika vlastními. Jdeme do Pike Pub na trhu.“
Vešli jsme do baru zastrčeného na Pike Place Market a našli jsme u okna malý stolek.
"Jaký je váš oblíbený druh úzkého hrdla?" zeptal se šéf.
Řekl jsem, že jsem nakloněn Naughty Nellie v 22-uncovém úzkém hrdle.
"Dobrá volba," řekl šéf. "Objednáte si to a já si dám Citrus Summer Ale."
Zatímco jsme čekali, až dorazí naše úzká místa, pustili jsme se do práce na problémech výkonu SQL Serveru.
"Budeme muset zkontrolovat problémy na několika místech," řekl šéf. „Mohou to být problémy s pamětí, úložištěm nebo procesory, ale všechny vypadají pro uživatele přibližně stejně, že? Mizerný výkon.
"Problémy s CPU není tak těžké najít. Pokud je to problém, pak uvidíme, že SQL Server zatěžuje procesor a způsobuje, že neustále narůstá.
„Pokud se jedná o problém s pamětí, uvidíme věci, jako je delší doba provádění dotazů a více I/O, protože aplikace musí neustále docházet na disku. Můžeme také zkontrolovat protokol aplikace, zda neobsahuje zprávy o nedostatku paměti.
"A pokud je úzké místo v úložišti, uvidíme extrémní aktivitu na discích a dlouhé čekací doby na I/O."
Naše úzká místa dorazila. Pečlivě jsme je studovali, když jsme hlouběji zvažovali problém s výkonem.
Mnoho potenciálních zdrojů překážek výkonu SQL Server
"Co když je to problém I/O?" Zeptal jsem se. „Měli bychom zjistit, zda čekací doba WRITELOG není příliš vysoká ve srovnání s celkovou čekací dobou. Nebo, když už mluvíme o I/O, možná je problém v samotném SQL. Pokud existuje neefektivní kód, jako je NESTED LOOP JOIN na obrovské tabulce, SQL by mohl žádat o přečtení řádků ve vnitřní tabulce tisíckrát. To by výkon skutečně potrestalo.“
"Může být," řekl šéf. „Složité operace spojení a řazení mohou být náročné, zvláště když databáze tempdb není správně nakonfigurována. Spor Tempdb vypadá jako obyčejné zámky databáze, ale ve skutečnosti je to zadržený spor kvůli souběžným procesům, které všechny čekají, až na ně přijde řada na alokačních stránkách.“
"Jaké nástroje můžeme použít ke zkoumání všech těchto věcí?" zeptal jsem se.
„SQL Server měl profiler pro zkoumání uložených procedur, ale je zastaralý. Něco takového je dobrý způsob, jak najít a diagnostikovat problémové dotazy, i když je to jen první krok. Pak jsou tu dynamické pohledy a funkce správy, které vám pomohou monitorovat stav vašeho serveru a databáze, odstranit problémy a vyladit SQL.“
"Ale SQL Server má tolik pohyblivých částí," řekl jsem. "Raději bych měl nástroj, který se dívá na celý obrázek zvenčí dovnitř."
"Já taky. Nejlépe z cloudu, takže k tomu nepotřebujeme více hardwaru a softwaru v místě."
Odstranění překážek výkonu na serveru SQL Server
Pike začínalo být přeplněné. A jakkoli jsme byli se šéfem ochotni sedět v hospodě a popovídat si, byl koneckonců pátek večer. Měli jsme další místa, kam jít, další lidi, které jsme mohli vidět, a další věci, o kterých jsme mohli mluvit.
"Co bychom měli dělat, až najdeme úzká místa?" zeptal jsem se.
"Sbíráme obvyklé podezřelé," řekl šéf. „Abychom nevyužili příliš mnoho paměti, musíme vývojářům databází sdělit, které z jejich kódu a dotazů propouštějí paměť. Pokud najdeme operace, které spojují čtyři, pět nebo šest tabulek, budeme muset vývojářům poskytnout tipy na ladění SQL Serveru a osvědčené postupy pro přepracování databáze. Nebo můžeme mít příliš mnoho indexů a můžeme plýtvat cykly jejich aktualizací; to je stejně náročné na CPU a I/O jako příliš málo indexů. Můžeme mít problém s fragmentací indexů SQL Serveru nebo možná budeme muset odstranit zastaralé a duplicitní indexy.“
"Dává to smysl," řekl jsem. "Možná na to budeme muset hodit více hardwaru." Rychlejší disky mohou pomoci s I/O úzkými hrdly. Více a rychlejší procesory mají vliv na dobu odezvy na dotaz. A přidání RAM znamená větší škálovatelnost SQL Serveru, že?“
"Ano," řekl šéf, "ale nejprve se chci ujistit, že hlavní příčinou není vývoj nebo problém DevOps. Jakmile se přesvědčím, že tomu tak není, zahraji si kartu Buy More Hardware.“
Chvíli jsme poseděli a dívali se, jak se hospoda plní pátečními večerními veselicemi.
"Šéfe," zeptal jsem se, "myslíte, že všichni tito lidé vědí, jak bezstarostnou existenci všichni vedou, bez břemene řešení blokovaných relací, maximálního čekání na vstup/výstup, očekávané životnosti stránky a poměru zásahů do mezipaměti?"
"Je to kříž nést, že?" odpověděl šéf. „Většina lidí nemá ponětí, čím procházíme. Dobrá věc, že problémy s výkonem SQL Serveru řešíme tak tiše, s takovou grácií pod tlakem a s tak dobrým vkusem. Když už mluvíme o dobrém vkusu, jak se vám daří se svým úzkým hrdlem?“
Zkontroloval jsem. "Moje úzké hrdlo je prázdné." Stejně tak moje láhev.“
"Mé taky. Čas jít. Máme co dělat.“
Je možný systém s nulovým úzkým hrdlem serveru SQL?
Víme, že existují kroky, které můžeme podniknout, abychom se těmto třem běžným typům úzkých míst serveru SQL Server vyhnuli. Je však možné nakonfigurovat databázi SQL Server tak dobře, aby neměla žádná úzká hrdla?
Krátká odpověď pravděpodobně není. I u toho nejpilnějšího DBA se tu a tam objeví překážky SQL Serveru. Můžete však podniknout kroky, abyste se proaktivně vyhnuli úzkým místům a minimalizovali jejich dopad na výkon. Například Brent Ozar nabízí několik skvělých tipů pro monitorování čítačů Perfmon pro vyladění vašeho SQL Serveru a můžete použít pohled sys.dm_os_performance_counters, který vám pomůže identifikovat úzká hrdla a rychle je napravit.
Úzká místa SQL Serveru jsou běžnou součástí života DBA. Naštěstí s odpovídajícím dohledem, pečlivým monitorováním a častým laděním dotazů lze problémy s výkonem vyřešit dříve, než si uživatelé vůbec uvědomí, že je problém.