V tomto pokračování mé série „ladění výkonu na kolena“ bych rád probral Solid State Disky (SSD) a některé problémy, které vidím při jejich použití v prostředí SQL Serveru. Podrobný popis SSD disků najdete v tomto článku na Wikipedii.
Co dělají SSD pro výkon SQL Serveru?
SSD nemají žádné pohyblivé části, takže když dojde ke čtení nebo zápisu, nedochází k téměř žádné I/O latenci. Latence u rotujícího disku pochází ze dvou věcí:
- Posunutí hlavy disku na správnou stopu na povrchu disku (známé jako doba hledání)
- Čekání, až se disk otočí do správného bodu stopy (známé jako rotační latence)
To znamená, že disky SSD poskytují velké zvýšení výkonu, když existuje úzké místo I/O.
Je to tak jednoduché.
Je tu trochu komplikace, která stojí za zmínku, ale přesahuje rámec tohoto článku, abychom se do něj dostali do hloubky:Výkon SSD se může začít zhoršovat, když se disk opravdu zaplní (podrobně prozkoumáno a vysvětleno v tomto článku od AnandTech). Ovladač SSD může také vyžadovat určitou systémovou paměť, která pomáhá s vyrovnáváním opotřebení (prodlužuje životnost buněk NAND v SSD), a to se bude lišit podle dodavatele. Dost toho – zpět k SQL Serveru.
Vyhněte se špatným internetovým radám
Na internetu kolem SQL Serveru a SSD vidím dvě velmi špatné rady.
První se týká toho, co dát na SSD, kde je rada vždy umístit tempdb a vaše transakční protokoly na SSD. Na první pohled to zní jako dobrá rada, protože transakční protokoly a tempdb jsou běžně úzká hrdla v systému.
Ale co když nejsou?
Vaše pracovní vytížení může být většinou pro čtení, v takovém případě protokol transakcí pravděpodobně nebude překážkou pracovního zatížení, takže jeho umístění na SSD může být plýtvání drahým SSD.
Vaše databáze tempdb nemusí být příliš využívána podle vaší pracovní zátěže, takže umístění na SSD může být plýtváním drahým SSD.
Když zvažujete, kterou část prostředí SQL Serveru přesunout na SSD, chcete prozkoumat, kde jsou I/O úzká hrdla. To lze provést velmi snadno pomocí kódu, který jsem zveřejnil minulý týden a který používá sys.dm_io_virtual_file_stats DMV k poskytnutí snímku I/O latence pro všechny soubory ve všech databázích v instanci. Chcete-li porozumět svým číslům latence a porovnat je s dobrými/špatnými hodnotami, přečtěte si tento dlouhý příspěvek, který jsem napsal konkrétně o latenci I/O tempdb a protokolu transakcí.
A i když máte vysoké latence, netrhejte se a nemyslete si, že jediným řešením je přesunout soubory se špatným výkonem na SSD:
- U latence čtení datového souboru prozkoumejte, proč dochází k tak velkému počtu čtení. Pokrývám to zde.
- U latence zápisu do souboru protokolu zvažte všechny způsoby, jak vyladit výkon protokolu a toho, co se protokoluje. Pokrývám to zde, zde a zde.
Nejhorším možným případem je situace, kdy dostanete spoustu SSD, postupujte podle internetových rad a přesuňte na ně tempdb a soubory protokolu, a pak nedojde k žádnému zvýšení výkonu při pracovní zátěži. To nebude povzbuzovat vaši správu, aby vám poskytla dražší SSD.
Druhá špatná rada se týká fragmentace indexu, kde rada zní, že protože jsou SSD disky tak rychlé, nemusíte se při používání SSD obávat fragmentace indexu.
Jaký nesmysl!
Existují tři způsoby, jak tuto špatnou radu vyvrátit:
- SSD v žádném případě nezastaví příčinu fragmentace indexu:stránky se rozdělují ze stránek, které potřebují volné místo pro náhodné vložení nebo zvětšení velikosti řádku. Rozdělení stránky generuje stejné množství transakčního protokolu, využití zdrojů a potenciálního čekání vlákna bez ohledu na to, kde jsou data/soubory protokolu uloženy.
- Fragmentace indexu zahrnuje mnoho datových/indexových stránek s nízkou hustotou stránek (tj. hodně prázdného volného místa). Opravdu chcete, aby vaše drahé SSD ukládaly spoustu volného místa? SSD zde vůbec nepomáhají.
- Můj kolega Jonathan Kehayias provedl pomocí Extended Events hloubkový průzkum vzorců I/O týkajících se fragmentace indexu, konkrétně s cílem vyřešit tuto špatnou radu, a zjistil, že fragmentace indexu při používání SSD stále způsobuje snížení výkonu. Jeho dlouhý příspěvek si můžete přečíst zde.
Jediná věc, kterou SSD dělají kolem fragmentace indexu, je zrychlení čtení, takže při fragmentaci indexu dochází k menšímu snížení výkonu pro skenování rozsahu indexu, ale bod 3 výše ukazuje, že penalizace stále existuje.
Jednotky SSD nemění způsob, jakým se vypořádáte s fragmentací indexu v prostředí serveru SQL Server nebo jak jí zabráníte.
Zajistěte ochranu svých dat
Jedním z hlavních hříchů, které vidím, že lidé používají SSD disky, je používání pouze jednoho z nich. S pouze jedním diskem, jakou úroveň RAID používáte? Nula. RAID-0 neposkytuje žádnou redundanci.
Pokud budete používat SSD, musíte použít alespoň dva v konfiguraci RAID-1 (zrcadlení). Nemá smysl zvyšovat výkon, pokud jako kompromis obětujete dostupnost systému.
Jednou z možností, ke které se někdy dostanu k použití alespoň dvou SSD, je to, že SSD karta poskytuje Windows dva disky, takže vytvoření zrcadleného svazku Windows přes tyto dva disky je stejné jako RAID-1 na dvou fyzicky samostatných SSD?
Ne, to není. Je to stále jeden fyzický SSD bez redundance. Už jste někdy viděli selhání poloviny SSD karty? Ne, já také ne. Udělejte to správně a použijte dva z nich a získejte skutečnou redundanci pro svá data.
Dalším odrazem, který dostávám, je, že jsou to SSD, ne rotující disky, takže se nepokazí. To je špatně. SSD mohou selhat a selžou stejně jako rotující disky. Osobně jsem během testování v našem laboratorním prostředí viděl selhání dvou podnikových SSD. Podle tohoto článku na StorageReview.com mají SSD pro spotřebitele MTBF 2 miliony hodin oproti 1,5 milionu hodin u spotřebitelských rotačních disků a očekával bych podobné výsledky u disků podnikové třídy, ale SSD selhávají.
Shrnutí
Nenechte se chytit do pasti myšlenek, že cokoli na SSD vložíte, znamená to, že získáte zvýšení výkonu – musíte pečlivě vybírat. A nevěřte ani nesmyslům o ignorování fragmentace indexu při používání SSD.
SSD jsou velmi užitečným způsobem, jak zvýšit výkon, ale vzhledem k jejich ceně se chcete ujistit, že maximalizujete návratnost investic vaší společnosti tím, že je budete používat správně a pouze tam, kde je to vhodné.
V dalším článku ze série proberu další běžnou příčinu ladění výkonu. Do té doby přejeme hodně štěstí při odstraňování problémů!