Testování operační paměti
Značkové servery jsou předem alespoň minimálně otestovány již výrobcem, a tak není třeba věnovat testům paměti RAM zvýšenou pozornost. Jediný kvalitní, prakticky použitelný program pro testování paměti na i386 je memtest86. Stáhneme a nainstalujeme na disketu či CD. Po nabootování zapneme v menu všechny testy a necháme několik hodin běžet. Mezitím si stáhneme a vypálíme (pokud už nemáme) CD-ROM image live Linux distribuce Knoppix. Pokud již Knoppix máme, lze tento čas využít ke studiu dokumentace k HW RAID řadiči.
Testování disků
Všechny disky včetně systémového rovnoměrně rozmístíme mezi jednotlivé kanály SCSI řadiče, s nastavováním SCSI ID a HW RAIDU se není třeba zabývat. HW RAID necháme zatím ještě vypnutý. Pokud systém po zapnutí najde všechny disky správně, nabootujume si z CD-ROMky do Knoppixu. Překontrolujeme, zda i Linux správně našel všechny disky.
Pro testování povrchu disků před uvedením do provozu je vhodné použít program Data Test – dt. Program lze bez problémů na námi nabootovaném Knoppixu přeložit. Při překladu na Linuxu se nepokoušejte aktivovat volbu pro použití asynchroních IO operací. Tyto operace nefungují v Linuxu 2.4 spolehlivě a často hlásí chyby i v případě správně fungujícího disku. Na FreeBSD 5.2 pracuje AIO spolehlivě.
Program dt má poměrně značné množství voleb – většinu ani nebudeme potřebovat. K programu je však dodávána velice obsáhlá dokumentace, která základní seznámení s programem urychlí. Doporučuji do ní alespoň nahlédnout, a ocenit tak kvality programu s mnohaletou historií. Program dt je také velice užitečný při simulaci různých typů filesystémové zátěže.
Program dt se ovládáním velice podobá známému programu dd. Podobně jako dd má parametry if= a of=. Tyto parametry slouží k určení souboru nebo zařízení, na kterém bude test prováděn. if= slouží k určení zařízení pro read-only test a of= slouží pro read/write test.
Nejprve budeme testovat jednotlivé fyzické disky. Spustíme příslušný počet programů dt, pro každý disk jeden. Použijeme tyto volby:
dt of=/dev/sda flags=direct,fsync errors=999999 incr=variable min=512
max=256k runtime=1d
K parametrům: of= označuje jméno blokového zařízení příslušného disku, flags zakazují použití cache, errors je maximální počet tolerovaných chyb během testu, min a max označují minimální a maximální velikost testovacího záznamu, incr označuje náhodnou změnu velikosti záznamu v průběhu testu a konečně runtime nastavuje celkovou dobu testu na jeden den.
Konfigurace dataspace
Dataspace pro databázový server můžeme rozdělit mezi jednotlivé fyzické disky několika způsoby: manuálně, pomocí RAID diskového pole, nebo za použití kombinace obou metod. Dataspace se snažíme rozdělit tak, abychom co možná nejrovnoměrněji rozprostřeli zátěž mezi jednotlivé disky a současně minimalizovali počet nutných přesunů diskových hlaviček během provozu databáze.
Ruční rozdělení
Optimální rozdělení databázového prostoru mezi jednotlivé disky je zevrubně probíráno v manuálech k jednotlivým databázovým serverům. Mírně se sice liší podle použitého serveru, ale zhruba vypadá takto:
Typy databázových prostorů
V databázi se vyskytuje několik typů databázových prostorů. Ne všechny databáze používají všechny zde uvedené typy. Například PostgreSQL nemá rollback, undo log a ani náznak koncepce TABLESPACE-INDEXSPACE.
TYP | Převažující typ Přístupu | Velikost IO transakce | R Aktivita | W aktivita |
---|---|---|---|---|
1. ROLLBACK SEGMENT | sekvenční | velká | minimální | velká |
2. TEMPORARY SEGMENT | sekvenční | velká | střední | střední |
3. TABLESPACE | spíše sekvenční | střední | velká | střední |
4.INDEXSPACE | náhodný | malá | velká | velká |
5. REDO-UNDO LOG | sekvenční | velká | minimální | velká |
6. SYSTEM DICTIONARY | náhodný | malá | minimální | minimální |
7. ARCHIVE LOG | sekvenční | velká | minimální | velká |
8. DIST. TRANSACTION LOG | sekvenční | malá | minimální | střední |
Hlavní zásady pro ruční rozdělování prostoru
Na fyzicky odlišných discích by měly být tyto prostory:
- Datové prostory, ke kterým se přistupuje během většiny databázových operací současně.
- Dočasné prostory současně pracujících uživatelů.
- Prostory se synchronním zápisem.
Využívání jednotlivých prostorů
Prostory používané při read-only transakcích jsou: 2, 3, 4. Při zápisu použijeme navíc prostory 1 a 5, u 2-phase commit transakcí potřebujeme ještě 8. Prostory 5 a 8 jsou zapisovány synchronně na disk. Disková aktivita v prostoru 6 je minimální, většina dotazů se obsluhuje z cache.
Příklad ručního rozdělení databáze pro 6 disků
Začneme tím, že prostory 2,3,4 umístíme na různé disky. Prostory se synchroním zápisem 5 a 8 dáme na čtvrtý disk. Zbývají nám dva disky a prostory 1,6,7. Prostor 6 přidáme na stejný disk k prostoru 3. Zbývající prostory 1 a 7 jsou asynchroní write-only, a tak je můžeme dát společně na pátý disk. Co s posledním diskem? Využijeme jej k tomu, abychom odlehčili ostatním diskům. Podle převažujícího typu zátěže jej použijeme pro:
Typ zátěže | Použití disku |
---|---|
velké sorty | TEMPORARY |
update velkých tabulek | INDEXSPACE |
full table scanny | TABLESPACE |
Ruční rozdělování jednotlivých prostorů mezi dostupné disky je považováno za umění. Optimálního rozdělení dosáhnete až po několika pokusech následovaných potřebnou dobou pro sledování chování databáze v praxi.
Nevýhody ručního rozdělení databázového prostoru
Ačkoliv si mnoho databázových administrátorů na ručním dělení dataspace mezi disky zakládá, v dnešní době se již ruční rozdělování databázového prostoru nevyplatí. Na ruční rozdělení je potřeba vynaložit značné úsilí: Nejprve je třeba pečlivě rozdělení naplánovat, potom provést export/import dat a nakonec sledovat chování databáze v provozu. Pokud výsledný efekt není takový, jaký bychom si přáli (máme šest disků, ale během provozu povětšinou blikají kontrolky jen u dvou), je nutné celý proces opakovat.
Data a Indexy zvlášť
V databázových příručkách se již po mnoho let dočítáme jednu základní poučku: indexy na jeden disk, data na druhý. Tato poučka není úplně chybná. Rozdělit zátěž mezi dva disky je o mnoho lepší než nechat vše na jednom. Pokud často vybíráme pouze malou část z tabulky, tak databáze používá současně indexy i data a je dobré, že jsou na odlišných discích.
Tato poučka ovšem nezohledňuje několiv věcí:
- Aktivita v indexovém prostoru je vždy větší než v datovém prostoru. Tento rozdíl se ještě zvětší při zápisu do tabulek.
- V praxi s databází aktivně pracuje několik uživatelů současně, takže i k datovému disku se nebude přistupovat sekvenčně, ale náhodně.
RAID je pro rozdělení zátěže lepší
Vzhledem k těmto okolnostem (nerovnoměrné rozdělení zátěže, náhodný přístup) doporučuji použít místo známého pravidla pro distribuci zátěže RAID pole. V našem případě to bude RAID-0, které zajistí rovnoměrné rozdělení zátěže mezi oba dva disky. Pokud bychom chtěli navíc zvýšit odolnost proti výpadku jednotlivých disků, mohli bychom použít pole v konfiguraci RAID-1. Toto pole však rozdělí pouze čtecí zátěž mezi oba disky, a je proto vhodné pouze v případě, kdy je většina databázových operací read-only.