V návaznosti na Ladění Linuxu pro nízkou PostgreSQL latenci z minulého měsíce byla nyní provedena obrovská hromada testování na dvou souborových systémech, třech záplatách a dvou sadách parametrů ladění jádra. Dosavadním výsledkem jsou některá zajímavá nová data a ještě jedno další vylepšení v této oblasti, která jsou nyní v PostgreSQL 9.1 (celkem tři, další dva jsou záplaty pro monitorování). O doporučené praxi budu mluvit příští měsíc během jedné z mých přednášek na PostgreSQL East a také jsem v této oblasti předložil něco na květnový PGCon. Zde také budu mluvit trochu více o slepých uličkách, dokud jsou tyto vzpomínky stále čerstvé.
Základní problém je v tom, že způsob, jakým PostgreSQL používá při zápisu mezipaměť operačního systému, umožňuje akumulaci velkého množství dat. Výsledkem po dokončení kontrolních bodů databáze mohou být dlouhé prodlevy při čekání na zápis těchto dat. Ukázalo se, že program pgbench, který je součástí PostgreSQL, je při vytváření tohoto problému opravdu dobrý, takže to jsem použil pro všechny testy. Hlavní otázky, na které jsem se rozhodl odpovědět, byly:
- Vykazuje změna ze starého souborového systému ext3 skutečně zlepšení výkonu databázových úloh? Minulý rok jsem psal něco o návratu XFS na Linux, což ukázalo pěkné zlepšení v jednoduchých benchmarcích. Ne vždy se to však projeví ve vylepšení databáze.
- Skutečně zlepšují poslední laditelné linuxové dirty_bytes a dirty_background_bytes latenci v nejhorších případech?
- Které ze zde navržených změn databáze pro zlepšení chování skutečně fungují?
Pokud si chcete prohlédnout nezpracovaná data, můžete vidět všechny výsledky testu. Co bylo změněno pro každou testovací sadu, je zdokumentováno, a pokud se podíváte na jednotlivý test, můžete vidět použité parametry databáze a některé další základní informace o OS. Tato webová stránka je to, co pochází z mého testovacího programu pgbench-tools, pokud byste si něco takového chtěli sami vyzkoušet.
Výsledky nebyly příliš překvapivé, ale byly zajímavé. Všechny testy zde byly provedeny se dvěma velikostmi databáze. Při menší velikosti databáze (měřítko=500, asi 8GB databáze, která se snadno vejde do 16GB RAM serveru), ext3 spravoval 690 transakcí/sekundu, zatímco při dvojnásobné velikosti (měřítko=1000, asi 16GB databáze) to bylo mnohem více vyhledávání vázáno a zvládlo pouze 349 TPS. XFS zvýšila tato dvě čísla na 1757 TPS a 417 TPS – zisk 255 % a 19 %. Ještě lepší je, že latence v nejhorším případě u jedné transakce klesla z rozsahu 34 až 56 sekund (!) na 2 až 5 sekund. I když ani 5 sekund není skvělé, jedná se o syntetickou zátěž navrženou tak, aby byl tento problém opravdu špatný. Čísla ext3 jsou tak hrozná, že je stále pravděpodobné, že zde narazíte na nepříjemný problém, i když jsem ve skutečnosti viděl lepší chování na tomto souborovém systému, než jsem viděl v dřívějších jádrech (to bylo provedeno s 2.6.32).
1. kolo: XFS drtivě vítězí. Nemohu doporučit ext3 jako životaschopný souborový systém na linuxových systémech se spoustou paměti, pokud plánujete hodně zapisovat; v tomto kontextu to prostě nefunguje. Tento server měl pouze 16 GB RAM, takže si dokážete představit, jak špatný je tento problém na vážném produkčním serveru zde v roce 2011.
Další na řadě jsou laditelné dirty_bytes a dirty_background_bytes. Tyto dva docela zlepšily latenci na ext3, na úkor některých zpomalení. Nejhorší z nich, zpomalená doba údržby běžící na VACUUM, nevidíte v samotných výsledcích testu; Už jsem o tom mluvil ve svém dřívějším příspěvku na blogu. Na XFS je vyladění těchto parametrů výkonovou katastrofou. V menším měřítku databáze poklesne výkon TPS o 46 % a navíc se skutečně zhorší latence.
2. kolo: Od dirty_bytes nebo dirty_background_bytes nečekejte žádné zázraky. Zdá se, že za určitých okolností mají určitý pozitivní účinek, ale potenciální nevýhoda je také velká. Ujistěte se, že pečlivě testujete a zahrňte do testování VAKUUM, než tyto dva upravíte směrem dolů.
Jako další jsem v rámci tohoto posledního CommitFestu vyhodnotil tři nápady na opravy PostgreSQL:
- Rozšiřte volání synchronizace kontrolního bodu na disk (fsync) v průběhu času. Zaznamenali jsme určitý úspěch na zaneprázdněném klientském serveru v kombinaci s lepším zpracováním toho, jak byly ostatní operace synchronizace ukládány do mezipaměti databáze
- Kompaktní požadavky fsync. Tento nápad se oddělil od prvního a přeměnil se v patch napsaný Robertem Haasem. Myšlenka je taková, že klienti pokoušející se synchronizovat data na disk by mohli soutěžit se zápisem kontrolních bodů. Oprava umožňuje klientům vyčistit frontu požadavků fsync, pokud někdy zjistí, že je plná.
- Řadit zápisy kontrolního bodu. Koncept spočívá v tom, že pokud zapisujete věci v pořadí, v jakém databáze věří, že jsou věci uloženy na disku, operační systém může zapisovat efektivněji. Tato oprava se objevila před několika lety s některými výsledky benchmarků, které naznačovaly, že fungovala, ale v té době nebyl nikdo schopen replikovat vylepšení. Myšlenka zapadla do zbytku práce natolik dobře, že jsem ji znovu zhodnotil.
3. kolo: Po týdnech zkoušení toho všeho byl jediným přístupem z této sady, který ukázal zlepšení téměř u všech velikostí zátěže, zhutnění fsync. Původní kód synchronizace kontrolního bodu šíření v této oblasti částečně pomohl, ale konkrétní implementace, která je nyní potvrzena pro 9.1, fungovala ještě lépe. Ve většině testů náročných na zápis, které jsem prováděl, to byl téměř celkový 10% zisk. To je skvělé vylepšení pro PostgreSQL 9.1 a mělo by to zcela eliminovat problém, který jsme viděli způsobit zde mnohem větší zpomalení produkčních systémů.
Zbytek nápadů zde nezískal tak pozitivní hodnocení po těžkém benchmarking, takže se prozatím vraťte na polici. Budu zde nadále shromažďovat data – další logickou věcí, kterou je třeba vyzkoušet, jsou některé testy ext4 – a pak se znovu vrátím k vývoji. Získat 10% zisk u některých obtížných úloh je jistě hezké, ale stále je zde příliš mnoho nejhorších případů chování na to, abychom považovali problémy se synchronizací kontrolních bodů za uzavřené téma.