Fórum Root.cz
Hlavní témata => Server => Téma založeno: Santa 02. 03. 2015, 10:34:39
-
Vo firme sme riesili potrebu zrychlit pristup k datam v databaze (MariaDB), kde sme narazili na bottle-neck pristupove doby a rychlosti citania diskov. Zvazovali sme najprv nasadenie SSD, no koli obave z ich nizsej zivotnosti padol vyber na RAMdisk.
Volba padla na brd modul. Uvodne testy ukazali, ze idem spravnym smerom:
Zapis:
------
santa@DB-server:~$ sudo dd if=/dev/zero of=/mnt/disk/aa bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 22.1489 s, 185 MB/s
santa@DB-server:~$ sudo dd if=/dev/zero of=/mnt/ramdisk/aa bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 6.75993 s, 606 MB/s
Citanie:
santa@DB-server:~$ sudo dd if=/mnt/disk/aa of=/dev/null bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 20.8874 s, 196 MB/s
santa@DB-server:~$ sudo dd if=/mnt/ramdisk/aa of=/dev/null bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 1.94548 s, 2.1 GB/s
Potreba rychleho citania dat a zaroven nutnost zabezpecit data proti vypadku ma doviedla ku kombinacii SW RAID 1 nad diskom a ramdiskom.
vytvoril som si prazdny image subor (52GB) a ten pripojil na loop5, a pre ramdisk som nastavil rovnaku velkost, 52GB. (server ma 64 GB RAM)
Nasledne som pomocou mdadm vytvoril RAID 1 zariadenie, formatol ho a pripojil.
mdadm -C /dev/md1 -n 2 -l 1 /dev/ram0 -W /dev/loop5
mkfs.ext4 /dev/md1
mount /dev/md1 /mnt/ramdisk
Vysledne casy boli viac ako uspokojive:
santa@DB-server:~# sudo dd if=/dev/zero of=/mnt/ramdisk/aa bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 15.3726 s, 266 MB/s
santa@DB-server:~# sudo dd if=/mnt/ramdisk/aa of=/dev/null bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 1.79785 s, 2.3 GB/s
Zostala uz len posledna vec, ako zabezpecit, aby po restarte servera doslo k spusteniu RAIDu a rekonstrukcii obsahu RAMdisku a revalidacii takehoto pola:
/sbin/losetup /dev/loop5 /srv/db_images/ramdisk.img
mdadm --assemble /dev/md1 /dev/loop5
mdadm --run /dev/md1
mdadm --manage /dev/md1 --add /dev/ram0
mount /dev/md1 /mnt/ramdisk
nasledne som na diskovej urovni pri vypnutom MariaDB presunul databazy, ktore som potreboval zrychlit do /mnt/ramdisk/ a vytvortil z /var/lib/mysql linky na ramdisk.
That's all...
Snad toto niekomu pomoze, ked bude potrebovat nieco podobne riesit. komplexne selekty nad takto vytvorenou databazou lietaju ako namydlene ;)
-
Tohle nepatří do fóra, ale spíš do blogu nebo rovnou do článku. Nechceš se ještě víc podrobně rozepsat a udělat z toho článek?
-
Povodne som to chcel dat do blogu ale pri registracii mi to pise ze z mojej lokality nie je mozne zalozit blog. Ako by som bol niekde na marse :D
PS: aj forum sa ma pyta na nejake veci ktore ako clovek zijuci mimo uzemia CR fakt musim googlit (druhe najvacsie mesto v Cesku je......Ve kterém měsíci proběhla sametová revoluce? ... (chvilku mi tvalo ze november je u vas listopad :D )
-
Jeste zbyva zabezpecit, aby nejaky vul nerestartoval stroj, kdyz je zrovna rozpadly RAID.
-
no tak to je tedy velmi slušná akce! tohdle by stálo opravdu na pěkně napsaný článek
-
Nechapu. Proc to pamet dostal RAM disk? Nebylo by lepsi mit velkou buffer-cache?
-
Hmm, neriesi 99% tvojich problemov memory table?
-
co se stane az to padne? data na hdd nebudou v sync s RAM, tudiz budes mit 1 poskozeny zdroj dat a 1 zadny zdroj dat. Nebo se pletu?
-
Nechci Vám kazit radost, ale každý normální DB stroj na zeměkouli umí využít velkou RAM pro selecty automaticky, respektive když se mu povolí příslušné velké množství paměti používat. Nepřekvapivě to MariaDB umí také, ovšem musí se to nastavit ručně.
-
lepsi by bylo udelat raid1 pres dva ruzny disky s write-mostly a jeden ramdisk; pak by nevadilo zdechnuti jednoho disku
nebo jeste pro sichr udelat pred restartem pocitace nebo periodicky cronem kopii ramdisku uplne nekam jinam, na to skripty jsou, treba namatkou http://www.observium.org/wiki/Persistent_RAM_disk_RRD_storage
tedy by ramdisk sel obnovit pri restartu pred rebuildem a nespolehalo by se jen na data na disku
-
Pokusim sa zhrnut odpovede do jedneho prispevku:
JardaP, OMG: kludne moze aj v tejto faze vypadnut masina, nakolko dochadza k rekonstrukcii RAM oddielu, ktory je tak ci tak prazdny pri boote. Preto sa /dev/rd1 inicializuje manualne tak, ze sa prida najprv disk, a nasledne ked rd1 bezi, prida sa ram oddiel, ktory sa automaticky naplni datami.
Ivan,Kolemjdoucí: ramdisk koli tomu, ze potrebujem aby len niektore schemy (databazy) boli priorizovane na citanie. buffering, ci globalne settingy su fajna vec, to boli uvodne optimalizacie. Nevies to vsak nastavit per table, ale len per engine. a ked mas tak ako my, auditovanu databazu (ked nastane update na zazname, automaticky do tzv. historickej tabulky sa pridava povodny zasnam - before update trigger) tak ramkou plytvas na X nepodstatnych veci, lebo DB engine nerozlisuje prioritu tabuliek, schem.
Astar: memory_table neriesi podstatny problem, perzistencia ukladanych dat. ak ti masina klakne, data z memory_table su ta-tam...
-
trubicoid2: mas pravdu, preto som nasledne este z NAS cez iSCSI pripojil remote volume ako dalsi disk do tohoto raisu, takze vo vysledku mas data v ramdisku, na lokalnom disku a nasledne este na geograficky oddelenom NASku (druha serverovna)
-
Pokusim sa zhrnut odpovede do jedneho prispevku:
JardaP, OMG: kludne moze aj v tejto faze vypadnut masina, nakolko dochadza k rekonstrukcii RAM oddielu, ktory je tak ci tak prazdny pri boote. Preto sa /dev/rd1 inicializuje manualne tak, ze sa prida najprv disk, a nasledne ked rd1 bezi, prida sa ram oddiel, ktory sa automaticky naplni datami.
zkusim se zeptat jeste jednou - mas stroj s raid1 (1disk, 1ram) do toho raid 1 jsi nakopiroval nejakou databazi. Pokud je ta databaze jenom pro cteni, zadny problem. Pokud ale udelas nejaky insert, tak ty data je potrebne zapsat do toho raid a tudiz i na disk ktery je v tom raid. Ted si predstav ze delas nekolik insertu a cast dat se jiz zapisuje na disk a dojde k resetu stroje... Tudiz to raid1 pole je z meho pohledu nefunkcni, v ram nic neni, na disku je neco zapsano neco ne...
Z toho co jsi napsal mi vychazi:
1. databaze je jenom pro cteni, tudiz je uplne jedno jestli stroj vypadne nebo ne, po startu se udela raid a nakopiruje se odnekud puvodni databaze
2. databaze neni pro cteni a tudiz pripadny vypadek nemas promysleny
-
OMG:
Databaza nie je len pre citanie. Zapis prebieha a v primare sa vykonava na disk, kedze ten je v poli oznaceny ako writemostly. Problem so stabilitou sa uplne vyriesi pridanim dalsieho disku, tak ako to naznacil trubicoid2.
btw: ak by v raid1 bol len jeden disk, a jede ramdisk, mohlo by dojst k tomu, ze su po tvrdom pade poskodene subory v /dev/loop5, v tom mas pravdu. preto som pridal dalsi disk, a teda RAID1 je nad 3 zariadeniami. primarne teda pri update table dochadza k zapisu na disky. preto je citanie rychle a zapis pomaly.... otestoval som to niekolkymi tvrdymi restartami masiny, odpojenim od siete (nedostupnost NAS) a funguje to. nevravim, ze neexistuje nejaky scenar, pri ktorom by tato zostava nedokazala havarovat, otazka je, za tie peniaze sa da postavit lepsie riesenie?
-
za tie peniaze sa da postavit lepsie riesenie?
nevidel jsem nikde kolik penez na to mas... resit performance databaze je na dlouhou diskusi, z koule to proste nikdo tady neumi...
reseni raid1 (disk+ram), pripadne (disk+ram+nas) je z principu pruserove i kdyz tve testy ukazuji ze ne.
-
rychlosti pekne jen co je pravda, ale dva ssd v raid 1 to budou mit podobne,
a co se tyka te zivotnosti ssd museli by jste do toho dene hrnout stovky gigabitu aby vam skolaboval v pristich 4 letech
ale je to pekny ze si se podelil o zkusenosti treba se to nekomu bude hodit
-
OMG
Dostal som v budgete nejake zvysne zelezo co bolo na sklade, 3 dni na najdenie vhodneho riesenia a ulohu vyriesit to tak aby nebolo potrebne nic dokupovat ;)
Mas pravdu, ze ladenie databazy je umenie hodne majstra a 90% z toho je to, ako navrhujes databazu a pises selecty, a 10% je zvysok.
zatial toto vypada stabilne i ked to krici ze NIEEEE, no uvidime co ukazu dlhodobejsie testy.
-
Karel:
mas nejake realne testy nad SSD v RAID1? myslim co sa tych rychlosti tyka. Hodilo by sa to na porovnanie
-
JardaP, OMG: kludne moze aj v tejto faze vypadnut masina, nakolko dochadza k rekonstrukcii RAM oddielu, ktory je tak ci tak prazdny pri boote. Preto sa /dev/rd1 inicializuje manualne tak, ze sa prida najprv disk, a nasledne ked rd1 bezi, prida sa ram oddiel, ktory sa automaticky naplni datami.
Co kdyz RAID lehne a posledni spravna kopie je v ramdisku? Pred kazdym restartem byste meli overit, v jakem stavu je RAID, jestli si muzete restart dovolit.
-
JardaP:
mate pravdu, ze pri restarte by sa to malo kontrolovat. doplnim do scriptu. Horsie sa handluju prave katastroficke pady (vypadok prudu na oboch napajacich vetvach atp....) Ako som uz spomenul, nie je to uplne idealne riesenie, ma svoje rizika...
-
Zeptám se možná úplně pitomě, ale jedna věc mi není jasná:
Dosáhl jsi toho, že rychlost zápisu pořád odpovídá rychlosti zápisu na disk. Plus to není úplně robustní (je to trochu nestandardní řešení, u kterýho si nikdy nemůžeš být moc jistý, jaké scénáře ho položí, otestovat všechny případy nejsi schopný).
Čím se tohle liší od toho, kdybys to vůbec neřešil "ručně" a prostě nasadil nějaký FS, který má solidně zvládnutou MFU cache (např. ZFS)? Čtení budeš mít z cache (nejčastěji čtené tabulky z MFU cache nic nevytlačí) a zápis na disk, takže rychlost stejná a robustnost vyšší.
Jaký je důvod, proč to tak neudělat?
-
Ivan,Kolemjdoucí: ramdisk koli tomu, ze potrebujem aby len niektore schemy (databazy) boli priorizovane na citanie. buffering, ci globalne settingy su fajna vec, to boli uvodne optimalizacie. Nevies to vsak nastavit per table, ale len per engine. a ked mas tak ako my, auditovanu databazu (ked nastane update na zazname, automaticky do tzv. historickej tabulky sa pridava povodny zasnam - before update trigger) tak ramkou plytvas na X nepodstatnych veci, lebo DB engine nerozlisuje prioritu tabuliek, schem.
Pořád mi připadá že IMHO je méně práce nakonfigurovat vlastní instanci DB engine pro tuto kritickou DB, než hrátky s RAM diskem a konzistencí s HDD.
Audit na update samozřejmě nějaké stránky v RAM zabere, ale pochybuji že to překročí významnou mez třeba 5 % z uvedených 64 GB.
-
JardaP:
mate pravdu, ze pri restarte by sa to malo kontrolovat. doplnim do scriptu. Horsie sa handluju prave katastroficke pady (vypadok prudu na oboch napajacich vetvach atp....) Ako som uz spomenul, nie je to uplne idealne riesenie, ma svoje rizika...
Tak pokud mate stroj teto konfigurace bez UPS, tak to je hned jeste vetsi prdel .
-
Mirek: ja v tom vidim mladicke nadseni a zejmena nerozvaznost zpusobenou pramalou zkusenosti. Ocenil bych vsak originalitu pri hledani reseni.
Pro same stromy nevidi les a jednou se bude hodne divit pokud to takto bude provozovat. Zkuseny clovek by to samozrejme resil tak, aby zachoval spolehlivost - treba prave pres ZFS(je jedno jestli ma ty soubory v pameti protoze ramdisk nebo protoze ZFS).
-
ja by som skusil namiesto priameho pristupu do DB napchat medzi applikaciu a DB jeden service layer ktory by sa staral len o citanie a zapis
pri citani si vies pekne poriesit cachovanie(priorita, TTL,..) toho co potrebujes priamo v pamati...
-
Jaký je důvod, proč to tak neudělat?
je, a velmi jednoduchy, ZFS mi na um neprislo ;) Je asi dovod preco mas rank GURU ;)
Dakujem za uzitocny typ.
Tak pokud mate stroj teto konfigurace bez UPS, tak to je hned jeste vetsi prdel .
Obe vetvy su zalohovane cez UPS a jedna z nich este aj cez naftak, bez toho by som sa do ramdisku nepustal ;)
Lobo:
v specifikacii mam definovane, ze ziadne data na ktore nema pouzivatel opravnenie nesmu opustit db na vyssiu vrstvu (napr na webserver). data sa filtruju priamo v db views, niekedy az na uroven stlpca, takze nejaky caching na urovni nad databazou nepripada do uvahy.
to_je_jedno
dik za konstruktivnu kritiku ;)
-
Ahoj,
pro takovéto případy používáme rapiddisk www.rapiddisk.org (http://www.rapiddisk.org)
Vytváří vrstvu pomocí dm nad fyzickým diskem (jiným blokovým zařízením), odolnost proti výpadku je tedy srovnatelná jako bez ramdisku (v případě použití módu WRITETHROUGH).
-
pro takovéto případy používáme rapiddisk www.rapiddisk.org (http://www.rapiddisk.org)
diky
-
pro takovéto případy používáme rapiddisk www.rapiddisk.org (http://www.rapiddisk.org)
Super, dik za typ, hned zajtra to testnem.
-
typ neni tip.
-
Už to tady pár lidí naťuklo, ale nikdo to asi neřekl dostatečně přesvědčivě. Takže pozor:
Vykašli se na ten ramdisk!
Já taky před pár lety podobnou kravinu udělal, protože jsem nerozumněl tomu, jak MySQL funguje. Dnes se tomu směju.
Trocha teorie: MySQL (MariaDB), resp. InnoDB (o MyISAM/Aria 1.x se snad ani nebavíme) všechny operace provádí nad strukturou nazvanou buffer_pool umístěnou v RAM. Disk z pohledu běžícího innodb funguje spíš jako swap v OS kam se hází data až když se nevejdou do paměti (resp. non-dirty data se samozřejmě neukládají, protože tam už jsou, je to analogie trochu volná).
To znamená:
Tu velikost, kterou jsi nastavil ramdisku nastav na buffer_pool v konfiguráku MariaDB, díky tomu budeš mít všechna data v paměti a při čtení se o disk ani neškrne, navíc předejdeš zbytečnému kopírování RAMDisk -> buffer_pool.
Teď zápisy: MariaDB už nemá ten deb... ehm zbytečný limit 4GB na velikost logů. Máš-li místo na disku, nastav velké logy co to jde (typicky bývají ve 2 souborech a nastavuješ velikost jednoho souboru). Tím dosáhnež toho, že každý zápis se provede pouze v RAM + sekvenční zápis do logů (místo okamžitého random zápisu do disku ve tvém RAID1) a jednou za čas (pokud budeš mít velké logy, tak to budou klidně hodiny třebas i den) se část buffer_poolu zapíše na disk (navíc innodb to dělá docela inteligentně). Pokud ti ta rychlost bude ještě pořád málo, dej si logy na jiný disk.
Suma sumárum dostaneš takto vždy lepší výkon než nejlepší možný případ toho RAIDu s ramdiskem + plotna. Data budou vždy konzistentní (vše je v logách), jediný "problém" se kterým musíš počítat je, že pokud to spadne, bude chvíli (pár minut) trvat, než se přehrají logy (to můžeš sledovat v error logu). Ale toto je mnohokrát ověřený scénář, který funguje a na který se můžeš spolehnout. Ehm až teda na pád při běžícím alter table, truncate table atd., ale to je prostě průšvih návrhu MySQL, kterému se prostě nijak nevyhneš ani svým řešením (a zas tak často se to nestává).
-
typ neni tip.
Skutocne najhodnotnejsi prispevok k vecY...
-
Pokusim sa zhrnut odpovede do jedneho prispevku:
...
Pouzivas blbou databazi and/or ji nemumis nastavit. Databaze si do pameti cachuje to, k cemu casto pristupuje, zbytek neresi.
+viz predchozi, raid je zalozenej na tom, ze v okamziku, kdy ti FS posle ze ulozeno, tak je skutecne ulozeno (na hdd). Pokud tobe ten tvuj potvrdi ulozeni, muze to byt klidne jen v RAM a tudiz v okamziku kdy to zbuchne nemas nic. Co vic, mas databazi ve zcela nekonzistetnim stavu. Vyzkousej si to. Nahod si to na testovacim stroji a posli do toho aspon par stovek inser/update a vypni to.
=> ty data vlastne nanic nepotrebujes, cemuz odpovida i cena reseni.
Už to tady pár lidí naťuklo, ale nikdo to asi neřekl dostatečně přesvědčivě. Takže pozor:
Vykašli se na ten ramdisk!
...
Tak nejak.
-
Pre tých, ktorí by toto chceli skúšať s PostgreSQL, doplním:
Rýchlosť behu PostgreSQL z RAMdisku je plusmínus zhodná s rýchlosťou behu z disku pri vypnutom fsync. To nie je teória, mám to overené prakticky. Takže namiesto tohoto krkolomného cvičenia stačí nastaviť v postgresql.conf parameter fsync=off. U nás to používajú vývojári na spúšťanie unit testov - tie ktoré predtým trvali 5 minút sa skrátili na 10 sekúnd. Ale na ostrý server by som to nedával.
-
ktorí by toto chceli skúšať s PostgreSQL
RAM disk s PostgreSQL nikdo s mozkem v hlavě zkoušet nebude. Na nečekání na zápis na HDD je parametr synchronous_commit=off, nikoliv fsync=off.
-
ktorí by toto chceli skúšať s PostgreSQL
RAM disk s PostgreSQL nikdo s mozkem v hlavě zkoušet nebude. Na nečekání na zápis na HDD je parametr synchronous_commit=off, nikoliv fsync=off.
Mno, svet nie je binarny ;-) PostgreSQL z ramdisku je sice "divny" ale zalezi na use-case vsakze. A ci to funguje? Jasne ze ano ale db je riadne specificka (VELA writes/sec, plno triggerov, skoro ziadne reads), mozno by bolo treba inu technologiu, ale kedze je dany postgres (a prekopat to do niecoho ineho stoji vela $$$), znasilnuje sa postgres...
-
Znásilňuje se proto, že se nečtou manuály a dokumentace.
-
Znásilňuje se proto, že se nečtou manuály a dokumentace.
V mojom prípade to vyzeralo tak, že prišli vývojári, či sa nedá devel databáza nainštalovať do RAMdisku. Keď prišli s takou priamočiarou požiadavkou, tak som ju priamočiaro vykonal (s poznámkou, že ide o blbý nápad). Veľa som si od toho nesľuboval, ale zjavne im to pomohlo. Tak som hľadal ďalej, či sa toto zlé riešenie nedá zlepšiť. Nakoniec som došiel ku fsync=off (podľa manuálu). Že sa rovnaký výsledok dá dosiahnuť aj cez synchronous_commit som zistil až teraz. Znie to rozhodne bezpečnejšie ako vypnúť fsync.
-
Plně chápu a soucítím ;-)
-
několik lidí tady zmiňujě, že dnešní databáze je zbytečné dávat do ramdisku, že si to databáze cachují do ram sami, atd.atd.
Ale proč tedy firmy jako SAP přepsali celej DB engine viz "HANA", kde jde právě o čístou implementaci do RAM paměti sevším všudy...?
-
HANA samozřejmě průběžně zapisuje na HDD. Rozdíl mezi in-memory a standardní DB je hlavně v politice. Standardní DB musí při COMMIT čekat na dokončení zápisu dat na HDD, zatímco in-memory DB ne, data se zapíší na HDD třeba až za pět minut.
-
zajdan: nikdo nezpochybnuje "nacpat to do RAM", jen zpochybnujeme ramdisk a raid pole jako vhodny nastroj.
-
několik lidí tady zmiňujě, že dnešní databáze je zbytečné dávat do ramdisku, že si to databáze cachují do ram sami, atd.atd.
Ale proč tedy firmy jako SAP přepsali celej DB engine viz "HANA", kde jde právě o čístou implementaci do RAM paměti sevším všudy...?
Databaze jako Oracle, Informix anebo i MSSQL do jiste miry duplikuji funkcionalitu kernelu OS. Maji vlastni memory management, vlastni "drivery" pro pristup na disk, vlastni "lvm", vlastni scheduler (Infx), vlastni system prav, vlastni zalohovani, atd. Navic implementuji vlastni multiversioning(snapshoty).
Nu druhou stranu ale maji jiny problem, byly navrhovane v dobe kdy RAM byla draha, a pomer mezi kapacitou RAM a objemem dat na disku byl treba 1:1000. U Oracle je kapacita databaze prakticky nekonecna, protoze jeho interni adresni prostor pouziva UROWID, ktere ma variabilni delku, in-memory databaze si jednoduse vystaci s 64-bit pointerem. Pred 20ti lety by se pouzivani 64bit zdalo jako plytvani mistem, dneska je ale pameti hodne prace se skutecnymi pointery je mnohem jednodussi.
Pro vsechny databaze ale plati, ze maji svuj adresni prostor oznaceny jako neswapovatelny a obchazeji diskovou cache OS.
A pro diskove operace pouzivaji krome read/write jeste DIRECT_IO, mmap/msync, aio popr. jeste neco jineho. Databaze maji na OS specificke pozadavky, ale na druhou stranu toho vlastne chteji od OS docela malo(napr. alokuji pamet pouze pri startu) a vsechno si delaji samy. Pouze u MySQL se chybejici funkcionalita supluje prostredky operacniho systemu.
-
V mojom prípade to vyzeralo tak, že prišli vývojári, či sa nedá devel databáza nainštalovať do RAMdisku. Keď prišli s takou priamočiarou požiadavkou, tak som ju priamočiaro vykonal (s poznámkou, že ide o blbý nápad). Veľa som si od toho nesľuboval, ale zjavne im to pomohlo. Tak som hľadal ďalej, či sa toto zlé riešenie nedá zlepšiť. Nakoniec som došiel ku fsync=off (podľa manuálu). Že sa rovnaký výsledok dá dosiahnuť aj cez synchronous_commit som zistil až teraz. Znie to rozhodne bezpečnejšie ako vypnúť fsync.
takze az za tebou prijedou vyvojari s tim, ze potrebuji mit na serveru k dispozici worldwide read/write ftp server ve kterem budou data firemni databaze, tak jim taky vyhovis? Ja ti nevim, ale pokud za mnou nekdo dojde s takovouhle peetchovinou, tak mu to slusne nacrtnu v cem je problem a pak at se jde zamyslet nekam...
-
ano opravdu OMG, ale omg v tom smyslu, že namísto aby jste byli rádi, že se podělí o technickou zkušenost, tak sem zatahujte 'politicke' pohledy na věc...už se na to někteří kuvafix vyprdnite a nebo to prostě nekomentujte
-
Pouze u MySQL se chybejici funkcionalita supluje prostredky operacniho systemu.
Právěže ne. InnoDB si právě dělá všechno samo (mělo by to fachat i s RAW zařízením, ale to jsem nezkoušel) a nepoužívat s InnoDB DirectIO je z 99% nesmysl (tím 1% myslím současné používání jiných storage enginů). To co píšeš platí zejména pro Firebird, do značné míry pro Postgres a pro všechny noSQL co jsem potkal.
Právě InnoDB má toto pořešené dost dobře a je nesmysl ho cpát na ramdisk.
-
V mojom prípade to vyzeralo tak, že prišli vývojári, či sa nedá devel databáza nainštalovať do RAMdisku. Keď prišli s takou priamočiarou požiadavkou, tak som ju priamočiaro vykonal (s poznámkou, že ide o blbý nápad). Veľa som si od toho nesľuboval, ale zjavne im to pomohlo. Tak som hľadal ďalej, či sa toto zlé riešenie nedá zlepšiť. Nakoniec som došiel ku fsync=off (podľa manuálu). Že sa rovnaký výsledok dá dosiahnuť aj cez synchronous_commit som zistil až teraz. Znie to rozhodne bezpečnejšie ako vypnúť fsync.
takze az za tebou prijedou vyvojari s tim, ze potrebuji mit na serveru k dispozici worldwide read/write ftp server ve kterem budou data firemni databaze, tak jim taky vyhovis? Ja ti nevim, ale pokud za mnou nekdo dojde s takovouhle peetchovinou, tak mu to slusne nacrtnu v cem je problem a pak at se jde zamyslet nekam...
Jedná sa o vývojový DB server, na ktorom nie sú ostré dáta. Vývojový server je na to, aby sa na ňom skúšalo, hoci aj takéto psie kusy.
V Tvojom hypotetickom prípade upozorním dotyčného na riziká, ktorých som si vedomý a keď bude na požiadavke trvať, tak ju vykonám. Som platený od toho čo urobím a nie od toho, čomu všetkému zabránim. Navyše mojim cieľom nie je pretvárať svet, či dokazovať svoju dôležitosť. Ja chcem len poskytnúť služby, ktoré zákazníci požadovali a na konci mesiaca za to vystaviť primerané faktúry.
Našťastie robím s ľuďmi, ktorí sú celkom inteligentní. Keď mi občas chýba, že zo mňa nikto nerobí debila - to potom vyleziem na internet a prispievam do diskusií, aby som si to vynahradil. Ďakujem, že si mi pomohol. ;D
-
Jedná sa o vývojový DB server, na ktorom nie sú ostré dáta. ...
=> takze ses primou pricinou zcela nefunkcniho a nepouzitelnyho vyslednyho produktu. Protoze vyvojar pak u zakaznika cumi jak puk, protoze "jemu to prece fungovalo OK". Pokud se neco testuje, tak vzdy za podminek v nejhorsim pripade shodnych, za jakych to ma behat ve skutecnosti, v idealnim pripade za podminek mnohem horsich.
-
Jedná sa o vývojový DB server, na ktorom nie sú ostré dáta. ...
=> takze ses primou pricinou zcela nefunkcniho a nepouzitelnyho vyslednyho produktu. Protoze vyvojar pak u zakaznika cumi jak puk, protoze "jemu to prece fungovalo OK". Pokud se neco testuje, tak vzdy za podminek v nejhorsim pripade shodnych, za jakych to ma behat ve skutecnosti, v idealnim pripade za podminek mnohem horsich.
to mu ale nevysvetlis, ze debilni napady treba ustrihnout hned na zacatku a ne az to nekde produkcne nasazujes... Pokud je pro nej normalni pro developeri nasazovat takovouhle debilitu, pak se jiz nicemu nedivim...
-
Jedná sa o vývojový DB server, na ktorom nie sú ostré dáta. Vývojový server je na to, aby sa na ňom skúšalo, hoci aj takéto psie kusy.
V Tvojom hypotetickom prípade upozorním dotyčného na riziká, ktorých som si vedomý a keď bude na požiadavke trvať, tak ju vykonám. Som platený od toho čo urobím a nie od toho, čomu všetkému zabránim. Navyše mojim cieľom nie je pretvárať svet, či dokazovať svoju dôležitosť. Ja chcem len poskytnúť služby, ktoré zákazníci požadovali a na konci mesiaca za to vystaviť primerané faktúry.
Našťastie robím s ľuďmi, ktorí sú celkom inteligentní. Keď mi občas chýba, že zo mňa nikto nerobí debila - to potom vyleziem na internet a prispievam do diskusií, aby som si to vynahradil. Ďakujem, že si mi pomohol. ;D
budto pracujes pro nejakou debilni 1 man firmu, nebo vasi manazeri nehlidaji costs. Vyvojovy DB server je od toho aby se na nem vyvijelo, testovaci DB server je od toho aby se na nem testovalo. Vyvoj i testovani ma sve specifika, ale pokud nekdo prijde za tebou, ze mu nevadi prijit o produkcni data (testovaci scenar s DB v RAM) a ty mu v tom vyhovis, pak proste nepremyslis... To neni o blokovani neceho, to je o predvidani problemu a upozorneni na ne dokud to jeste produkcne nenasazujes... Pokud to ten vyvojar neakceptuje, mas sanci na to upozornit manazment a az to nekde produkcne nasadi a zakaznik prijde o data, muzes treba povysit... ;) Nikdo z tebe debila nedela, vsichni ti jenom rikaji ze ve tvem pripade databaze v ramdisku je riziko...
-
OMG, j: máte úplnú pravdu. Robím pre šupácke firmy, ktoré robia šupácke produkty. Som priamym a jediným dôvodom, prečo sa im nedarí. Potom chodím na internet zhadzovať iných, aby som sa necítil ako taká nula. Preto som aj za Vás rád, že aspoň ku Vám sa život zachoval lepšie. ;D
-
Santa: Super pokus a díky za zápisek.
Celkem mám problém s pomalým čtením z disků a díky tvému zápisku si říkám, proč tam vlastně do RAID1 nedám jedno SSD. S tím writemostly (neznal jsem) na běžný disk by to snad mohlo být celkem stabilní a i rychlý.
-
OMG, j: máte úplnú pravdu. Robím pre šupácke firmy, ktoré robia šupácke produkty. Som priamym a jediným dôvodom, prečo sa im nedarí. Potom chodím na internet zhadzovať iných, aby som sa necítil ako taká nula. Preto som aj za Vás rád, že aspoň ku Vám sa život zachoval lepšie. ;D
Kašli se ně, mají evidentně nějakou poruchu osobnosti ;)
-
Znásilňuje se proto, že se nečtou manuály a dokumentace.
Nope. Znasilnuje sa preto ze to funguje, a v ramdisku to funguje lepsie ako s fsync=off atd. Pretoze aj s fsync=off disk/OS zdochne na prilis vysoke iops, kedze tie data DB engine nakoniec zapisat musi. Ako som uz napisal, zalezi na use-case. Vyskusane...
-
Nope. Znasilnuje sa preto ze to funguje, a v ramdisku to funguje lepsie ako s fsync=off atd. Pretoze aj s fsync=off disk/OS zdochne na prilis vysoke iops, kedze tie data DB engine nakoniec zapisat musi. Ako som uz napisal, zalezi na use-case. Vyskusane...
Vyzkoušel sis kulové, s fsync=off DB engine zapíše do systémové diskové cache a na HDD to čeká pouze tehdy když se sejde dat k zápisu více než je velikost cache. Se synchronous_commit=off není ani tento problém.
-
Nope. Znasilnuje sa preto ze to funguje, a v ramdisku to funguje lepsie ako s fsync=off atd. Pretoze aj s fsync=off disk/OS zdochne na prilis vysoke iops, kedze tie data DB engine nakoniec zapisat musi. Ako som uz napisal, zalezi na use-case. Vyskusane...
Vyzkoušel sis kulové, s fsync=off DB engine zapíše do systémové diskové cache a na HDD to čeká pouze tehdy když se sejde dat k zápisu více než je velikost cache. Se synchronous_commit=off není ani tento problém.
:) srandista
-
jj, vyzkoušel sis kulové.
-
Znásilňuje se proto, že se nečtou manuály a dokumentace.
Nope. Znasilnuje sa preto ze to funguje, a v ramdisku to funguje lepsie ako s fsync=off atd. Pretoze aj s fsync=off disk/OS zdochne na prilis vysoke iops, kedze tie data DB engine nakoniec zapisat musi. Ako som uz napisal, zalezi na use-case. Vyskusane...
Jasne, zatimco u ramdisku mirorovanyho s diskem se ty data na ten disk nakonec zapsat nemusi ... lol
Mimochodem, kazdej kdo nekdy stavel nejaky diskovy pole, ti mimo jiny rekne, ze sice muzes pouzit rychlejsi/pomalejsi disk, ale ze to vzdycky degraduje vykon na ten nejpomalejsi clanek. Protoze pokud mas nastaveny zrcadlo, tak maly odchylky (protoze zadny dva disky nejsou stejny) vyresi pochopitelne cache, ale jakmile se zaplni, tak bude (protoze musi z principu) system vzdy cekat.
Vubec nemluve o tom, ze ramdisk je o rad az dva pomalejsi, nez primy adresovani RAM (tak jak to dela kazda normalni databaze). Proste proto, ze tam jeste navrch musi bejt FS a vsecho kolem.
-
Znásilňuje se proto, že se nečtou manuály a dokumentace.
Nope. Znasilnuje sa preto ze to funguje, a v ramdisku to funguje lepsie ako s fsync=off atd. Pretoze aj s fsync=off disk/OS zdochne na prilis vysoke iops, kedze tie data DB engine nakoniec zapisat musi. Ako som uz napisal, zalezi na use-case. Vyskusane...
Jasne, zatimco u ramdisku mirorovanyho s diskem se ty data na ten disk nakonec zapsat nemusi ... lol
Mimochodem, kazdej kdo nekdy stavel nejaky diskovy pole, ti mimo jiny rekne, ze sice muzes pouzit rychlejsi/pomalejsi disk, ale ze to vzdycky degraduje vykon na ten nejpomalejsi clanek. Protoze pokud mas nastaveny zrcadlo, tak maly odchylky (protoze zadny dva disky nejsou stejny) vyresi pochopitelne cache, ale jakmile se zaplni, tak bude (protoze musi z principu) system vzdy cekat.
Vubec nemluve o tom, ze ramdisk je o rad az dva pomalejsi, nez primy adresovani RAM (tak jak to dela kazda normalni databaze). Proste proto, ze tam jeste navrch musi bejt FS a vsecho kolem.
Ramdisk mirrorovany nie je, masina skape => db sa znova vytvori. Vyskusane a benchmarkovane to je (a to "kulovy" si mozete strcit odkial to prislo ;-) ).
-
Vzhledem k tomu, ze nezvladas pouzivat tak slozity s sofitikovany system jako tohle forum, tak o databazi vis asi 10x vetsi howno. Kcemu asi tak nekomu bude databaze, ze ktery s kazdym vypnutim zmizej data, ktery do ni zapisuje ... lol. Nemluve o tom, ze si ani neumis precist o cem je tu rec.
-
Vyskusane
Vyzkoušel sis kulové, už mě to nebaví psát pořád dokola.
-
Nope. Znasilnuje sa preto ze to funguje, a v ramdisku to funguje lepsie ako s fsync=off atd. Pretoze aj s fsync=off disk/OS zdochne na prilis vysoke iops, kedze tie data DB engine nakoniec zapisat musi. Ako som uz napisal, zalezi na use-case. Vyskusane...
Vyzkoušel sis kulové, s fsync=off DB engine zapíše do systémové diskové cache a na HDD to čeká pouze tehdy když se sejde dat k zápisu více než je velikost cache. Se synchronous_commit=off není ani tento problém.
a ta systemova diskova cache je kde umistena ? Ze by v ram.
-
a ta systemova diskova cache je kde umistena ? Ze by v ram.
Nepřekvapivě ve stejné RAM jako RAM disk.
-
HANA samozřejmě průběžně zapisuje na HDD. Rozdíl mezi in-memory a standardní DB je hlavně v politice. Standardní DB musí při COMMIT čekat na dokončení zápisu dat na HDD, zatímco in-memory DB ne, data se zapíší na HDD třeba až za pět minut.
Jen pro upřesnění, HANA taky každý COMMIT píše synchronně na disk (do redo logu na ssd, nebo fusion-io kartu). Jinak by při výpadku přišla o data.