Úskalí provozování databázového serveru na Windows

S jakými problémy jsem se setkal při provozování data warehousingu na DB2 v prostředí Windows.

16.7.2010 00:00 | Radim Kolář | přečteno 736×

Platforma windows, která má nyní podle odhadů 60-70% na serverech je nasazována oproti linuxu zejména z následujících důvodů:

1. Větší dostupnost windows administrátorů

2. Windows administrátor je levnější a potřebuje méně znalostí - naprostou většinu věcí nakliká

3. Firemní politika

4. Software je k dispozici právě jen pro tento OS

5. Snadná instalace software, instalační program zařídí vše potřebné

Má ale i své nevýhody:

1. Nestabilita

2. Nižší výkon

3. Z ničeho nic se oběvující problémy

4. Windows registr, rád se poškozuje

5. Je potřeba rezignovat na požadavek bezproblémového provozu

6. Prostředí je dost komplexní - špatně se diagnostikují problémy

Před necelým půl rokem jsem nasadil jednu database warehouse aplikaci na windows server. Důvod pro vybrání windows byl jednak získat praktické zkušenosti s provozem na windows a jednak si ušetřit práci s konfigurací během a po instalaci. Jednalo se o kombinaci IBM DB2 9.7 databáze a Websphere aplikačního serveru.

Počátační testy po instalaci asi nad 1 GB dat vypadaly dobře a tak jsem to už na windows nechal. Asi za 3 týdny se objevily první problémy které byly způsobené nárůstem oběmu zpracovávaných dat. Systém byl pomalý, to co trvalo několik minut mu trvalo i hodiny. Analýza problému ukázala na swapování. Bylo především divné, že systém vůbec swapuje protože monitorovací utilita ukazovala přes 1,2 GB RAM free. Po konzultaci s experty na windows jsem se dozvědel že pokud má server dobře šlapat je potřeba počítat s 2 GB Ram vyhrazeným pro OS Windows (bez aplikací). U Linuxu se počítá 256 MB RAM pro OS + nějaká ta RAM navíc pro cache. Tak jsem si šel tu ramku znova přepočítat podle doporučení Windows expertů a vyšlo mi toto:

1. 2GB Overhead windows OS

2. 1GB Overhead websphere

3. 1GB Overhead DB2

4. 0,5GB paměti pro J2EE aplikaci

5. 2 GB paměti pro DB2.

Tak jsem vzal 8 GB RAM, tedy dvojnásobek s čím to běželo na linuxu.

Dalším podstatným problémem, který se oběvil byla fragmentace souborů na disku. Microsoft používá velmi špatný algoritmus pro alokaci volných bloků ať se již jedná o fs FAT32 nebo NTFS. Způsobuje značnou fragmentaci souborů a proto je potřeba často a pravidelně defragmentovat. Pro zajimavost se podívejte jak rozfragmentované byly databázové soubory:

Velikost souboru / počet fragmentů
2,13GB 34316
4,53GB 64791
8,00GB 36395
477MB  4168
4,56GB 1046

Kdyby databáze dělala OLTP tak tam by fragmentace nevadila kromě velmi pomalých záloh. V OLTP se zpracovávají náhodné malé bloky dat zatímco u data warehouse se často procházejí celé tabulky a DB2 optimalizér počítá při generaci přístupového plánu s tím že nejsou výrazně fragmentované. Jak vidíte z tabulky, v našem případě jsou sobory fragmentované velmi výrazně. Špatná zpráva je ta, že defragmentovač obsažený ve Windows je dost slabý a v některých případech neumí soubory defragmentovat. Ne že by je neuměl defragmentovat zcela, to by zase tak nevadilo, on je neumí defragmentovat vůbec. Zakoupil jsem proto komerční NTFS defragmentič a nařídíl každý den defragmentovat databázové soubory.

Když se Windows poskytne potřebná péče tak pak poskytují přijatelný výkon. Import 1M záznamů do 2 tabulek o 150M a 10M záznamů.

Rows: 1000000 read, 0 rejected, 1000000 commited.
Mon Jul 12 13:46:48 CEST 2010 Processing loaded data.
Mon Jul 12 13:49:50 CEST 2010 Done.

Navíc je použit jen jeden SATA disk, při použití více disků či více RAM bychom dostali výrazně lepší výkon. Jeden disk pro indexy, druhý pro data, třetí pro temporary space a čtvrtý pro protokolační soubory - abychom rozložili IO zátěž.

Jak je vidět z Windows se dobrý výkon sice vyrazit dá, ale je k tomu potřeba narozdíl od Linuxu vyvinout nadstandardní úsilí a navíc je to pak ve stavu sice to chodí, ale kdo ví co se rozbije příště. Podobné zkušenosti mám s provozováním Lotus Notes serveru - Win vs Linux.

Verze pro tisk