Průvodce hardwarem pro Firebird

Alexey Kovyazin, naposledy aktualizováno: 30. listopadu 2015

V technických podpůrných skupinách Firebird často vidíte následující otázku: „Jaký hardware zvolit pro Firebird DBMS?". Toto téma zůstává trvale populární, protože hardwarové požadavky se liší podle úloh a samotný hardware se v čase mění.

Rozhodli jsme se napsat tuto příručku, abychom poskytli potřebné znalosti každému, kdo chce vybrat skutečně efektivní hardware pro svou databázi Firebird. K tomu se budete muset naučit některé základní detaily o tom, jak funguje Firebird, operační systém a samozřejmě také hardware.

Trocha teorie

Abyste zjistili, jaký hardware bude pro vaši databázi Firebird nejvhodnější, musíme pochopit, jak Firebird využívá své komponenty: CPU, RAM, HDD/SSD a jak tyto komponenty interagují s operačním systémem (například s cache souborů).

Funkční moduly serveru Firebird

Nejprve se podíváme na funkční moduly Firebirdu pomocí obrázku 1:

Obrázek 1. Moduly Firebirdu

Firebird zahrnuje následující hlavní funkční moduly:

Objekty metadat: pohledy, tabulky, indexy, triggery, uložené procedury a další databázové objekty. Objekty metadat se nacházejí v adresním prostoru procesu Firebirdu (může to být fbserver, fb_inet_server nebo firebird.exe).
Cache stránkových bufferů obsahuje databázové stránky načtené z disku a nachází se v adresním prostoru serverového procesu. Mechanismus cacheování stránek je poměrně složitý, takže pouze uvedeme, že Firebird cacheuje nejčastěji používané databázové stránky.
Firebird třídí záznamy v paměti (v adresním prostoru serverového procesu), dokud množství paměti použité pro všechny současné třídicí operace nedosáhne limitu nastaveného parametrem TempCacheLimit (firebird.conf). Jakmile je tento limit překročen, je ve složce s dočasnými soubory vytvořen dočasný soubor (s odpovídajícím příznakem operačního systému), který se použije pro třídění. Pokud je v systému volná RAM, bude třídicí soubor cacheován operačním systémem a třídění bude probíhat v paměti.
Globální dočasné tabulky (GTT) jsou vytvářeny jako dočasné soubory v operačním systému. Pokud má operační systém volnou paměť, operace s GTT jsou prováděny v RAM.

Základní operace s hardwarem

Podívejme se, jak funkční moduly Firebirdu interagují s hardwarovými komponentami během operací prováděných v průběhu práce s databázemi.

Jakmile je Firebird spuštěn, serverový proces zabírá minimální množství RAM (několik megabajtů) a neprovádí žádné intenzivní operace s CPU nebo RAM.

Když je navázáno připojení k databázi, server začne číst její metadata a vytvářet odpovídající objekty v paměti, což vede k tomu, že proces zabírá tím více prostředků, čím více tabulek, indexů, triggerů a dalších metadat se používá. Využití paměti se zvyšuje, ale CPU v této fázi prakticky není využíván.

Když klient začne provádět SQL dotazy (včetně uložených procedur), server provádí odpovídající operace pomocí hardwaru. Je možné vyčlenit následující základní operace zahrnující interakci s hardwarem:

čtení databázových stránek z pevného disku,
zápis databázových stránek na pevný disk,
čtení databázových stránek z cache,
zápis databázových stránek do cache,
čtení dat z globálních dočasných tabulek a zápis dat do nich,
zpracování SQL dotazů (například JOIN),
třídění záznamů v sadách výsledků.

Každá z těchto operací vyžaduje určité množství systémových prostředků. Následující tabulka ukazuje spotřebu prostředků v intenzivních jednotkách (1 znamená nejméně intenzivní, 10 nejvíce intenzivní):


	Čtení stránky z disku	Zápis stránky na disk	Čtení stránky z cache stránkových bufferů	Zápis stránky do cache stránkových bufferů	Čtení z GTT	Zápis do GTT	Třídění záznamů	Zpracování SQL dotazů
CPU	1	1	1	1	1	1	5	10
RAM	5	5	5	5	5	5	5	2
Disk I/O	10	10	1	1	1	1	1	1

Jak vidíte, nejnáročnější operace na prostředky jsou ty, které zahrnují přístup k disku, protože disky zůstávají nejpomalejší hardwarovou komponentou i přes pokrok v posledních letech související s SSD.

To vede k jednomu ze způsobů optimalizace výkonu, který je zcela hardwarově orientovaný - přesunout všechny operace čtení a zápisu do RAM. Ale pozor, přístup „zvětšete page cache" nefunguje. Tímto problémem se budeme podrobně zabývat v sekci o RAM.

Současně prováděné operace

Obvykle je nutné vybrat hardware pro server, který bude obsluhovat mnoho klientů, takže je opravdu důležité pochopit, jak je implementována paralelnost operací.

Z hlediska hardwarových komponent můžeme hovořit o paralelním využití CPU, disku a RAM. Moderní CPU mají několik jader, která mohou provádět sady instrukcí paralelně, takže server DBMS distribuuje operace mezi jádra, což znamená závěr, že čím více jader má CPU, tím více klientů bude moci na tomto serveru pracovat.

Z hlediska disků to není tak jednoduché. Když tradiční pevné disky (HDD) čtou informace, fyzicky pohybují hlavou nad magnetickým materiálem určitou konečnou rychlostí. Databáze může být poměrně velká, tj. 3 terabajty, a pokud SQL dotazy od klientů přistupují k jejím datům umístěným v různých oblastech disku paralelně, hlava disku bude přeskakovat mezi různými oblastmi na disku, čímž se vážně zpomalí operace čtení a zápisu. To výrazně zvýší frontu disku, zatímco ostatní prostředky (CPU, RAM) budou nečinné. Cache disku (cache HDD nebo RAID řadiče) samozřejmě toto zpomalení do určité míry kompenzuje, ale nestačí to.

Na rozdíl od tradičních HDD jsou disky SSD (solid-state drives) mnohem méně náchylné ke snížení výkonu v případě paralelního přístupu k datům. Výhoda SSD je obzvláště zřejmá při paralelním zápisu dat - naše testy ukazují, že SSD je 7krát rychlejší než SATA disk (odkaz!). SSD však mají některé problémy, které je třeba vzít v úvahu při jejich používání (viz Výběr disků), aby se předešlo zpomalení, předčasným poruchám a ztrátě dat.

Operace s RAM jsou na moderních počítačích prováděny velmi rychle, jsou prakticky omezeny pouze šířkou pásma datové sběrnice, takže tyto operace nepředstavují úzké hrdlo, ani když existuje mnoho paralelních SQL dotazů.

Datové toky

Při provádění SQL dotazů Firebird čte a zapisuje mnoho dat, přenáší je mezi funkčními moduly a odpovídajícími hardwarovými komponentami. Abychom identifikovali možná úzká hrdla, musíme pochopit, jak je prováděna výměna dat. Pomůže nám s tím obrázek 2 níže:

Obrázek 2. Datové toky mezi RAM a trvalým úložištěm

Je zřejmé, že přenos dat z trvalého úložiště do RAM a zpět je nejnáročnější operací na čas. Vytváří dva datové toky: čtení/zápis datových stránek ze souborů databáze a čtení/zápis třídicích souborů. Protože může existovat několik třídicích souborů a mohou být poměrně velké, mohou vytvářet poměrně velké zatížení disků, takže je vhodné směrovat tyto vstupně/výstupní toky na různé disky.

Zálohování

Firebird nabízí dvě metody zálohování: ověřené zálohování pomocí nástroje gbak a neověřené inkrementální zálohování pomocí nástroje nbackup.

Doporučujeme kombinovat tyto metody zálohování: spouštějte nbackup často (například každou hodinu, den a týden) a každou noc vytvářejte ověřenou záložní kopii pomocí gbak.

Ať už použijete jakoukoli metodu zálohování, soubor databáze je čten (celý nebo jeho část) a je zapisována záložní kopie (úplná nebo inkrementální). Operace zápisu jsou během procesu zálohování prováděny sekvenčně, což znamená, že běžné levné pevné disky s rozhraním SATA (HDD SATA) budou pro zálohování dobré, protože sekvenčně zapisují poměrně rychle.

Výběr vhodného hardwaru

Nyní, když máme představu o tom, jak Firebird interaguje s hardwarem, bychom se měli zaměřit na faktory, které ovlivňují výběr každé konkrétní komponenty a jejích specifikací.

Někdy skutečné statistiky konkrétní databáze silně ovlivňují výběr hardwarových komponent, takže k získání těchto statistik použijeme nástroje z HQbird (profesionální distribuční balíček Firebirdu od IBSurgeon). Zkušební verzi HQbird si můžete stáhnout na http://hqbird.com/en/hqbird/.

CPU

Při výběru CPU byste měli vzít v úvahu následující tři věci:

Jaké dotazy v aplikaci převažují,
Počet aktivních připojení k databázi v průměru a při špičkovém zatížení,
Verze a architektura Firebirdu.

Jaké dotazy v aplikaci převažují?

Firebird vždy provádí jeden dotaz na jednom jádře, takže složité a špatně optimalizované dotazy mohou využít jedno jádro až na 100 %, čímž vytlačují ostatní dotazy na méně zatížená jádra, a čím více jader je, tím nižší je pravděpodobnost, že bude celé CPU využito a že uživatelé zaznamenají jakékoli snížení výkonu aplikace.

Pokud aplikace spouští hlavně jednoduché krátké SQL dotazy, všechny dotazy jsou dobře optimalizované a nejsou generovány žádné ad hoc dotazy (například pro sestavy), CPU nebude představovat úzké hrdlo výkonu a můžete zvolit low-end CPU s méně jádry.

Pokud aplikace obsahuje generátor sestav nebo mnoho pomalých dotazů vracejících velké množství dat, potřebujete CPU s více jádry.

Počet aktivních připojení k databázi v průměru a při špičkovém zatížení

Počet připojení (aktivních uživatelů) také ovlivňuje výběr CPU. Bohužel ani vývojáři aplikací nemají přesnou představu o tom, kolik připojení, dotazů a transakcí je v daném okamžiku aktivních. Chcete-li získat přesnější informace, doporučujeme použít nástroj MON$ Logger z HQbird a pořídit několik snímků během jeho běhu, kde uvidíte, kolik připojení je skutečně navázáno.

Obrázek 3. MON$ Logger: počet připojení

Například zde vidíte, že počet připojení je 296. Je zřejmé, že v tomto případě je příliš optimistické použít čtyřjádrový CPU, zatímco 24jádrové řešení bude docela vhodné. Je také vhodné spočítat počet současně spuštěných dotazů, protože připojení mohou být nečinná bez spuštěných SQL dotazů.

Pro hrubý odhad potřebného počtu jader CPU můžete použít poměr 10 až 30 připojení na 1 jádro. 10 připojení na jádro pro aplikaci s převážně složitými a pomalými dotazy, 30 připojení na jádro pro aplikaci s převážně jednoduchými dobře optimalizovanými dotazy.

Verze a architektura Firebirdu

Pokud používáte Firebird verze 2.5, mějte na paměti, že pro distribuci zpracování mezi více jader byste měli použít architekturu Classic nebo SuperClassic. Ve verzi 2.5 může architektura SuperServer použít pro jednu databázi pouze jedno jádro, takže by se neměla používat v systémech, které spotřebovávají mnoho prostředků.

Ve verzi Firebird 3.0 využívají SuperServer, Classic a SuperClassic funkce vícejádrových CPU. Firebird 3.0 SuperServer vykazuje nejlepší výkon.

RAM

Při výběru RAM byste měli věnovat pozornost dvěma věcem:

paměťový modul musí mít kód pro opravu chyb (ECC RAM)
množství RAM musí být správně vypočítáno

ECC RAM

ECC RAM výrazně snižuje počet chyb, ke kterým dochází při práci s pamětí, a důrazně se doporučuje ji používat v průmyslových systémech.

Výpočet potřebného množství paměti RAM

Pro výpočet množství paměti se musíme podívat na zvláštnosti různých architektur Firebirdu. Firebird 2.5 Classic a Firebird 3.0 Classic spouští samostatný proces pro obsluhu každého připojení, SuperClassic spouští samostatné vlákno pro každé připojení, ale prakticky se stejnou strukturou spotřeby paměti - každé připojení má svou vlastní nezávislou mezipaměť stránek.

Firebird SuperServer spouští jeden proces s jednou mezipamětí stránek pro všechna připojení.

Následující parametry tedy ovlivňují celkovou spotřebu paměti:

Počet připojení
Velikost stránky databáze
Velikost metadat (úměrná počtu tabulek, triggerů, uložených procedur atd.; nelze ji nastavit; je určena fyzickým používáním)
Pro Classic a SuperClassic - na připojení
Pro SuperServer - na instanci otevřené databáze
Velikost mezipaměti stránek (určena parametry v hlavičce databáze nebo v firebird.conf nebo ve vlastnostech konkrétního připojení)
Pro Classic a SuperClassic - na připojení
Pro SuperServer - na instanci otevřené databáze
Velikost mezipaměti pro třídění (určena parametrem v firebird.conf). Paměť pro třídění se nealokuje najednou, ale až podle potřeby.
Pro Classic - na připojení
Pro SuperServer a SuperClassic - na proces (tj. jedna mezipaměť pro třídění)
Pro Classic/SuperClassic - velikost tabulky zámků (obvykle je malá, takže ji z výpočtu vynecháme).

Společnost IBSurgeon provedla několik testů a získala sadu optimálních hodnot pro počet stránek v mezipaměti stránek Firebirdu:

Classic/SuperClassic - od 256 do 2000 stránek
SuperServer 2.5 - 10000 stránek
SuperServer 3.0 - 100000 stránek

Na základě těchto testů jsme vytvořili optimalizované konfigurační soubory Firebirdu pro servery se 4-6 GB paměti. Můžete si je stáhnout zde: /cs/optimized-firebird-configuration/

Vzorce pro výpočet potřebného množství paměti RAM

Níže vidíte vzorce používané pro odhad přibližného množství paměti, které bude Firebird potřebovat. Skutečná spotřeba paměti se může lišit, protože tento odhad nezohledňuje množství paměti potřebné pro metadata, bitové masky indexů atd., což může spotřebu paměti zvýšit. Předpokládá se také, že paměť pro třídění bude plně využita ve všech připojeních, což obvykle neplatí.

Pokud je vaše databáze již v provozu, můžete se podívat na průměrné množství paměti používané procesem Firebirdu (pomocí Správce úloh nebo ProcessExploreru).

Odhad pro Classic:

Počet připojení * ( (Počet stránek v mezipaměti * Velikost stránky) + Velikost mezipaměti pro třídění )

Příklad pro Classic: předpokládejme 100 aktivních uživatelů, velikost stránky databáze je nastavena na 8 KB a počet stránek v mezipaměti stránek je nastaven na 256, velikost mezipaměti pro třídění je zvýšena z 8 MB (výchozí hodnota pro Classic a SuperClassic) na 64 MB:

((256.8 KB)+64) = 6600 MB

Odhad pro SuperClassic:

Počet připojení * (Počet stránek v mezipaměti * Velikost stránky) + Velikost mezipaměti pro třídění

Příklad pro SuperClassic: 100 uživatelů, velikost stránky databáze je 8 KB, počet stránek v mezipaměti stránek je 256, velikost mezipaměti pro třídění je 1024 MB

100.(256.8 KB) + 1024 MB = 2024 MB

Odhad pro SuperServer:

(Počet stránek v mezipaměti * Velikost stránky) + Velikost mezipaměti pro třídění

Příklad pro SuperServer (Firebird 2.5): 1 databáze, 100 uživatelů, velikost stránky databáze je 8 KB, počet stránek v mezipaměti stránek je 10000, velikost mezipaměti pro třídění je 1024 MB:

(10000.8 KB) + 1024 = 1102 MB

Příklad pro SuperServer (Firebird 3.0): 1 databáze, 100 uživatelů, velikost stránky databáze je 8 KB, počet stránek v mezipaměti stránek je 100000, velikost mezipaměti pro třídění je 1024 MB:

(100000.8 KB) + 1024 = 1805 MB

“Nadměrná paměť”

Firebird je často obviňován z neefektivního využívání paměti - když běžící proces serveru spotřebovává malé množství paměti RAM a zbytek paměti zůstává údajně nevyužitý.

Ve skutečnosti to není pravda. Tento závěr v podstatě spočívá v nepochopení toho, jak funguje mechanismus ukládání do mezipaměti Firebirdu, a v nedokonalosti nástrojů pro monitorování operačního systému.

Především si musíte být naprosto jisti, že Firebird intenzivně využívá souborovou mezipaměť operačního systému. Když je stránka načtena do mezipaměti stránek Firebirdu, prochází přes souborovou mezipaměť operačního systému. Když Firebird uvolní stránku ze své mezipaměti stránek, operační systém nadále drží tento kus databáze ve své paměti RAM, pokud má dostatek volné paměti.

Obrázek 4. Úrovně mezipaměti: Firebird, OS a úložiště

Pokud se však na to jen podíváte, operační systém nezobrazuje paměť přidělenou souborové mezipaměti jako používanou. Například zde je typická situace rozdělení paměti, když běží server Firebirdu, jak ji zobrazuje Správce úloh:

Obrázek 5. Správce úloh nezobrazuje využití souborové mezipaměti

Vypadá to, jako by bylo využito pouze 6,3 GB z 16 GB.

Pokud však použijete nástroj RAMMap (od SysInternals od Microsoftu), vypadá vše mnohem logičtěji:

Obrázek 6. RAMMap zobrazuje podrobnosti o využití paměti: mapované soubory jsou databáze v mezipaměti

Databázové soubory (dbw350.fb252x64.fdb a dbw250.fb252x64.fdb) jsou ukládány do mezipaměti operačním systémem a zabírají celou paměť, kterou Správce úloh deklaruje jako volnou:

Obrázek 7. RAMMap: podrobnosti o využití souborové mezipaměti

Z toho vyvozujeme, že operační systém efektivně využívá veškerou dostupnou paměť k ukládání databáze do mezipaměti, až do úplného načtení databáze do paměti.

Diskový subsystém

Správná konfigurace diskového subsystému hraje důležitou roli při výběru a konfiguraci hardwaru pro Firebird, protože jakékoli chyby v tomto kroku povedou k velkým selháním, která se obtížně opravují.

Samostatné disky pro všechno

Pro snížení konkurence o diskový vstup/výstup mezi operacemi se souborem databáze a pro snížení pravděpodobnosti současné ztráty databáze a zálohy se doporučuje mít tři různé disky (nebo pole RAID): jeden pro databázi, jeden pro dočasné soubory a jeden pro vytváření a ukládání záložních kopií.

Když říkáme “samostatné disky”, znamená to, že datové toky musí procházet různými kanály vstupu/výstupu. Pokud vytvoříte tři logické disky na jednom fyzickém disku, nedojde ke zvýšení výkonu. Pokud však uspořádáte tři logické disky na datovém úložišti vybaveném vícekanálovými řadiči, výkon se s největší pravděpodobností zvýší, protože zařízení může distribuovat datové toky mezi řadiče. Někdy se uvádí, že vyhrazení samostatného disku pro ukládání souborů operačního systému a odkládacího souboru operačního systému zvyšuje výkon.

SSD pro databázi

SSD je nejlepší volbou pro práci s databází, protože zajišťují vynikající škálování při paralelním vstupu/výstupu. Je nutné používat podnikové disky se zvýšeným počtem cyklů čtení/zápisu, jinak je velmi pravděpodobné, že přijdete o data kvůli selhání SSD.

Před nějakou dobou byly SSD náchylné ke zvýšenému opotřebení, pokud na disku zbývalo málo volného místa (méně než 30%). Jednoduše řečeno, každá modifikace na SSD se zapisuje do nové volné buňky, takže nedostatek volného místa vedl ke zvýšenému opotřebení buněk, které zůstaly volné, a ke kratší životnosti disku.

Výrobci moderních řadičů SSD prohlašují, že tento problém byl vyřešen preventivním přesouváním statických dat a nyní je opotřebení buněk více či méně vyrovnáno. Přesné specifikace a operační algoritmy SSD jsou však výrobci drženy v tajnosti, takže stále doporučujeme ponechat 30% místa na SSD volných, stejně jako snížit jejich očekávanou životnost a plánovat jejich výměnu nejméně jednou za tři roky.

Předpokládejme, že velikost vaší databáze je aktuálně 100 GB a roste o 1 GB měsíčně. V tomto případě nesmíte koupit SSD minimální velikosti (120 GB), ale je lepší zvolit další zařízení v produktové řadě - 250 GB. Zároveň by nákup 512gigabajtového SSD byl plýtváním penězi, protože se doporučuje disk vyměnit za tři roky.

Nejlepší praxí je vyhradit SSD výhradně pro práci s databází, protože jakékoli operace vstupu/výstupu snižují životnost disků.

Disk pro dočasné soubory

Protože se dočasné soubory na disku objevují pouze tehdy, když není dostatek paměti RAM, nejlepším způsobem je této situaci samozřejmě úplně předejít. Počet a velikost dočasných souborů v produkčním systému lze vyhodnotit pouze monitorováním složky s dočasnými soubory. FBDataGuard z distribučního balíčku HQbird provádí tento druh monitorování. Jakmile budete vědět, kolik dočasných souborů pro třídění se na disku vytváří a kdy se vytvářejí, budete moci zvýšit množství paměti RAM a změnit konfiguraci v firebird.conf.

V každém případě Firebird vyžaduje, abyste zadali složku, kde budou dočasné soubory uloženy. Obvykle se výchozí nastavení ponechává beze změny, tj. používá se složka operačního systému pro dočasné soubory. Pokud je volné paměti RAM dostatek, je to dobrá volba.

Existuje však další důležitý problém týkající se umístění dočasných souborů na disku - je to vytváření indexů při obnově ověřené záložní kopie (vytvořené pomocí nástroje gbak). Při vytváření indexu se také vytváří dočasný soubor obsahující všechny klíče z tohoto indexu. Pokud je databáze poměrně velká, může být velikost indexu pro některou velkou tabulku také poměrně velká. Například index největší tabulky obsahující 3,2 miliardy záznamů v 1terabajtové databázi je 29 GB, ale vytvoření tohoto indexu zabralo 180 GB volného místa:

Aby se předešlo nedostatku volného místa na systémovém disku, je možné zadat další disk jako dodatečné rezervované místo v firebird.conf:

TempDirectories =C:\temp; H:\Temp

Pokud na prvním disku není místo, Firebird bude pokračovat v používání druhého disku pro dočasné soubory a tak dále.

HDD pro zálohy

Pro vytváření a ukládání záložních kopií budou vhodné běžné HDD s rozhraním SATA nebo nSAS. Zajišťují rychlé sekvenční zápisy a čtení pro záložní soubory a jsou dostatečně levné, abyste nešetřili na jejich velikosti a mohli uchovávat několik záložních kopií.

Disky pro záložní kopie musí mít vždy extra volné místo: velikost nejnovější záložní kopie + 10%. V tomto případě je možné vytvořit novou záložní kopii, ujistit se, že proces zálohování úspěšně skončil (tento proces může trvat několik hodin pro databázi o velikosti několika terabajtů), a teprve poté smazat předchozí záložní kopii.

Pokud smažete předchozí záložní kopii před vytvořením nové, je možné, že se nevytvoří žádná nová záložní kopie, zatímco stará již bude smazána a databáze bude poškozena, například kvůli selhání disku.

Pokud používáte výše doporučenou metodu zálohování (kombinaci tříúrovňové přírůstkové zálohy a ověřené zálohy jednou denně s uchováváním pouze jedné nejnovější kopie), použijte pro výpočet minimálního místa pro zálohy následující vzorec:

Velikost_databáze*3+0.2.Velikost_databáze

Podívejme se na následující příklad výpočtu místa potřebného pro zálohy:

Předpokládejme, že máme databázi o velikosti 100 GB, pro kterou ukládáme tříúrovňovou přírůstkovou zálohu (týden-den-hodina - jedna kopie každé úrovně) a jednu kopii denní ověřené zálohy. V tomto případě budou záložní kopie zabírat následující místo:

Nbackup_level_0.weekly - 100 GB
Nbackup_level_1.daily - 5 GB (přibližně)
Nbackup_level_2.hourly - 200 MB (přibližně)
Denní ověřená záloha - 100 GB (přibližně)
Navíc potřebujete rezervovaných 110 GB, abyste mohli vytvořit další záložní kopii.

Celkem - 316 GB.

! Velikost prvotní úrovně inkrementálního souboru nebo vyšší závisí na počtu stránek změněných od posledního spuštění nbackup. Velikost těchto souborů lze určit pouze experimentálně, protože množství změn v databázi závisí na aplikacích.

Samozřejmě, odhad prostoru pro zálohu by měl zohlednit možné abnormální zvýšení velikosti databáze a odpovídajícím způsobem zvýšit množství volného místa, jinak může být proces zálohování neočekávaně přerušen kvůli nedostatku místa.

Přirozeně, chytré nástroje pro zálohování (FBDataGuard od HQbird) si všimnou nedostatku místa pro záložní kopie a pošlou odpovídající zprávu administrátorovi.

HDD pro databázi

SSD se může ukázat jako příliš drahé řešení nebo databáze může být příliš velká a budete muset použít méně nákladné metody. V tomto případě byste měli použít HDD s rozhraním SAS. Pokud to není možné, použijte SATA disky s rozhraním nSAS nebo nejlevnější variantu - běžné SATA disky.

Pro zvýšení rychlosti (a také spolehlivosti - viz níže) pevných disků byste je měli spojit do RAID10. RAID10 je kombinace zrcadlených (RAID1) a proužkovaných (RAID0) bloků. Dobrý a správně nakonfigurovaný RAID řadič s velkou mezipamětí je pěknou alternativou k SSD.

Spolehlivost a RAID

Samozřejmě je nutné zvýšit spolehlivost diskového subsystému spojením disků do RAID ve všech výše zmíněných variantách (kromě disku vyhrazeného výhradně pro dočasné soubory).

• Pro SSD se ujistěte, že používáte RAID1 - tj. dva zrcadlené disky, na které se změny zapisují současně, což výrazně snižuje šance na ztrátu všech dat. RAID 10 složený z SSD bude s největší pravděpodobností nadbytečný, protože RAID sběrnice omezí propustnost. Například rozhraní 6 Gbit/s má propustnost 600 megabajtů za sekundu, zatímco moderní jednotlivé SSD již této rychlosti dosáhly. Takže pro RAID 10 dostaneme stejný limit 600 MB/s.

Kromě toho můžete použít PCI Express 3.0 ke spojení SSD do RAID 10, protože propustnost této sběrnice je již 16 gigabitů za sekundu a více.

• Pokud používáte HDD pro účely zálohování, stačí použít RAID1, který zajistí bezpečnost záložních kopií a přijatelnou rychlost čtení a zápisu.

• HDD používané pro databázi by měly být spojeny do RAID10 (alespoň 4 disky), které poskytují optimální kombinaci nákladů, spolehlivosti a výkonu. Někteří uživatelé také používají RAID5, obětují výkon pro větší prostor.

Konfigurace RAID pro Firebird

Především byste se měli ujistit, že je v RAID správně nabitá záložní bateriová jednotka (BBU). Pokud taková bateriová jednotka není, většina RAID přepne do bezpečného režimu zápisu (mezipaměť disku je zcela zakázána), což poskytuje nižší rychlost vstupu/výstupu než běžný SATA disk!

Tato skutečnost způsobuje většinu frustrovaných zpráv na technickou podporu od uživatelů, kteří si zakoupili drahý server a zjistili, že pracuje pomaleji než stolní počítač. Bohužel někteří prodejci nezahrnují bateriové jednotky ve výchozím nastavení, proto je to první věc, kterou byste měli zkontrolovat a případně opravit.

Poté byste měli nakonfigurovat mezipaměť pro čtení a zápis. Často je mezipaměť ve výchozím nastavení zakázána, a pokud chcete, aby byl RAID poměrně rychlý, musíte mezipaměť povolit.

Kromě povolení mezipaměti byste měli zkontrolovat, jak funguje - může být write through a write back. Rychlý způsob práce s mezipamětí je write back - v tomto případě jsou všechny změny zapsány do řadiče mezipaměti a po chvíli přímo na disk.

Můžete použít nástroje od výrobců dodávané s RAID ke kontrole bateriové jednotky, mezipaměti a režimu.

Moderní RAID řadiče mohou také jemně vyladit mezipaměť - lze ji upravit pro usnadnění čtení nebo zápisu. Obvykle je rozdělena 50%/50% pro čtení a zápis.

Chcete-li zjistit, jak přesně nakonfigurovat mezipaměť, můžete také použít nástroj MON$ Logger z pokročilého distribučního balíčku HQbird. Zobrazuje poměr operací čtení a zápisu k sobě navzájem (agregovaný od okamžiku prvního připojení k serveru):

Obrázek 8. HQbird MON$Logger: poměr čtení/zápisu

Jak vidíte, v tomto příkladu je mnohem více operací čtení než operací zápisu, takže má smysl nakonfigurovat RAID řadič pro 80% operací čtení a 20% operací zápisu.

SAN a databáze

Integrovaná úložiště se v poslední době stala populární. Zahrnují flexibilně přizpůsobitelné pole disků (všechny typy RAID) s pokročilými funkcemi mezipaměti. Obvykle mají SAN několik řadičů vstupu/výstupu, což umožňuje obsluhovat několik serverů současně a pracovat poměrně rychle.

Mnoho organizací nakupuje SAN a používá je při práci s databázemi Firebird. Pokud je SAN správně nakonfigurován, je možné dosáhnout dobrého výkonu. Měli byste vzít v úvahu následující problémy, pokud používáte SAN:

Musí být k dispozici několik vysoce výkonných řadičů disků, které poskytují vícekanálovou výměnu dat.
Musí být přítomny záložní bateriové jednotky (BBU), pokud jsou konstrukčně zajištěny.
Databázové disky musí být spojeny do RAID10.
Mezipaměť musí být povolena, režim zápisu musí být přepnut na write back.
Pokud je k SAN připojeno několik počítačů, každý z nich musí mít svůj vlastní řadič.
Jsou nainstalovány nejnovější ovladače SAN. Setkali jsme se s případy, kdy pozdější ovladače poskytly 30% nárůst výkonu.
Pokud je na SAN několik logických disků (pro databáze, záložní kopie, operační systém), mají různé kanály vstupu/výstupu. Pokus použít jeden kanál pro všechny disky najednou povede k nižšímu výkonu.
Podobně, pokud několik serverů a databází používá SAN současně, může být výkon nižší kvůli zvýšené šířce pásma řadičů vstupu/výstupu.
Často se používají kombinované způsoby - když jsou operační systém a dočasné soubory uloženy na lokálních discích, zatímco databáze a záložní soubory jsou uloženy na SAN.

Často se SAN používají jako “dva servery - jeden SAN” za účelem vytvoření clusteru odolného proti selhání. Je třeba poznamenat, že takový cluster může vyřešit problémy související pouze s hardwarovými poruchami na jednom ze serverů přepnutím na druhý server okamžitě. Pokud je problém spojen se SAN nebo samotnou databází, toto řešení nepomůže.

Pro vytvoření skutečně řešení odolného proti selhání byste měli použít řešení replikující data mezi dvěma instancemi databáze. Můžete kontaktovat [email protected], abyste se dozvěděli více dostupných řešení pro Firebird.

Stručné závěry a doporučení

Shrňme závěry a doporučení pro Firebird týkající se hardwaru.

Pro obsluhu velkého počtu uživatelů musí být použity vícejádrové CPU.
Minimální množství RAM se vypočítává na základě počtu uživatelů a konfigurace databáze, přebytečné množství RAM bude efektivně využito operačním systémem pro ukládání databázového souboru do mezipaměti.
Používejte samostatné disky pro databáze, dočasné soubory a záložní soubory.
Pro databáze raději použijte SSD.
Rezervujte alespoň 30% volného místa na SSD.
Je vhodné vyhradit disk pro databázi.
Používejte podnikové SSD (s velkým počtem cyklů zápisu/čtení).
Ujistěte se, že používáte RAID.
Pro SSD - RAID 1, pro HDD - RAID10, pro záložní HDD - RAID1. i. SAS, SATA, nSAS
Ujistěte se, že je RAID baterie přítomna a nabitá.
Ujistěte se, že je přepnuta na write back.
Některé RAID řadiče mají velikost mezipaměti již nakonfigurovanou, například 75% pro čtení, 25% pro zápis, nebo 50/50 atd. Proto je nutné nainstalovat MON$Logger - software, který bude řídit parametry RAID, sledovat poměr čtení/zápisu a měnit nastavení RAID.
Použití SAN má své výhody a nevýhody. Abyste z něj získali maximum, měli byste SAN správně nakonfigurovat.
Pro vytvoření řešení odolného proti selhání musíte použít řešení s replikami běžícími na různých serverech.

Kontakty

Společnost IBSurgeon/IBase.ru vyvíjí pokročilý distribuční balíček HQbird pro podniky, poskytuje komplexní technickou podporu pro Firebird a vyvíjí přizpůsobené distribuční balíčky, stejně jako řeší další složité problémy.

IBSurgeon také nabízí službu optimalizace Firebird pro zlepšení výkonu databáze Firebird.

Kontaktujte nás: [email protected]