Primárním zaměřením tohoto blogu je výkon v prostředí SQL Server. Dalo by se namítnout, že výkon začíná u návrhu databáze a aplikace. Můžete ale také prokázat, že mít k dispozici správné zdroje je pro dobrý výkon zásadní. Přes veškerou diskusi o správných zdrojích (jaký model CPU, kolik paměti, jaký druh úložiště) někdy zanedbáváme plánování kapacity:pomocí dat, která máme abychom mohli činit informovaná rozhodnutí o tom, co potřebujeme . Plánování kapacity není jen zjišťování, kolik místa na disku potřebujeme, ale zahrnuje také zdroje, které musí mít instance SQL Serveru k dispozici, aby zvládla zátěž.
Nové nebo stávající?
Kapacitní plánování nového řešení je opravdu ošemetné. Musíte přijít s odhady pracovní zátěže na základě informací, které shromažďujete od firmy. To znamená, že musíte klást těžké otázky o tom, kolik dat budou očekávat v prvním měsíci, prvních šesti měsících a prvním roce. Když přichází nové řešení, je to často POSLEDNÍ věc, na kterou firma myslí, takže velmi často dostanete vágní odpovědi. V případě nového řešení se musíte opravdu snažit co nejlépe odhadnout. Netahejte si vlasy ve snaze získat přesná čísla.
Pokud je řešení od dodavatele, musíte jej požádat o doporučení pro plánování jak o potřebném prostoru, tak o potřebných zdrojích. Připouštím, že možná nemají tato data, ale nedostanete to, o co nepožádáte. Nikdy není na škodu to zkusit.
[Bonus:Pokud dodavatel nemá žádné informace, které by mohl poskytnout, nebylo by užitečné, kdybyste mu poté, co je systém několik měsíců v provozu, odešlete svá data...například jaký máte hardware a jak vypadá náplň práce? Nemusí to být 20stránkový zápis, ale zpětná vazba je může postrčit směrem k větší proaktivitě.]
Pokud jde o stávající řešení, pokud máte problém s výkonem nebo chcete upgradovat hardware, budete chtít získat informace o aktuálním prostředí, abyste mohli naplánovat nové.
Úložiště
Plánování částky Potřebné úložiště je poměrně jednoduché, jen to vyžaduje určité plánování předem. Ve svých článcích o proaktivní kontrole stavu serveru SQL Server diskutuji o monitorování místa na disku a zahrnuji dotaz k zachycení informací o souborech. Tento dotaz zachycuje velikost databázových souborů pro instanci a také použitý prostor. Tyto údaje je nutné sledovat v čase, a to neznamená několik týdnů. Chcete vidět, jak se soubory mění v průběhu měsíců, možná po dobu jednoho až dvou let, protože vzorce použití pro aplikaci se mohou měnit. Tyto informace lze snadno zachytit, vyžadují málo místa k uložení a jsou neocenitelné jako reference při pořizování úložiště. Pokud můžete poskytnout kvantitativní data o růstu systému, máte mnohem větší šanci, že získáte prostor, který potřebujete, než o něj později. A když žádáte o místo, nezapomeňte do svých výpočtů zahrnout tempdb.
Hardwarové zdroje
CPU
Optimalizace výkonu vašeho CPU není jen o počtu CPU, které máte, musíte také vzít v úvahu model a pracovní zatížení (např. datový sklad s velkými paralelními dotazy vs. OLTP se sériovými dotazy). S těmito informacemi a malou pomocí od Glenna můžete určit nejlepší procesor pro váš server. Nezapomeňte zvážit licenční náklady a omezení na základě vaší edice SQL Server!
Paměť
Paměť je relativně levná a doporučujeme vždy zakoupit maximální množství paměti, kterou server pojme. Čtení dat z paměti je výrazně rychlejší než čtení z disku, takže čím více dat se do paměti vejde, tím lépe. Všimněte si, že celá databáze nemá aby se vešly do paměti. Potřebujete jen pracovní sadu dat, aby se vešla do paměti. Zvažte 2TB databázi. Je nepravděpodobné, že ve scénáři OLTP budou všechny 2 TB přístupné každý den. Obvykle se přistupuje pouze k nejnovějším údajům – třeba jen za posledních 30 nebo 60 dní. To jsou data, která se musí vejít do paměti. Ale samozřejmě jen zřídka vidíme čisté prostředí OLTP, často je to smíšené prostředí, protože uživatelé rádi spouštějí sestavy nad velkými sadami dat a neexistuje žádný datový sklad nebo kopie sestavy databáze, takže mají spustit sestavy proti produkci. To komplikuje požadavky na paměť. Nyní někdy potřebujete tato starší data v paměti, ale někdy ne. Je důležité porozumět pracovní zátěži; jaké typy dotazů se provádějí proti databázi?
Pokud používáte Standard Edition, ověřte, že máte na serveru více paměti, než je maximální podporovaná paměť. Například se serverem SQL Server 2014 a vyšším je ve Standard Edition maximální množství paměti, kterou můžete přidělit fondu vyrovnávacích pamětí (prostřednictvím nastavení maximální paměti serveru), 128 GB. Proto chcete mít na serveru více paměti (např. 160 GB), abyste mohli nastavit maximální paměť serveru na nejvyšší možnou hodnotu 128 GB a stále měli k dispozici paměť pro operační systém a další procesy SQL Server. Dále s SQL Server 2016 SP1 Standard Edition můžete používat In-Memory OLTP s limitem 32 GB na databázi. To je nad maximální hodnotou paměti serveru, takže pokud plánujete používat tuto funkci, kupte si paměť podle toho.
Úložiště
Když mluvíme o požadavcích na výkon úložiště, často slyšíte lidi mluvit o IOPS (operace vstupu/výstupu za sekundu). Tento článek byl ve skutečnosti inspirován otázkou od diváka, který sledoval můj kurz Pluralsight o Benchmarkingu a Baseliningu. Otázka zněla:„Jak korelujete čítače sledování výkonu pro čtení a zápisy za sekundu s připojením uživatelů, abyste odhadli počet IO na uživatele? Čtení a zápisy za sekundu jsou vstupní/výstupní operace, takže tato data máme k dispozici prostřednictvím PerfMon na úrovni instance, a to je to, co používáte k definování požadavků IOPS pro instanci.
Pokud však víte, čte a píše a připojení uživatelů, pak můžete provést nějaké výpočty a zjistit IOPS na uživatele. To je užitečné, pokud plánujete rozšířit řešení a přidat další uživatele. Chcete se ujistit, že se řešení bude škálovat, a jednou z možností, kterou máte, je vzít vypočítané IOPS na uživatele na základě X počtu uživatelů a poté odhadnout IOPS instance pro Y počet uživatelů. Nyní s tímto výpočtem uděláme mnoho předpokladů. Předpokládáme, že způsob, jakým nová připojení využívají systém, je stejný jako dnes – to může, ale nemusí být nakonec, nebudete to vědět, dokud nebude systém na svém místě. Když pochopíte tuto hodnotu (čtení + zápisy / uživatelská připojení =průměrný IOPS na uživatele), pak víte, jak odhadnout IOPS pro řešení na základě předpokládaných uživatelských připojení.
Tyto informace pak přenesete do svého úložiště, aby prodiskutovali možné dostupné konfigurace. Můžete vypočítat maximální IOPS pro konfiguraci disku, pokud máte informace o discích (např. počet disků, rychlost, velikost a konfiguraci RAID). Propustnost IO pro jednotku můžete otestovat pomocí CrystalDiskMark, i když to nemusí být možné, pokud nebylo rozhodnuto o úložišti. Jakmile je však na svém místě, měli byste projít tímto testováním, abyste se ujistili, že IOPS pro daný disk dokáže splnit očekávanou zátěž.
IOPS jsou jen jedním ze způsobů, jak se dívat na výkon úložiště. Pochopte, že tato data vám říkají, kolik IO se vyskytuje, a v ideálním případě, pokud znáte IOPS a máte úložiště splňující požadavky, měla by být latence minimální. Ale to, co ovlivňuje výkon, je latence. Chcete-li zjistit, jaká latence existuje, budete muset k porovnání úložiště použít nástroj, jako je DiskSpd. Glenn má skvělý článek, který vysvětluje, jak analyzovat výkon IO, a pak další článek o tom, jak jej pomocí DiskSpd otestovat, abyste pochopili latenci. Vřele doporučuji přečíst si oba články, pokud jste se dříve nedívali na úložiště a výkon.
Závěr
Plánování kapacity je více než jen vědět, kolik místa potřebujete pro databázové soubory. Musíte porozumět pracovnímu zatížení a tomu, co vyžaduje z hlediska CPU, paměti a diskových prostředků. K tomu potřebujete data… což znamená, že potřebujete zachytit základní linie. Moje úplně první sezení v komunitě SQL Server bylo v prosinci 2010 a bylo na téma základní linie. O šest let později stále mluvím o jejich důležitosti a stále slyším od lidí, že tato čísla nemají. Pokud chcete provádět inteligentní a cílené plánování kapacity, musíte shromáždit příslušná data… jinak jen hádáte.