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 21:55 | Komunita

Nadace pro svobodný software (FSF) oznámila aktualizaci seznamu prioritních oblastí (changelog), na které by se měli vývojáři a příznivci svobodného softwaru zaměřit. Jsou to například svobodný operační systém pro chytré telefony, hlasová a video komunikace nebo softwarový inteligentní osobní asistent.

Ladislav Hagara | Komentářů: 1
včera 16:44 | Nová verze

Byla vydána verze 2.0.0 knihovny pro vykreslování grafů v programovacím jazyce Python Matplotlib (Wikipedie, GitHub). Přehled novinek a galerie grafů na stránkách projektu.

Ladislav Hagara | Komentářů: 0
včera 15:33 | Komunita

V australském Hobartu probíhá tento týden konference linux.conf.au 2017. Na programu je celá řada zajímavých přednášek. Sledovat je lze online.

Ladislav Hagara | Komentářů: 0
včera 10:20 | Zajímavý článek

Pavel Tišnovský se v dvoudílném článku na MojeFedora.cz věnuje bitmapovým (rastrovým) grafickým editorům ve Fedoře. V prvním dílu se věnuje editorům MyPaint, MtPaint, Pinta, XPaint, Krita a GIMP. V pokračování pak editorům GNU Paint (gpaint), GrafX2, KolourPaint, KIconEdit a Tux Paint.

Ladislav Hagara | Komentářů: 1
16.1. 17:11 | Komunita

Byl proveden bezpečnostní audit svobodného IMAP a POP3 serveru Dovecot (Wikipedie). Audit byl zaplacen z programu Mozilla Secure Open Source a provedla jej společnost Cure53. Společnost Cure53 byla velice spokojena s kvalitou zdrojových kódu. V závěrečné zprávě (pdf) jsou zmíněny pouze 3 drobné a v upstreamu již opravené bezpečnostní chyby.

Ladislav Hagara | Komentářů: 0
16.1. 15:30 | IT novinky

Nadace Raspberry Pi představila na svém blogu Raspberry Pi Compute Module 3 (CM3 a CM3L), tj. zmenšené Raspberry Pi vhodné nejenom pro průmyslové využití. Jedná se o nástupce Raspberry Pi Compute Module (CM1) představeného v dubnu 2014. Nový CM3 vychází z Raspberry Pi 3 a má tedy dvakrát více paměti a desetkrát větší výkon než CM1. Verze CM3L (Lite) je dodávána bez 4 GB eMMC flash paměti. Uživatel si může připojit svou vlastní. Představena byla

… více »
Ladislav Hagara | Komentářů: 1
16.1. 01:23 | Nová verze

Oficiálně bylo oznámeno vydání verze 3.0 multiplatformního balíku svobodných kancelářských a grafických aplikací Calligra (Wikipedie). Větev 3 je postavena na KDE Frameworks 5 a Qt 5. Krita se osamostatnila. Z balíku byly dále odstraněny aplikace Author, Brainstorm, Flow a Stage. U Flow a Stage se předpokládá jejich návrat v některé z budoucích verzí Calligry.

Ladislav Hagara | Komentářů: 7
15.1. 15:25 | Nová verze

Bylo oznámeno vydání první RC (release candidate) verze instalátoru pro Debian 9 s kódovým názvem Stretch. Odloženo bylo sloučení /usr jako výchozí nastavení v debootstrap. Vydán byl také Debian 8.7, tj. sedmá opravná verze Debianu 8 s kódovým názvem Jessie.

Ladislav Hagara | Komentářů: 6
15.1. 13:37 | Zajímavý projekt

1. ledna byl představen projekt Liri (GitHub). Jedná se o spojení projektů Hawaii, Papyros a původního projektu Liri s cílem vyvíjet operační systém (linuxovou distribuci) a aplikace s moderním designem a funkcemi. Včera byl představen Fluid 0.9.0 a také Vibe 0.9.0. Jedná se o toolkit a knihovnu pro vývoj multiplatformních a responzivních aplikací podporující Material Design (Wikipedie) a volitelně také Microsoft Design Language (designový jazyk Microsoft) [reddit].

Ladislav Hagara | Komentářů: 8
14.1. 00:33 | Zajímavý software

Google na svém blogu věnovaném open source představil knihovnu pro komprimaci a dekomprimaci 3D grafiky s názvem Draco. Knihovna bude využívána například v aplikacích pro virtuální a rozšířenou realitu. Porovnání Draco s gzip na YouTube. Zdrojové kódy Draco jsou k dispozici na GitHubu pod licencí Apache 2.0.

Ladislav Hagara | Komentářů: 5
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (10%)
 (2%)
 (75%)
 (3%)
 (10%)
Celkem 304 hlasů
 Komentářů: 24, poslední včera 10:14
    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: 920×

    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.