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í
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 11:30 | Komunita

Bylo oznámeno, že bude proveden bezpečnostní audit zdrojových kódů open source softwaru pro implementaci virtuálních privátních sítí OpenVPN. Audit provede Matthew D. Green (blog), uznávaný kryptolog a profesor na Univerzitě Johnse Hopkinse. Auditována bude verze 2.4 (aktuálně RC 1, stabilní verze je 2.3.14). Audit bude financován společností Private Internet Access [reddit].

Ladislav Hagara | Komentářů: 0
dnes 06:00 | Komunita

Na YouTube byl publikován Blender Institute Reel 2016, ani ne dvouminutový sestřih z filmů, které vznikly za posledních 10 let díky Blender Institutu. V institutu aktuálně pracují na novém filmu Agent 327. Dění kolem filmu lze sledovat na Blender Cloudu. Videoukázka Agenta 327 z června letošního roku na YouTube.

Ladislav Hagara | Komentářů: 0
dnes 01:02 | Zajímavý článek

Minulý týden byly vydány verze 1.2.3 a 1.1.7 webového poštovního klienta Roundcube. V oznámení o vydání bylo zmíněno řešení bezpečnostního problému nalezeného společností RIPS a souvisejícího s voláním funkce mail() v PHP. Tento týden byly zveřejněny podrobnosti. Útočník mohl pomocí speciálně připraveného emailu spustit na serveru libovolný příkaz. Stejně, jak je popsáno v článku Exploit PHP’s mail() to get remote code execution z roku 2014.

Ladislav Hagara | Komentářů: 0
včera 16:00 | Nová verze

Byla vydána verze 0.98 svobodného nelineárního video editoru Pitivi. Z novinek lze zmínit například přizpůsobitelné klávesové zkratky. Videoukázka práce s nejnovější verzí Pitivi na YouTube.

Ladislav Hagara | Komentářů: 1
včera 15:00 | Zajímavý software

Stop motion je technika animace, při níž je reálný objekt mezi jednotlivými snímky ručně upravován a posouván o malé úseky, tak aby po spojení vyvolala animace dojem spojitosti. Jaký software lze pro stop motion použít na Linuxu? Článek na OMG! Ubuntu! představuje Heron Animation. Ten bohužel podporuje pouze webové kamery. Podpora digitálních zrcadlovek je začleněna například v programu qStopMotion.

Ladislav Hagara | Komentářů: 3
7.12. 21:21 | Nová verze Ladislav Hagara | Komentářů: 0
7.12. 11:44 | Zajímavý projekt

Na Indiegogo byla spuštěna kampaň na podporu herní mini konzole a multimediálního centra RetroEngine Sigma od Doyodo. Předobjednat ji lze již od 49 dolarů. Požadovaná částka 20 000 dolarů byla překonána již 6 krát. Majitelé mini konzole si budou moci zahrát hry pro Atari VCS 2600, Sega Genesis nebo NES. Předinstalováno bude multimediální centrum Kodi.

Ladislav Hagara | Komentářů: 2
7.12. 00:10 | Nová verze

Byla vydána verze 4.7 redakčního systému WordPress. Kódové označením Vaughan bylo vybráno na počest americké jazzové zpěvačky Sarah "Sassy" Vaughan. Z novinek lze zmínit například novou výchozí šablonu Twenty Seventeen, náhledy pdf souborů nebo WordPress REST API.

Ladislav Hagara | Komentářů: 10
6.12. 12:00 | Zajímavý projekt

Projekt Termbox umožňuje vyzkoušet si linuxové distribuce Ubuntu, Debian, Fedora, CentOS a Arch Linux ve webovém prohlížeči. Řešení je postaveno na projektu HyperContainer. Podrobnosti v často kladených dotazech (FAQ). Zdrojové kódy jsou k dispozici na GitHubu [reddit].

Ladislav Hagara | Komentářů: 27
6.12. 11:00 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2016-8655 v Linuxu zneužitelné k lokální eskalaci práv. Chyba se dostala do linuxového jádra v srpnu 2011. V upstreamu byla opravena minulý týden [Hacker News].

Ladislav Hagara | Komentářů: 2
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (8%)
 (5%)
 (3%)
Celkem 799 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: SW raid a databáze

Zdeněk Zámečník avatar 21.9.2010 15:22 Zdeněk Zámečník | skóre: 26
SW raid a databáze
Přečteno: 915×

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...


Řešení dotazu:


Odpovědi

21.9.2010 16:37 Sten
Rozbalit Rozbalit vše Re: SW raid a databáze
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 avatar 21.9.2010 17:15 Zdeněk Zámečník | skóre: 26
Rozbalit Rozbalit vše Re: SW raid a databáze

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 avatar 21.9.2010 16:52 frEon | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: SW raid a databáze
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.
Talking about music is like dancing to architecture.
Zdeněk Zámečník avatar 21.9.2010 17:21 Zdeněk Zámečník | skóre: 26
Rozbalit Rozbalit vše Re: SW raid a databáze
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 avatar 21.9.2010 17:49 frEon | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: SW raid a databáze
to bohuzel nemam.
Talking about music is like dancing to architecture.
Heron avatar 21.9.2010 18:53 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: SW raid a databáze

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 avatar 21.9.2010 22:12 Zdeněk Zámečník | skóre: 26
Rozbalit Rozbalit vše Re: SW raid a databáze

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 avatar 22.9.2010 09:42 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: SW raid a databáze
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 avatar 22.9.2010 15:33 frEon | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: SW raid a databáze
neni, vcera vysel
Talking about music is like dancing to architecture.
Heron avatar 22.9.2010 15:48 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: SW raid a databáze
Ovšem je otázkou zda je připraven pro produkční nasazení.
frEon avatar 22.9.2010 16:26 frEon | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: SW raid a databáze
jo, ja prave nevedel jak jsi to myslel....
Talking about music is like dancing to architecture.
poky74 avatar 22.9.2010 15:37 poky74 | skóre: 36 | blog: Zápisník | Vrchlabí
Rozbalit Rozbalit vše Re: SW raid a databáze

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

Chcete Linuxové samolepky nebo Tuxe na klíče? ->
Heron avatar 22.9.2010 15:47 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: SW raid a databáze
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 avatar 22.9.2010 17:23 Zdeněk Zámečník | skóre: 26
Rozbalit Rozbalit vše Re: SW raid a databáze
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 avatar 22.9.2010 17:34 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: SW raid a databáze
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 avatar 22.9.2010 17:47 Zdeněk Zámečník | skóre: 26
Rozbalit Rozbalit vše Re: SW raid a databáze
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 avatar 22.9.2010 21:57 Zdeněk Zámečník | skóre: 26
Rozbalit Rozbalit vše Re: SW raid a databáze
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 avatar 23.9.2010 08:25 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: SW raid a databáze
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 avatar 23.9.2010 11:37 Zdeněk Zámečník | skóre: 26
Rozbalit Rozbalit vše Re: SW raid a databáze
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 avatar 24.9.2010 10:26 Zdeněk Zámečník | skóre: 26
Rozbalit Rozbalit vše Re: SW raid a databáze
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 avatar 24.9.2010 11:16 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: SW raid a databáze
:-( 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 avatar 24.9.2010 18:49 Zdeněk Zámečník | skóre: 26
Rozbalit Rozbalit vše Re: SW raid a databáze
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 avatar 24.9.2010 23:20 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: SW raid a databáze
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 avatar 25.9.2010 11:59 Zdeněk Zámečník | skóre: 26
Rozbalit Rozbalit vše Re: SW raid a databáze
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.
22.9.2010 08:05 Radim Kolář | skóre: 11
Rozbalit Rozbalit vše Re: SW raid a databáze
mate u toho sw raidu nastavenou spatnou velikost bloku. Dulezite je dat log soubory na samostatny raid10 svazek a data pak zvlast.
Heron avatar 22.9.2010 09:37 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: SW raid a databáze
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?
22.9.2010 16:18 Radim Kolář | skóre: 11
Rozbalit Rozbalit vše Re: SW raid a databáze
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 avatar 22.9.2010 18:37 Zdeněk Zámečník | skóre: 26
Rozbalit Rozbalit vše Re: SW raid a databáze
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 avatar 23.9.2010 18:25 Zdeněk Zámečník | skóre: 26
Rozbalit Rozbalit vše Re: SW raid a databáze
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 avatar 23.9.2010 18:53 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: SW raid a databáze

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 avatar 25.9.2010 18:51 Zdeněk Zámečník | skóre: 26
Rozbalit Rozbalit vše Re: SW raid a databáze
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.

Založit nové vláknoNahoru

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

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