Snížení výkonu Firebird: testy, mýty a pravda
Alexey Kovyazin, 16. května 2014
Tento článek si můžete stáhnout ve formátu PDF.
Nedávno jsme v IBSurgeon provedli sérii výkonnostních testů s Firebird 2.5.2. Firebird 2.5.2 je nejpopulárnější verzí databáze Firebird a její uživatelé mají často otázky související s výkonem Firebirdu.
Jedním z nejdůležitějších problémů týkajících se výkonu databáze je její degradace. Mnoho uživatelů tvrdí, že jejich databázové aplikace mají problémy s výkonem při dosažení určité prahové hodnoty: může to být 3 GB, 5 GB, velikost RAM, 20 GB atd. Nejčastější tvrzení je „velikost databáze je větší než velikost RAM“: když velikost databáze Firebird dosáhne velikosti RAM, údajně začne být velmi pomalá… Je to pravda?
Rozhodli jsme se provést sérii testů, abychom ověřili, zda taková degradace výkonu související s růstem databáze existuje. Rozhodli jsme se simulovat celoživotní růst databáze se stejným zatížením na stejném hardwaru, a proto jsme spustili 11 testů s databázemi o velikosti mezi 9 GB a 30 GB:
Obrázek 1. Velikosti databází pro testy
Testovací hardware a konfigurace Firebirdu
Testovací hardware měl následující klíčové charakteristiky:
CPU AMD-FX8350, RAM 16 GB, SATA software RAID1 2x4TB Seagate disky, operační systém Windows Server 2008R2 (2008R2 je 64bitový).
Jak vidíte, jedná se o low-end hardwarovou konfiguraci; lze ji v současnosti (květen 2014) pořídit za méně než 1000 USD a lze ji považovat za typickou low-level konfiguraci - možná s výjimkou velkých SATA disků, ale podle zprávy výrobce je rychlost 1TB a 4TB SATA disků téměř stejná.
Protože cílem testu bylo změřit změny výkonu typického systému, použili jsme Firebird (64bitový) s architekturou SuperServer, nikoli Classic, abychom zcela simulovali situaci v malé společnosti - používají to, co bylo původně nainstalováno po léta. Jak víte, SuperServer využívá pouze 1 jádro CPU, takže pravděpodobně Classic nebo SuperClassic (které mohou využívat všechna jádra CPU) by mohly vykázat lepší výsledky z hlediska výkonu, ale naším cílem nebylo ladění výkonu.
Nicméně jsme upravili firebird.conf se zřejmými změnami, které doporučujeme pro všechny instalace Firebird SuperServer: zvýšené page buffery na 10000 a dočasný prostor pro třídění.
Všechny testovací databáze byly vytvořeny s velikostí stránky 16384, pouze pro konzistenci.
Testování
Načítání
Každý test obsahoval 2 kroky: načítání a simulaci 20 terminálů, které provádějí inserty, update a delete.
Krok načítání provádí loader aplikace (load.exe), která vkládá data do několika tabulek. Jak vidíte na obrázku 2, data jsou načítána různou rychlostí; pohybuje se od ~35 Mb/s do 1 Mb/s.
Obrázek 2. Rychlost načítání databáze (červený graf)
To souvisí s návrhem loader aplikace, nikoli s Firebirdem: loader rychle vloží 70 % databáze a poté pomalu doplní zbytek dat, a to se opakuje u databází všech velikostí. Je pro nás důležité, že loader provádí stejné operace, takže můžeme použít jeho průměrnou rychlost k měření rychlosti načítání.
Je důležité zmínit, že loader vkládá pouze data a indexy jsou vytvořeny po dokončení načítání.
Podívejme se na tabulku s výsledky kroku načítání pro 11 databází mezi 9 a 30 GB:
| # | velikost databáze, GB | čas načítání, sec | rychlost načítání SATA, Mb/s |
|---|---|---|---|
| 1 | 9,04 | 2535 | 3,65166075 |
| 2 | 10,80 | 3197 | 3,45924304 |
| 3 | 13,00 | 4057 | 3,281242297 |
| 4 | 15,50 | 4698 | 3,378458919 |
| 5 | 17,30 | 5455 | 3,24751604 |
| 6 | 19,90 | 6037 | 3,375451383 |
| 7 | 21,60 | 6473 | 3,417024564 |
| 8 | 24,20 | 7539 | 3,287014193 |
| 9 | 26,00 | 7779 | 3,422547885 |
| 10 | 28,60 | 8851 | 3,308823862 |
| 11 | 30,30 | 9266 | 3,348499892 |
Obrázek 3. Čas a rychlost načítání
Nebo je lepší zobrazit to na grafu na obrázku 4:
Obrázek 4. Výsledky testů: rychlost načítání.
Jak vidíte, graf je poměrně stabilní a průměrná rychlost procesu načítání se pohybuje kolem 3,3-3,4 Mb/s. Nejsou zde také žádné známky klesající rychlosti načítání, když velikost databáze přesáhne velikost RAM (po databázi #5, s velikostí 17,3 GB).
Výkon
Časy načítání vypadají tedy docela slibně, ale co skutečné výsledky výkonu?
Než přejdeme k výsledkům výkonu, rychle si zopakujme proces simulace.
Simulace spouští 20 vláken a každé z nich náhodně provádí několik obchodních operací: vytvoření nové objednávky, zpracování platby, počítání produktů na skladě, zpracování dodání objednávky atd. (podrobnosti najdete v SQL textech skutečných uložených procedur). Jak vidíte, jedná se o obvyklou sadu obchodních operací abstraktní inventární/prodejní aplikace.
Testovací aplikace měří počet obchodních operací za sekundu a hlásí průměrný počet. Toto číslo je samozřejmě umělý parametr, ale je dostatečně dobré pro srovnání.
Výsledky výkonnostních testů:
| # | velikost databáze, GB | výkon na SATA |
|---|---|---|
| 1 | 9,04 | 494,73 |
| 2 | 10,80 | 491,94 |
| 3 | 13,00 | 480,36 |
| 4 | 15,50 | 469,11 |
| 5 | 17,30 | 446,42 |
| 6 | 19,90 | 431,61 |
| 7 | 21,60 | 426,85 |
| 8 | 24,20 | 424,5 |
| 9 | 26,00 | 414,04 |
| 10 | 28,60 | 409,14 |
| 11 | 30,30 | 407,97 |
Obrázek 5. Tabulka s výsledky výkonnostních testů.
Nebo je lepší zobrazit výsledky v grafické podobě:
Obrázek 6. Graf výsledků výkonu
Jak vidíte, dochází k pomalé degradaci výkonu s růstem velikosti databáze - čím větší databáze, tím pomaleji bude pracovat (na stejném hardwaru). Neexistuje také žádný velký pokles výkonu, když velikost databáze přesáhne velikost RAM. Růst databáze z 9 GB na 30 GB vede k přibližně 20% ztrátě výkonu.
30GB databáze Firebird jsou dnes všude a stále rostou. Co se ale stane s výkonem databáze, když bude ještě větší? Máme na mysli - VĚTŠÍ! Co se stane s výkonem, když bude databáze OPRAVDU VELKÁ?
Mr.Big
Abychom odpověděli na tuto otázku, rozhodli jsme se podívat na úplný konec testovací tabulky a provést test s databází o velikosti 1,7 TB (1813 GB), na stejném hardwaru, se stejným nastavením.
Načítání
Vytvořili jsme tedy takovou databázi:
Obrázek 7. Velikost databáze - nyní s databází 1813 GB
Načítání trvalo 566448 sekund - 157 hodin, 6,55 dne. To je dlouhá doba, ale průměrná rychlost načítání byla… 3,28 Mb/s!
| # | velikost databáze, GB | čas načítání, sec | rychlost načítání SATA, Mb/s |
|---|---|---|---|
| 12 | 1813,969025 | 566448 | 3,279214122 |
Obrázek 8. Čas a rychlost načítání pro databázi Firebird 1.7TB
Na grafu to vypadá velmi dobře: poslední bod (#12). Firebird tedy vykazuje velmi dobré výsledky svých vkládacích algoritmů.
Obrázek 9. Rychlost načítání - bod #12 je pro databázi Firebird 1.7TB
Výkon Mr.Big
Poté jsme spustili stejný výkonnostní test - řádek 12 je pro databázi 1.7TB.
| # | velikost databáze, GB | výkon na SATA |
|---|---|---|
| 1 | 9,04 | 494,73 |
| 2 | 10,80 | 491,94 |
| 3 | 13,00 | 480,36 |
| 4 | 15,50 | 469,11 |
| 5 | 17,30 | 446,42 |
| 6 | 19,90 | 431,61 |
| 7 | 21,60 | 426,85 |
| 8 | 24,20 | 424,5 |
| 9 | 26,00 | 414,04 |
| 10 | 28,60 | 409,14 |
| 11 | 30,30 | 407,97 |
| 12 | 1813,969025 | 169,33 |
Obrázek 10. Výsledky výkonnostních testů - řádek 12 je pro databázi 1.7TB
A na grafu:
Obrázek 11. Výkon, bod #12 je pro databázi 1.7TB
Výsledek potvrzuje, že ve Firebirdu dochází k pomalé a stabilní degradaci výkonu - zatímco velikost databáze vzrostla 60krát (z 30 GB na 1813 GB), ztráta výkonu byla 2,4krát (ze 407 na 169 bodů).
Není to častá situace, kdy databáze (na stejném low-end hardwaru) vzroste z 30 GB na 1,7 TB, ale Firebird bude fungovat i v této situaci.
Velká databáze podrobně
Pro lepší pochopení databáze 1.7TB jsme shromáždili statistiky databáze pro databázi Mr.Big a analyzovali je v IBAnalyst:
Obrázek 12. Tabulky databáze 1.7TB v IBAnalyst
Jak vidíte, existují 2 velké tabulky - ORDER_LINE (~600 GB) s 6,3 miliardami záznamů a STOCK (~680 GB) s 2,1 miliardami záznamů.
A pro tyto tabulky existují 2 indexy s hloubkou = 4 - to znamená, že každý požadavek provede 4 čtení indexových stránek před skutečným čtením dat. Index ORDER_LINE_PK má velikost 50 GB.
Obrázek 13. Indexy databáze Firebird 1.7TB
Navzdory obrovskému počtu záznamů vypadají statistiky databáze dobře, takže není překvapením, že Firebird vykazuje docela dobré výsledky i pro velkou databázi na low-end hardwaru.
Testování Firebirdu s SSD diskem
Po dokončení série testů Firebirdu na low-end hardwaru jsme se rozhodli zkontrolovat, jaké budou výsledky na druhém konci technologie ukládání dat, a nainstalovali jsme SSD disk na stejný server.
Nainstalovali jsme SSD disk Plextor PX-256M M5 Pro a spustili stejnou sérii testů (kromě databáze 1.7TB) se stejným nastavením. Výsledky byly přidány do grafů se SATA zařízeními, viz níže.
Načítání
Jak vidíte, čas načítání na SSD je stejný jako na SATA. To je očekávaný výsledek: rychlost sekvenčních zápisů je na SATA a SSD discích téměř stejná.
Obrázek 14. Načítání na SSD a SATA
Výkon
Podívejte se na výsledky výkonu:
Obrázek 15. Výkon na SSD a SATA
Jak vidíte, výkon s náhodnými IO operacemi vykazuje ~8x lepší výsledky pro SSD disk. Z našich zkušeností s databázemi zákazníků jsme věděli, že SSD je u reálných aplikací o 30-50 % rychlejší, ale 8násobné zvýšení je velmi vysoké.
Tento test je však umělý a speciálně navržený k simulaci vysoce zatížených OLTP operací s mnoha updaty/delety, ale bez velkých fetchů. Běžná databázová aplikace nepracuje v tomto režimu neustále. To vysvětluje, proč SSD vykazuje v tomto konkrétním případě tak vysoké výsledky.
Shrnutí
Co jsme se tedy z těchto testů naučili?
Především - výkon Firebirdu nemá velké poklesy související s nějakým omezením velikosti. Na stejném hardwaru bude výkon pomalu klesat s růstem velikosti databáze. Tento pokles výkonu lze kompenzovat laděním konfigurace Firebirdu nebo chytrým upgradem hardwaru.
Je vhodné zmínit, že IBSurgeon nabízí službu optimalizace výkonu Firebirdu - pomocí experimentálních dat, která jsme shromáždili z testů, jako jsou tyto, můžeme výrazně zvýšit výkon databází Firebird a InterBase.
Dále jsme zjistili, že i velmi velké databáze Firebird (1,7 terabajtu) budou fungovat na low-end hardwaru s významnou, ale přijatelnou ztrátou výkonu.
A za třetí, SSD je opravdu dobrý pro OLTP aplikace. Pravděpodobně je to v současnosti nejlevnější způsob, jak zvýšit výkon databáze. Samozřejmě, použití SSD nevyřeší problémy se špatnými plány dotazů a neefektivními indexy, ale může obecně zvýšit výkon.
Pokračování: Další podrobnosti o 1,7 terabajtové databázi Firebird.