Alexey Kovyazin, 14. července 2014

Jak si pamatujete z našich předchozích článků, zkoumali jsme mýty o degradaci výkonu Firebirdu ( /cs/articles/firebird-performance-degradation-tests-myths-and-truth/), kde jsme vytvořili několik databází od 9Gb do 30Gb a také testovali velmi velkou databázi Firebird (1,7 terabajtu) (/cs/articles/more-details-about-1-7-terabyte-firebird-sql-database/).

Všechny testy proběhly na stejném hardwaru, což je poměrně nízkorozpočtová konfigurace: CPU AMD-FX8350, RAM 16GB, SATA software RAID1 2x4Tb HDD Seagate disky, operační systém Windows Server 2008R2 (2008R2 je 64bitový), a se stejnou konfigurací Firebirdu: Firebird 2.5.2 64-bit, SuperServer, se zvýšenými page buffery a TempCacheSize. Tento konfigurační soubor SuperServer si můžete zdarma stáhnout z tohoto umístění: /cs/optimized-firebird-configuration/

Výsledkem byl následující obrázek výkonu databáze:

![Firebird performance 1813Gb (1.7Tb)](/images/performance/perf7_performance_with 1800Gb_Firebird_database.png)

Obrázek 1. Degradace výkonu od 9Gb do 30Gb a 1,7Tb

Bod #11 je výkonnostní známka pro 30Gb databázi a #12 pro 1,7 terabajtovou databázi - velikost databáze vzrostla 60krát (z 30Gb na 1813Gb), ztráta výkonu byla 2,4krát (ze 407 na 169 bodů).

Otázka tedy zní: můžeme zlepšit výkon Firebirdu na stejném hardwaru pomocí úprav konfigurace?

A odpověď je: ano!

Supercharging FirebirdSQL

Jak si pamatujete, v tomto testu jsme spustili 20 souběžných připojení, která provádějí intenzivní INSERTy a méně intenzivní UPDATEy.

Všechny SELECTy jsou krátké a dobře definované, s efektivními plány provádění SQL, takže se jedná o typickou OLTP (online transakční zpracování) aplikaci. Pro takové aplikace je nejkritičtější věcí pro výkon paralelní zpracování. Firebird SuperServer 2.5.2 není dobře uzpůsoben pro vícevláknové zpracování - efektivně využívá pouze 1 jádro na databázi, a tento fakt dělá SuperServer nepříliš dobrou volbou pro OLTP aplikace.

Proto potřebujeme změnit architekturu Firebirdu na Classic nebo SuperClassic, které podporují vícevláknové zpracování a využívají více jader CPU (v CPU AMD-FX8350 je 8 jader).

Poté je potřeba určité ladění, protože výchozí konfigurace Firebirdu není optimální pro náš testovací systém.

Ladění parametrů v firebird.conf

Page cache

Abychom zlepšili výkon OLTP, rozhodli jsme se vyzkoušet architektury Classic a SuperClassic. Jedním z klíčových parametrů pro Classic a SuperClassic je počet page bufferů v mezipaměti. Na rozdíl od SuperServeru alokují Classic a SuperClassic page cache pro každé připojení.

Pro více podrobností o architekturách Firebirdu ve verzi 2.5 si můžete prohlédnout tuto tabulku: http://www.firebirdsql.org/file/fb25.architecture_comparison.pdf

Existuje jednoduchý vzorec pro výpočet využití paměti page cache pro různé architektury Firebirdu:

1. SuperServer - jedna page cache na databázi. Výchozí velikost page cache je 2048 stránek, doporučení je 10000 bufferů. V našem případě byla cache 16k (velikost stránky) x 10000 ~= 160Mb. To je pro všechna připojení.
1. Classic a SuperClassic - engine alokuje page cache pro každé připojení. Výchozí velikost je 75 stránek, takže 16Kb (velikost stránky) x 75 = ~= 1,17 Mb pro každé připojení.

Je zřejmé, že velikost page cache by měla být zvýšena, protože 75 stránek na připojení je příliš málo. Níže ukážeme výsledky několika různých hodnot pro velikost page cache.

LockHashSlots

Interně používá engine Firebirdu lock table k žádostem a získávání zámků pro interní objekty v databázi, a pro Classic a SuperClassic existuje parametr LockHashSlots (výchozí hodnota je 1009). Měl by být zvýšen při vysokém zatížení, aby se snížily hash řetězce v lock table. No, „vysoké zatížení“ se zdá být jakákoli reálná víceuživatelská aplikace, takže jsme jej nastavili na 30011 (pro všechny testy).

LockMemSize

Parametr LockMemSize se používá k nastavení počáteční velikosti lock table (výchozí hodnota je 1048576). Engine může velikost tabulky zvýšit podle potřeby. Zvýšení lock table je však nákladné z hlediska CPU a dalších zdrojů, protože se provádí prostřednictvím remapování paměti. Proto jsme jej nastavili na 7Mb, abychom ušetřili nějaký čas a CPU zdroje.

Testovací běhy

Provedli jsme několik testovacích běhů s různými hodnotami page cache s následujícími výsledky:

Page buffers	Classic, testovací body	SuperClassic, testovací body
256	299	372
512	371	359
768	362	386
1024	312	387
1500	390	392
2048	285	284

Tabulka 1. Testovací běhy pro Classic a SuperClassic

Jak vidíte, Classic a SuperClassic jsou pro tento úkol mnohem efektivnější než Firebird SuperServer: výsledky testů se zlepšily ze 169 bodů na 300-400, což se blíží výsledkům, které jsme měli pro 30Gb databázi!

Výsledky je lépe vidět na následujícím grafu:

Firebird performance 1813Gb (1.7Tb)

Obrázek 2. Výsledky testů pro 1,7 terabajtovou databázi

Můžete vidět, že nejlepší výkon (jak u Classic, tak u SuperClassic) byl při 1500 stránkách na připojení, takže velikost page cache na připojení byla:

1500x16k ~= 23,4Mb

Při 2000 stránkách na připojení se výkon výrazně snížil. Zdá se, že někde kolem 1500-2000 stránek se výhoda cachování stala menší než režie způsobená interakcemi lock table mezi procesy při synchronizaci stránek v mezipaměti každého serverového procesu. Je zřejmé, že při vyšším počtu připojení k tomu dojde dříve, a proto jsou servery Classic/SuperClassic obvykle konfigurovány s hodnotami jako 256-512 stránek.

Došlo také k poklesu výkonu Classic kolem 768-1000 page cache - nejsme si jisti, proč se to stalo.

Shrnutí

Naše experimenty potvrzují, že výkon Firebirdu lze zvýšit správným výběrem architektury Firebirdu (SuperServer, Classic nebo SuperClassic) a vhodným laděním několika důležitých parametrů pro konkrétní architekturu.

Výsledkem je, že obrovská 1,7 Tb databáze Firebird SQL může pracovat na nenáročném hardwaru s dostatečně dobrým výkonem. Jako praktický výstup z těchto testů jsme vytvořili několik konfiguračních souborů pro všechny verze Firebirdu pro všechny architektury. Samozřejmě nejsou vyladěny pro konkrétní aplikaci a/nebo hardware, ale jsou lepší než výchozí konfigurační soubory, které jsou vytvořeny pro velmi mírné zatížení.

Kompletní sada optimalizovaných konfiguračních souborů Firebirdu: /cs/optimized-firebird-configuration/

Neváhejte se ptát na jakékoli dotazy: [email protected]

Co dál?

Pracujeme na komplexním testu, který porovná výkon Firebirdu 2.5 a Firebirdu 3.0, s realistickou simulací zatížení a velkým počtem připojení. Zůstaňte naladěni!