Dotaz: SW raid a databáze

[Zdeněk Zámečník]

Našel by se tu někdo, kdo provozuje linuxový raid a na něm mu běží MySQL nebo PostgreSQL? Až do nedávna jsme na serverech používali výhradně hw raidy. Nicméně v honbě za výkonem a nižšími náklady jsem vyzkoušel na několika strojích sw raid (zejména RAID100 a RAID10), ale narazil jsem na problémy....

Při větším počtu insertů/transakcí v PostgreSQL jde výkon naprosto do kytek. Zde uvádím, co se mi podařilo naměřit nástrojem pgbench s defaultními parametry:

HW RAID1 (2x SATA 7k2, seq write 113MB/s, ext4)
466/560tps [473/571]

HW RAID0 (4x SAS 15k, seq write 320MB/s, ext4)
498/595tps [530/671]

SW RAID1 (4x SATA 7k2, seq write 146MB/s, ext3)
14/14tps [597/712]

SW RAID100 (8x SATA 7k2, seq write 580MB/s, ext4)
21/21tps [1022/1291]

Hodnoty v hranatých závorkách jsou naměřené při nastaveném

fsync=off

v konfiguraci Postgre.

Moje teorie je taková, že v případě sw RAIDu při syncu kernel čeká až se data skutečně na disk zapíší. U hw RAIDu dojde u menšího objemu dat pouze k zapsání do cache řadiče, ale pro kernel už se data tváří jako zapsaná. Zde se musí jasně projevit, že disky těch několik set I/O za sekundu opravdu nedají.

Ovšem pokud fsync vypnutý stejně v některých případech nedosáhnu takového výkonu jako na hw raidu - např. obnova SQL dumpu trvá na hw raidu 7minut, na sw stále okolo 8 hodin i s vypnutým fsyncem!

Tentýž problém u MySQL - tam jsou inserty do db cca 4x pomalejší oproti hw raidu. V případě InnoDB tabulek je to absolutně nepoužitelné. To jsem zatím vyřešil konfiguračním parametrem

innodb_flush_log_at_trx_commit = 2

Myslíte, že existuje nějaká možnost, jak to vyladit? Velice nerad bych dodatečně nakupoval řadiče za desítky tisíc (resp. mi to nikdo nezaplatí), které mi stejně RAID100 pravděpodobně nenabídnou a to nemluvím o problémech spojených s výměnou za jiný, pokud umře.

Jsem si vědom toho, že vypnutím nuceného zápisu na disk můžu při výpadku přijít o některá data, což mám částečně ošetřeno UPS, ale zároveň věřím tomu, že i tak to ty databáze dokáží rozdejchat. V krajním případě existují zálohy...

---

---

Odpovědi

[Sten]

Ano, kernel skutečně čeká na zápis, protože cache disků není jištěna baterkou, a tak na ní nemůže spoléhat při výpadku proudu. To samé platí i pro žurnál, který u výchozího nastavení (ordered) na disky čeká, než provede commit. Pokud máte stroj jištěný UPSkou, můžete žurnál vypnout nebo alespoň přenastavit do writeback módu

Je to SATA nebo SATAⅡ? SATA (ta první) neumí (na rozdíl od SAS či některých HW RAIDů) transaction reordering a to u náhodného přístupu může hodně zdržovat

Neliší se velikost RAM těch strojů? Každý GiB může hodně ovlivnit výkon

[Zdeněk Zámečník]

To jsem netušil, že jde změnit i čekání na commit. Chápu to dobře, že pokud db zavolá sync, tak se provede commit na filesystému? Žurnál bych raději nevypínal, takovou odvahu zase nemám. Díky za podnět, schválně to vyzkouším.

Jedná se o SATAII.

Velikost RAM těch strojí se líší - ten s hw RAIDem má 8GB DDR2 ECC. Ten se sw má 24GB DDR3 ECC.

Jsem si prakticky jist, že je to způsobeno tím, že db volá po každé transakci sync a když jich udělá za vteřinu třeba 100, tak by ten disk musel prakticky 100x seekovat (v reálu to možná bude méně, netuším jak se ty zápisy plánují).

[frEon]

Zkus jinej io planovac (netvrdim vsak, ze se vykonu hw raidu tim priblizis). Na db obecne se mi osvedcuje deadline. Deadline ma i spoustu kroutitek, mozna ze najdes nejake kompromisni reseni, ktere bude dostatecne pro realne nasazeni.

[Zdeněk Zámečník]

Nemáš nějak změřen rozdíl v rychlosti těch plánovačů? Docela mě mrzí, že mám poskládané pekelně rychlé pole, ale prakticky kvůli potlačování cache je to nepoužitelné zejména pro db. Já používám CFQ a moc se mi nechce použít jiný, protože bych se připravil o možnost nastavování IO priorit v OpenVZ....

[frEon]

to bohuzel nemam.

[Heron]

Mám. Měření diskového výkonu v závislosti na nastavení kernel scheduleru

Možná tě bude zajímat i tento článek, zde ale záhadně propadl ext4 a zatím jsem to neměl čas řešit.

[Zdeněk Zámečník]

Moc díky! Koukám, na tom tvém webu jsou vůbec samé zajímavé postřehy, ještě teď ho celý pečlivě pročítám.

Změna scheduleru pro mě tedy nemá příliš velký přínos, i přesto mi to nedalo a naivně jsem si myslel, že těm diskům v sw raidu postupně změním scheduler, abych to jen vyzkoušel...kernel panic. Já vím, moje blbost. Změnu nastavení žurnálu si už radši vyzkouším na nějakém nedůležitém stroji :D

[Heron]

Koukám, na tom tvém webu jsou vůbec samé zajímavé postřehy, ještě teď ho celý pečlivě pročítám

Díky, mám v TODO ještě pořádný test PostgreSQL 9 (snad to není předčasné) pro různé nastavení OS/FS/SW Raidu. Chystám se mu svěřit poměrně mnoho dat a vysoký výkon je pro mě hned po bezpečnosti dat klíčový. Jenže času je málo .

a naivně jsem si myslel, že těm diskům v sw raidu postupně změním scheduler, abych to jen vyzkoušel...kernel panic. Já vím, moje blbost.

Uff, tohle se mi nikdy nestalo a to jsem si s elevátory hrál poměrně hodně.

[frEon]

neni, vcera vysel

[Heron]

Ovšem je otázkou zda je připraven pro produkční nasazení.

[frEon]

jo, ja prave nevedel jak jsi to myslel....

[poky74]

A můžeš mi osvětlit důvod tak špatného výsledku RaiserFs v jednom z těch testů?

[Heron]

Mno, a co teď s tím reiserfs? 16% výkonu je tristní výsledek. Google mlčí. Možná by pomohla změna velikosti bloků na 8kB a vypnout tail. Skutečně netuším.

Google nenašel mnoho uživatelů Postgresu a zároveň Reiseru tak se nemám od čeho odpíchout. Reiser nepoužívám, možná by pomohlo vypnutí tail (to by ale na výkon DB serveru nemělo mít vliv, jelikož ten primárně mění obsah souborů a na konec příliš nepřidává (a když už tak po větších blocích).

[Zdeněk Zámečník]

Začínám podezřívat fs, ještě stále s tím experimentuji, ale uvedu momentálně získané hodnoty. Zapisuji do MySQL 10 tis. záznamů (cca 1MB) do tabulky typu InnoDB. Testy jsem prováděl na ext3 a ext4 s defaultním nastavením v CentOS 5.5. Výsledky jsou dost zarážející:

**************************************************
*RAID                         * ext3      * ext4 *
**************************************************
SW 10  (chunksize 256kB)        18s       2,56min
SW 100 (chunksize 64kB/1MB)     11s        +10min
HW 1   (chunksize 64kB)          3s       1,29min

[Heron]

Hmm, to vypadá, že ten backportovaný ext4 (technology preview) je nějaký divný.

Zkus mu ještě nastavit writeback.

[Zdeněk Zámečník]

Writeback do něj nemůžu za boha dostat, resp. přes tune4fs jej zapnu, ale jakmile jej nastavím v fstabu, tak partition nenamountuju. Narazil jsem na RedHatí diskuzi, kde někdo řešil problém se sync trvajícím přes sedm minut na ext4 s kernelem 2.6.18. Pokud dotyčný zapnul (pro mě záhadným způsobem) writeback, dočkal se tracu nějaké chyby v kernelu. Reakce vypadala takto:

Hmm.. It is hard to predict differences between vanilla tree. This is no only ext4 related. writeback path is changed dramatically. It is not easy to port writeback code to 2.6.18 with full performance improvements but without introducing new issues.

Takže se radši vrátím k ext3, naštěstí jsem nestihnul na mnoha místech na ext4 přejít. Rozhodně si ale zkusím ještě s tím žurnálem pohrát na ext3.

[Zdeněk Zámečník]

Tak jsem o něco pokročil. U obnovy dumpu PostgreSQL už se mi povedlo dosáhnout mnohem lepších výsledků. Pgbench tolik optimistický není, ale i v něm jsem dosáhl cca 11x vyšší rychlosti (152/160tps) než na ext4. Raději připomínám, že jedu na CentOS 5.5 s kernelem 2.6.18, takže nějaký novější kernel bude velice pravděpodobně s rychlostí ext4 někde úplně jinde.

Tentokrát už jsem testoval jen na SW RAIDu 10 s EXT3 (opět 10 tis. insertů do InnoDB):

***********************************************************
* chunksize  * mount options                       * time *
***********************************************************
  256kB        data=ordered                          18s
  256kB        data=writeback                        18s
  64kB         data=writeback                        16s
  64kB         data=writeback,noatime,nodiratime     16s
  64kB         data=journal,noatime,nodiratime       9.5s

Pro zajímavost uvadím rychlost obnovy 214MB dumpu v PostgreSQL:

************************************************************************
* RAID        * fsync * fs * mount options                    * time   *
************************************************************************
  HW 1          on      ext4 defaults                           11m 36s
  HW 1          off     ext4 defaults                            7m 37s
  SW 100        on      ext4 defaults                           19h
  SW 100        off     ext4 defaults                            9h 40m
  SW 10         on      ext3 data=writeback,noatime,nodiratime  49m 17s
  SW 10         on      ext3 data=journal,noatime,nodiratime    26m 25s
  SW 10         off     ext3 data=journal,noatime,nodiratime    11m 43s

Dokázal by mi někdo vysvětlit, jak je možné, že s data=journal je to rychlejší? Čekal bych spíše opak... Kdyby měl někdo nápad, jak z toho vyždímat ještě více, tak sem s ním. Zítra mám ještě v plánu zkusit více velikostí chunk-size na RAIDu.

[Heron]

Především bych si vůbec nehrál s fsync. Na prvním místě by měla být bezpečnost těch dat.

Jinak skutečně zajímavé výsledky, obzvláště těch 19h . Nechceš to ještě otestovat na XFS?

[Zdeněk Zámečník]

Naprosto souhlasím, ale například u replikovaných databází, které jsou určeny jen pro dosažení vyšší rychlosti (load balancing) si to mohu dovolit. Teď mi tam běží testy různě velikých chunků (4k-8M), ale klidně pak můžu vyzkoušet XFS.

[Zdeněk Zámečník]

Tak jsem tam na noc pustil xfs a nevypadá to dobře, stihlo se tam otestovat pouze toto, pak jsem to radši už vypnul, protože je to pomalé. Nevím jestli je to opět jen nějaká nectnost 2.6.18....

Formátoval a mountoval jsem takto:

mkfs.xfs -l size=128m,version=2 /dev/md1 -f
mount /dev/md1 /mnt/data -o rw,noatime,nodiratime,nobarrier,biosize=16,logbufs=8,logbsize=256k

Chunksize     mysql-inserts  pgrestore   pgbench
64k           1m 10s         188m 16s    126/130
128k          1m 15s         201m 51s    107/110
256k                                     96/98

[Heron]

To je teda na výrazně výkonnějším systému než mám já cca 5x horší výsledek (v pgbenchi).

[Zdeněk Zámečník]

Jj, čím dál tím víc začínám litovat, že jsem cca před rokem přešel z Debianu na CentOS. Dneska jsem narazil na další kernel panic a to když jsem za běhu přidal disk. Všude jinde mi hotplug běhá v pořádku... To už je třetí bug, na který jsem tu během tohoto týdne narazil.

Schválně vyzkouším rychlost db i v Debianu na tom samém stroji...už teď mám tušení, že kromě ext3 na tom budou ostatní fs lépe.

[Heron]

Mno a nebude to něčím jiným? Třeba vadným HW? Na CentOSu jsme panic ještě neviděli natož pak při tak běžných činnostech jako je výměna disku za běhu a změna scheduleru.

[Zdeněk Zámečník]

Netvrdím, že to není možné, ale na druhou stranu je to nový HW. Možná by to mohl dělat ten SATA řadič od Adaptecu, ale těžko říct. Vyzkouším tyhle úkony na stejném stroji v Debianu s novějším kernelem a uvidíme.

[Radim Kolář]

mate u toho sw raidu nastavenou spatnou velikost bloku. Dulezite je dat log soubory na samostatny raid10 svazek a data pak zvlast.

[Heron]

Jaká by měla být správná velikost bloku pro Raid0, 10 a PostgreSQL? 8kB jako velikost stránky? Nebo se to počítá pro 10 jinak?

[Radim Kolář]

Pro raid0 na logy by mela idealni byt polovina prumerne transakce ale ne delsi nez 64kb. pgsql ma pocitadlo transakci, takze si zjistete kolik log souboru se vytvorilo za den a kolik transakci a podelte to.

pro raid0 na data tam je potrebe vedet co je to za workload. OLAP ma rad vetsi bloky, OLTP mensi.

Jinak pokud mate hodne/vetsinu kratkych zapisujicich transakci tak DB2 je cca 5x rychlejsi nez pgsql8.1 nedavno jsem testoval tpc-b. Pokud je ta aplikace v Jave/hibernate, tak jen vymenite jdbc driver.

[Zdeněk Zámečník]

Zkoušel jsem na RAID10 porovnat výkon při 64kB a 256kB blocích a nezaznamenal jsem žádný rozdíl... Zkusím ještě menší bloky, ale moc šancí tomu nedávám. Vypadá to, že na to má největší dopad samotný filesystém (viz. výše).

[Zdeněk Zámečník]

Bohužel v mém prostředí nemůžu dát transakční logy umístit na jiný disk/pole kvůli jednotnému způsobu správy... (zkrátka by to v našich podmínkách přineslo více škody než užitku). Nicméně zkoušel jsem na SW RAID 10 experimentovat s velikostí bloků. Opět stejným způsobem jako výše - 10tis. insertů do innodb v mysql, restore postgresql z 214MB dumpu a pgbench. Filesystém je ext3 s mount options data=journal,noatime,nodiratime.

Výsledky vypadají následovně:

Chunksize     mysql-inserts  pgrestore   pgbench
4k            12s                        324/348tps
8k            12s            30m25s      298/325tps
16k           10s            28m32s      376/409tps
32k           11s            27m26s      375/410tps
64k           11s            26m22s      351/386tps
128k          9s             24m16s      325/348tps
256k          10s            23m49s      401/448tps
512k          11s            26m22s      227/353tps
1M            11s            27m39s      327/353tps
2M            10s            26m37s      382/416tps      
4M            10s            26m44s      346/376tps
8M            11s            26m47s      344/379tps

Čímž jsem došel k závěru, že v mém případě je nejvhodnější použít 256kB bloky, ale jak vidíte příliš velké rozdíly zde nejsou. Docela by mě zajímalo, jestli by mělo smysl udělat dvě RAID1 s nějakou velikostí bloků a nad tím RAID0 s jinou velikostí. Ale už nemám příliš síly to testovat.

[Heron]

Tož já ti do toho vnesu ještě další chaos

Docela by mě zajímalo, jestli by mělo smysl udělat dvě RAID1 s nějakou velikostí bloků a nad tím RAID0 s jinou velikostí.

Toto smysl nemá, protože u RAID10 v layoutu F2 je možnost číst ze všech disků současně (rychlost čtení 4x větší, lineárně s počtem disků). Jaký tam máš layout? I když pravda, tyto testy jsou skoro čistě zápisové. Jak TPC-B, tak load toho dumpu.

[Zdeněk Zámečník]

Tak první pokus na Debianu s kernelem 2.6.32, tentýž stroj se SW RAID10 (chunksize=256k) a EXT3 s mount options noatime,nodiratime,data=journal:

pgbench 557/633tps
mysql 10tis. insertů do InnoDB 5.4s

Přičemž na pozadí ještě probíhá synchronizace RAIDu.