Výkon PostgreSQL v závislosti na FS - vyřešeno

6.3.2010 08:59 | Přečteno: 2048× | poslední úprava: 6.3.2010 18:42

Při pokusu o změření výkonu PostgreSQL na různých konfiguracích raidu jsem nečekaně narazil na podivné chování PGSQL na různých FS.

Keci přijdou příště (až se mi podaří naměřit to pole), teď rychle k věci:

HW: Intel Core 2 Duo 6320, 8 GB RAM, SATA II disky (sda: ST3320620AS, sdd: SAMSUNG HD103SJ).
OS: CentOS 5.4 64b, kernel 2.6.18-164.6.1
SW: PostgreSQL 8.1.18, e2fsprogs 1.39, xfsprogs 2.9.4

Měření probíhalo programem pgbench

Výsledky (pro pgbench -c 1 -t 10000), počet transakcí za sekundu:

sda[ext3]: 334
sdd[ext3]: 602
sdd[xfs]:   35

Nastavení PostgreSQL jsem záměrně ponechal původní z balíčku.

Rozdíly mezi disky sda a sdd odpovídají rozdílu v HW. Na stejném disku je ext3 17x výkonnější než na xfs.

Prosím o komentáře, co je (případně na chyby v měření samotném) špatně. Lidé postgresql na xfs normálně používají a na fórech se hádají o jednotky procent výkonu, nikoliv o řád. Co se týče souborů, na daném serveru je xfs +/- stejně rychlý jako ext3 (prosím neflamujte na téma FS) a je nasazen kvůli velikosti pole. Pomůže novější PostgreSQL?

Update:

Vyřešeno. Na vině pomalé PGSQL DB bylo nastavení XFS, konkrétně barriér. Takže výsledky, počet transakcí za sekundu:

disk [xfs nobarrier]: 943
disk [xfs barrier]: 34
raid-5 [xfs nobarrier]: 67

Na mdadm a lvm bariéry nelze zapnout. Na samostatném disku je xfs při vypnutých bariérách řádově stejně rychlý jako ext3, při zapnutých rychlost db rapidně klesá.

       

Komentáře

[alblaho]

Příloha:

• 2.png (26437 bytů)

Postgres a Linux je vůbec docela divočina:

http://www.phoronix.com/scan.php?page=article&item=linux_2624_2633&num=2

Jaké jádro máš ty?

[Heron]

Píšu to v zápisku, 2.6.18 (distribuční v CentOS).

Docela divočina . Odpoledne zkusím nasadit novější stabilní PG a zopakuju měření. Nechce se mi věřit, že má FS až takový vliv, tohle musí být nějaká chyba.

[trekker.dk]

Ten skok mezi 2.6.29 a 2.6.30 je vcelku jasný, tam se u ext3 změnilo výchozí nastavení z data=ordered na data=writeback a nárůst výkonu z toho plynoucí je tedy vcelku jasně vysvětlitelný

Spíš by mě zajímalo, kde udělali soudruzi chybu teď, že ve většině benchmarků (nejen v odkazovaném článku) je 2.6.33 naprostý propadák.

(Btw. malá oprava zápisku - kvůli se píše kvůli )

[VSi]

V souvislosti s tímhle: neví někdo, jestli už na 2.6.30 fungují ext3 barriers nad LVM a nad SW RAID (mdraid)? Četl jsem testy, kde se ext3 nad LVM po několika výpadcích napájení úplně rozpadl, a to při nastavení data=ordered. Doporučeným řešením je HW RAID + write chache se zálohovací baterií.

Projevovalo se to jen, když byla zapnutá drive write cache na SATA discích. To je obvykle jejich výchozí nastavení, a při vypnutí drive write cache dokonce výrobce negarantuje živostnost disku. Zajímavé je, že třeba HP ve svých serverech dodává SATA disky s vypnutou chache.

Myslel jsem si, že na klasický setup MD RAID1 + LVM + EXT3 se dá spolehnout i při výpadku napájení (rozbije se třeba otevřený soubor, ale FS bude v pořádku). Pokud je teď výchozí data=writeback, měl bych strach ze ztráty dat ještě větší.

Každopádně vypnutí cache na SATA disku způsobí obrovský propad výkonu - u mě asi na 1/4 při sekvenčním zápisu, při provozu právě Postgresu na disku s vypnutou cache vylezl IOWAIT až na 80% z jednoho jádra, po zapnutí cache je to tak 10%.

Nebylo při testování na tom disku LVM? Právě XFS nad LVM prý někdy vypínal diskovou write cache, protože hrozila ztráta dat.

[okbob]

Zapnutí write chache (bez baterie) může způsobit ztrátu dat - pro db, to může znamenat poškození db - takže pozor.

[VSi]

Možnost ztráty dat je jasná, možné poškození DB bych taky čekal.

Tady šlo o to, že se rozsype EXT3 tak, že ho nejde vůbec připojit - snad došlo dříve k zápisu žurnálu než vlastních dat, nebo tak něco + problém s tím, že EXT3 nekontroluje konzistenci žurnálu nějakým kontrolním součtem. Takovéhle chování bych právě nečekal.

[Semo]

Je to testovane na identickych cerstvo sformatovanych particiach? Ina je rychlost disku na zaciatku a na konci a nahanat fragmenty suboru po velkej starej particii nieco stoji.

[Heron]

Ano je. Ten disk sdd je prázdný, před testem jsem vytvořil ext3 (default i optimalizovanou - výsledky se moc neliší a nejsou pro tento test zajímavé) a taktéž xfs (opět žádná větší závislost na nastavení). Ta testovací DB tam byla vytvořena znovu (pgbench -i) a DB byla na celém disku sama.

Co se týče polohy na plotně, tím by se dal vysvětlit max dvojnásobný rozdíl ve výkonu. Viz disk sda. Je systémový, fs vytvořený před lety a výsledek je stále řádově srovnatelný s sdd (stovky transakcí).

Zkoušel jsem i DB na Raid5 (to byl cíl testováni - rozdíl DB na HDD a R5 a R1, R10 pak někdy v budoucnu), tam mám též xfs a počet transkakcí je opět jen okolo 30.

[Michal Kubeček]

Před časem jsem zápolil s XFS taky. Problém se projevoval tím, že v okamžiku vypnutí virtuálního stroje pod VMware Worstation se program "zasekl" na dobu trvající třeba i 40-50 sekund, během nichž intenzivně pracoval disk. Zjistil jsem, že příčinou je pomalost operace zapsání veškeré cache na disk (tj. to, co dělá příkaz sync). Problém se projevoval na několika různých počítačích, systém byl vždy 64-bitový a výraznější to bylo na víceprocesorových (nebo spíš vícejádrových). Částečně pomohlo (proti vší logice) mountování s parametrem nobarrier, tím se doba trvání snížila asi na polovinu. Nakonec jsem to vyřešil přechodem na JFS.

Netvrdím, že jste narazil na stejný problém, ale dokázal bych si představi, že by pomalost databáze ve specifických případech byla způsobována právě pomalostí synchronního zápisu. Ale jestli máte ještě ten volný disk, zkuste na něm i JFS, podle mne je tento filesystém v Linuxu opomíjen do značné míry neprávem.

[Heron]

Barrier je podle jádra vypnutý. Ale zkusím.

S JFS nemám mnoho zkušeností, ale pro tento test jej tam dám.

[Heron]

Vyhráváš panáka dle chuti. Je to bariérama . Viz update zápisku.

[okbob]

Novější verze PostgreSQL asi nepomůže. Jestli je propad výkonu způsobený pomalým fsyncem, tak je problém nikoliv v pg, ale v operačním systému.

Pro testování fs je lepší např. bonnie http://www.abclinuxu.cz/zpravicky/benchmark-souboroveho-systemu-s-bonnieplusplus

Pavel

[Heron]

Díky za odpověď. Já netestuji FS. Chtěl jsem porovnat výkon DB na různých levelech RAIDu (1,5,10) a narazil jsem na tento problém. Na R5 mám právě XFS, proto jsem ho nasadil i na samostatný disk pro porovnání.

[okbob]

No R5 je pro databáze dost nevhodný - minimálně pro transakční log. Pokud je db trochu více zatížena - doporučuje se umístit transakční log na jiný hd. Zápis do transakčního logu bývá obvykle tou největší brzdou.

[Heron]

JJ, tohle vím, ale kolega toto neví a nevěří mi, proto ten test . Na druhou stranu, možná bude stačit mu poslat odkaz na tuto diskusi.

[linker]

Zajimalo by me, zda by nebyl Postgres vykonnejsi vyrazenim vrstvy filesystemu? Pracoval by primo s danym blokovym zarizenim, napr. sda.

[Michal Kubeček]

To téměř jistě ano, otázka ale zní o kolik.

[pepa z depa]

O kolik?

[Michal Kubeček]

Kdybych to věděl, tak bych to napsal. :-) Navíc stejně nejspíš nebude existovat nějaké univerzální číslo platné pro všechny případy.

[flaxa]

myslim, ze se o tom pise v kazde knizce o databazich, jak je to vyhodne, ze databaze implementuje v sobe same ty same funkce, jake ma i filesystem ( ), ovsem v novejsi dobe (tak od roku 2005) stoji psano, ze to nema smysl, ze filesystemy jsou uz tak mazane a pameti je tolik, ze to nic neprinese.

[okbob]

Vyjma určitých patologických případů, kdy něco nefunguje (jako je zmiňovaný problém s XFX) by přínos byl minimální - něco kolem nuly - limitem je rychlost čtení z disku, a rychlost zápisu.

[trekker.dk]

Na mdadm a lvm bariéry nelze zapnout.

U 2.6.33 na mdadm už jo. http://kernelnewbies.org/LinuxChanges#head-713e14251e05151b9d48bf91c344ca4ff07c526a

[Petr Chmelař]

Je to opravdu velký rozdíl používat XFS a EXT4 na RAIDu ... přesně nevím kolik to dělalo s uvedenou konfigurací na XFS, ale bylo to znatelně pomalejší (několikrát).

tps = 1655.252597 (excluding connections establishing)