abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 18:22 | IT novinky

    V uplynulých dnech byla v depu Českých drah v Brně-Maloměřicích úspěšně dokončena zástavba speciální antény satelitního internetu Starlink od společnosti SpaceX do jednotky InterPanter 660 004 Českých drah. Zástavbu provedla Škoda Group. Cestující se s InterPanterem, vybaveným vysokorychlostním satelitním internetem, setkají například na linkách Svitava Brno – Česká Třebová – Praha nebo Moravan Brno – Břeclav – Přerov – Olomouc.

    Ladislav Hagara | Komentářů: 0
    včera 13:11 | Nová verze

    Byla vydána nová verze 8.7.0 správce sbírky fotografií digiKam (Wikipedie). Přehled novinek i s náhledy v oficiálním oznámení (NEWS). Nejnovější digiKam je ke stažení také jako balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo ke spuštění a spustit.

    Ladislav Hagara | Komentářů: 0
    včera 12:22 | IT novinky

    Před 30 lety, k 1. 7. 1995, byl v ČR liberalizován Internet - tehdejší Eurotel přišel o svou exkluzivitu a mohli začít vznikat první komerční poskytovatelé přístupu k Internetu [𝕏].

    Ladislav Hagara | Komentářů: 4
    včera 11:33 | Nová verze

    Byla vydána (𝕏) nová verze 7.4 open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.

    Ladislav Hagara | Komentářů: 0
    včera 05:44 | Bezpečnostní upozornění

    Balíček s příkazem sudo byl vydán ve verzi 1.9.17p1. Řešeny jsou zranitelnosti CVE-2025-32462 (lokální eskalace práv prostřednictvím volby host) a CVE-2025-32463 (lokální eskalace práv prostřednictvím volby chroot).

    Ladislav Hagara | Komentářů: 6
    včera 05:22 | IT novinky

    Do služeb Seznam.cz se lze nově přihlásit pomocí služby MojeID [𝕏].

    Ladislav Hagara | Komentářů: 1
    včera 03:33 | Bezpečnostní upozornění

    Bezpečnostní výzkumníci zveřejnili informace o osmi zranitelnostech, které postihují více než 700 modelů tiskáren, skenerů a štítkovačů značky Brother. Bezpečnostní upozornění vydali také další výrobci jako Fujifilm, Ricoh, Konica Minolta a Toshiba. Nejzávažnější zranitelnost CVE-2024-51978 umožňuje útočníkovi vzdáleně a bez přihlášení získat administrátorská oprávnění prostřednictvím výchozího hesla, které lze odvodit ze

    … více »
    Ladislav Hagara | Komentářů: 0
    30.6. 16:00 | Komunita

    Společnost Oracle vlastní ochrannou známku JAVASCRIPT. Komunita kolem programovacího jazyka JavaScript zastoupena společností Deno Land vede právní bitvu za její osvobození, viz petice a otevřený dopis na javascript.tm. Do 7. srpna se k nim má vyjádřit Oracle (USPTO TTAB).

    Ladislav Hagara | Komentářů: 6
    30.6. 13:11 | IT novinky

    Byl představen samostatný rádiový modul Raspberry Pi Radio Module 2 s Wi-Fi a Bluetooth.

    Ladislav Hagara | Komentářů: 6
    30.6. 12:44 | Upozornění

    Certifikační autorita Let’s Encrypt ukončila k 4. červnu zasílání e-mailových oznámení o vypršení platnosti certifikátů. Pokud e-maily potřebujete, Let’s Encrypt doporučuje některou z monitorovacích služeb.

    Ladislav Hagara | Komentářů: 0
    Jaký je váš oblíbený skriptovací jazyk?
     (59%)
     (28%)
     (7%)
     (2%)
     (0%)
     (1%)
     (3%)
    Celkem 336 hlasů
     Komentářů: 16, poslední 8.6. 21:05
    Rozcestník

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

    6.3.2010 08:59 | Přečteno: 1635× | 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á.

           

    Hodnocení: 80 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    alblaho avatar 6.3.2010 10:14 alblaho | skóre: 17 | blog: alblog
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    Příloha:
    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 avatar 6.3.2010 10:27 Heron | skóre: 53 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    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.
    6.3.2010 12:59 trekker.dk | skóre: 72
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    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 ;-))
    Quando omni flunkus moritati
    6.3.2010 13:46 VSi | skóre: 28
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    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 avatar 6.3.2010 15:08 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    Zapnutí write chache (bez baterie) může způsobit ztrátu dat - pro db, to může znamenat poškození db - takže pozor.
    6.3.2010 15:27 VSi | skóre: 28
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    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.
    6.3.2010 11:50 Semo | skóre: 45 | blog: Semo
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    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.
    If you hold a Unix shell up to your ear, you can you hear the C.
    Heron avatar 6.3.2010 12:03 Heron | skóre: 53 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    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.
    6.3.2010 13:02 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS

    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 avatar 6.3.2010 15:08 Heron | skóre: 53 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    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 avatar 6.3.2010 18:31 Heron | skóre: 53 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    Vyhráváš panáka dle chuti. Je to bariérama :-). Viz update zápisku.
    okbob avatar 6.3.2010 13:25 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    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 avatar 6.3.2010 14:59 Heron | skóre: 53 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    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 avatar 6.3.2010 15:12 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    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 avatar 6.3.2010 15:32 Heron | skóre: 53 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    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.
    6.3.2010 13:33 linker
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    Zajimalo by me, zda by nebyl Postgres vykonnejsi vyrazenim vrstvy filesystemu? Pracoval by primo s danym blokovym zarizenim, napr. sda.
    6.3.2010 13:48 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    To téměř jistě ano, otázka ale zní o kolik.
    6.3.2010 14:08 pepa z depa
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    O kolik?
    6.3.2010 14:20 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    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.
    6.3.2010 14:19 flaxa
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    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 avatar 6.3.2010 15:24 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS
    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.
    6.3.2010 19:40 trekker.dk | skóre: 72
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS - vyřešeno
    Na mdadm a lvm bariéry nelze zapnout.
    U 2.6.33 na mdadm už jo. http://kernelnewbies.org/LinuxChanges#head-713e14251e05151b9d48bf91c344ca4ff07c526a
    Quando omni flunkus moritati
    7.3.2010 17:06 Petr Chmelař
    Rozbalit Rozbalit vše Re: Výkon PostgreSQL v závislosti na FS - vyřešeno
    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)

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.