Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

[messagebus]

Chapu, jsou to amateri. Taky tam nepisou, ze to ma problem s rychlosti zapisu, kdyz se do toho vsi silou mlati kladivem.

[Reklama]

[Rob Ros]

Já jen kroutím hlavou nad tím, že někdo raději koupí dražší hardware jen kvůli tomu, aby měl potenciálně stejný výkon na ZFS jako předtím na ext4. Kdyby bylo složité MySQL zálohovat tak neřeknu, ale tohle mi připadá jako strkání hranolu do kulatého otvoru.

No těch serverů máme hodně. A hlavní databáze musí jet 24/7 bez výpadků. Díky snapshotům je stěhování podstatně jednodušší než dělat z repliky hlavní stroj. Je to prostě příliš složité než aby se neukázal nějaký zádrhel. Chci hlavně jednotný způsob stěhování pro všechny virtuály.
A také se mi nechce věřit že by ten rozdíl byl až takový. S novým strojem budu moci udělat nové testy a hledat proč je rozdíl tak velký.

Na zalohovani (a pripadnou migraci dat) zive MySQL neni potreba zastaveni databaze a ani bezici replika. Staci pouzit nastroj k tomu urceny - xtrabackup.

[xsouku04]

Já jen kroutím hlavou nad tím, že někdo raději koupí dražší hardware jen kvůli tomu, aby měl potenciálně stejný výkon na ZFS jako předtím na ext4. Kdyby bylo složité MySQL zálohovat tak neřeknu, ale tohle mi připadá jako strkání hranolu do kulatého otvoru.

No těch serverů máme hodně. A hlavní databáze musí jet 24/7 bez výpadků. Díky snapshotům je stěhování podstatně jednodušší než dělat z repliky hlavní stroj. Je to prostě příliš složité než aby se neukázal nějaký zádrhel. Chci hlavně jednotný způsob stěhování pro všechny virtuály.
A také se mi nechce věřit že by ten rozdíl byl až takový. S novým strojem budu moci udělat nové testy a hledat proč je rozdíl tak velký.

Na zalohovani (a pripadnou migraci dat) zive MySQL neni potreba zastaveni databaze a ani bezici replika. Staci pouzit nastroj k tomu urceny - xtrabackup.

My používáme stále zastaralou myIsam, který zdá se má jedinou podstatnou nevýhodu v tom, že jeden select může někdy zamčít celou tabulku. To řešíme tak, že náročnější, ale méně důležité čtení provádíme z clonů. Jinak pro naše použití má mírně vyšší výkon než innodb.  Výhoda je, že zálohu je možné provést obyčejným rsync. Pokud chci mít jistotu, že nebudu muset opravovat nějakou tabulku, tak mohu na pár vteřin umělě tabulky zamčít a poté provést rsync znovu. ZFS snapshot je rychlejší a spolehlivější a zamčení tabulek se tak počítá na milisekundy a lze tedy udělat i za plného provozu.
Jinak používáme  klonování, tedy provést kopii celé databáze je potřeba jen naprosto výjimečně právě pro nastartování klonování. Pak už stačí provádět zálohy z klonu, který se může zastavit i na dlouhé hodiny, protože to poté dožene.
ZFS je ale dobré v tom, že může v pravidelných intervalech (třeba i jednou za 5 minut) dělat zálohu celého serveru, který pak stačí prostě spustit někde jinde s tím, že se přijde o data maximálně za 5 minut. (ale i ty bychom patrně našli v klonech, takže oni to ne). A hlavně, přes ZFS lze takto zálohovat libovolný virtuál  nejenom databázi.

S innodb jsme experimentovali a jednou se nám stalo, že se data natolik poškodila, že se z nich nedalo vyčíst vůbec nic. To se myisam nestane.

S xtrabackup nemám zkušenost.

[Exceptions]

My používáme stále zastaralou myIsam, který zdá se má jedinou podstatnou nevýhodu v tom, že jeden select může někdy zamčít celou tabulku. To řešíme tak, že náročnější, ale méně důležité čtení provádíme z clonů.

hlavně myIsam má podstatnou nevýhodu v neexistující kontrole integrity dat, nemožnosti z některých poruch tabulku rekonstruovat. Neměla by v ní být data, která nemám nikde jinde a o která nechci přijít.

[Rob Ros]

S innodb jsme experimentovali a jednou se nám stalo, že se data natolik poškodila, že se z nich nedalo vyčíst vůbec nic. To se myisam nestane.

Tyjo, tak ty experimenty by me tedy zajimaly. Protoze si moc nedokazu predstavit situaci, kdy shodim InnoDB takovym zpusobem, ze neprectu vubec nic, a v te same situaci z MyISAM ano. Navic u MyISAM si nemuzete byt jisti, ze prectena data jsou opravdu ta, ktera tam maji byt.

Cele me to fascinuje, ze kvuli ZFS jste ochotni obetovat vykon ale pro zaruceni integrity databaze nikoliv.

[Reklama]

[xsouku04]

No kdybych to celé dělal znovu, tak samozřejmě použiji už inodb, ale databáze se zakládala před patnácti lety. Ale jelikož potřebujeme dostupnost 24/7 tak se mi  do přechodu z lety osvědčeného myisam moc nechce.
Rozumím tomu, že konzistence dat např. u účetnictví je naprosto zásadní, ale pokud nezaúčtuji nebo ztratím např. jeden hovor z deseti milionů, tak to žádný zásadní problém není. Ale ani s tím jsem se nesetkal. Pro některé aplikace, např. logování je fakt jedno jestli použijete myisam nebo inodb.
Předpokládám, že overhead kvůli zfs bude zanedbatelný, za to snadné stěhování virtuálů z jedhoho fyzického stroje na jiný si myslím, že to stojí. Hlavně to mít vždy možnost spustit to stejné na záložním stroji.

Pro toho kdo si může dovolit alespoň noční nebo ještě lépe víkendové odstávky jsou samozřejmě priority jinde.

[Exceptions]

nejde ale o problém ztráty jednoho řádku, ale ztráty celých datových souborů se spoustami řádků, nikdo pak nedokáže říct, co tam vlastně bylo a jak. Stejně tak při poškození ti to může vracet jiné hodnoty. MyIsam používá takovou divnou binární strukturu, kdy v souboru .frm je uvedena struktura tabulky, jednotlivé sloupce mají své flagy, poté v .myd jsou je uveden flag sloupce a poté binární obsah a takhle pořád dokola. Pokud se něco poškodí, část dat zmizí nebo tam vznikne jiná chyba, nemáš moc záchytných bodů jak poznat od sebe samotná binární data a struktury. Je možné se tím snažit ručně nějak projít a najít bod, kdy se to začalo rozbíjet, ale je to obrovsky těžké, už u desítek společností jsem se snažil z toho vydobít kritická data. Dělej zálohy a nespoléhej na to, že se to nerozbije. U dlouho běžících systémů bez ECC lze pozorovat i chyby, které způsobují chyby paměti.

[xsouku04]

nejde ale o problém ztráty jednoho řádku, ale ztráty celých datových souborů se spoustami řádků, nikdo pak nedokáže říct, co tam vlastně bylo a jak. Stejně tak při poškození ti to může vracet jiné hodnoty. MyIsam používá takovou divnou binární strukturu, kdy v souboru .frm je uvedena struktura tabulky, jednotlivé sloupce mají své flagy, poté v .myd jsou je uveden flag sloupce a poté binární obsah a takhle pořád dokola. Pokud se něco poškodí, část dat zmizí nebo tam vznikne jiná chyba, nemáš moc záchytných bodů jak poznat od sebe samotná binární data a struktury. Je možné se tím snažit ručně nějak projít a najít bod, kdy se to začalo rozbíjet, ale je to obrovsky těžké, už u desítek společností jsem se snažil z toho vydobít kritická data. Dělej zálohy a nespoléhej na to, že se to nerozbije. U dlouho běžících systémů bez ECC lze pozorovat i chyby, které způsobují chyby paměti.

ECC máme. Jinak asi máme štěstí, že jsem nikdy nic takového zatím neviděl. Jediné co se někdy stalo, je když se zkopíruje tabulka za chodu (soubory tabulky), nebo vypadne elektřina, musí se daná tabulka opravit. Po opravě žádné viditelné poškozených jsem niky neviděl. Jinak zálohovat se musí vždy.Kromě nočních záloh (prosté rsync) máme několik clonů.

[xsouku04]

Tak jsem pořídil jiné disky konkrétně do jednoho ze dvou serverů  GIGABYTE NVMe 1TB SSD  a Patriot VIPER VPN100 SSD 1TB a Patriot VIPER VPN100 SSD 1TB

https://www.alza.cz/gigabyte-nvme-ssd-1tb-d5693273.htm
https://www.alza.cz/patriot-viper-vpn100-ssd-1tb-d5505745.htm

Jsou zapojeny do Raid 1 se  zfs. Jsou zapojeny přes redukce jako https://www.alza.cz/gaming/axagon-pcem2-n-d5710624.htm protože serverová deska je starší a nemá přímo sloty. Schválně každý jiný, aby neměli stejný bug ve firmware a neodešli stejně. Podle mojí zkušenosti (již zjevně více jak 50 disků od toho kdy SSD začali) je zabagovaný nepředvídatelný firmware nejslabší  místo SSD disků.

Co je zajímavé, že ve většině případů naměřím jen cca dvojnásobné množství IOPS oproti těm levným Kingstone diskům.
Kde je ale rozdíl podstatně větší je pokud spustím konkrétně

Kód: [Vybrat]

fio --name=randrw --rw=randrw --direct=1 --ioengine=libaio --bs=16k --numjobs=1 --rwmixread=80 --size=10G --runtime=300 --group_reporting
Je to test, který mi kdosi poradil výše na tomto fóru, aby se testovalo zatížení podobné tomu, jaké dělá databáze.
Při tomto testování těm levným Kingstone diskům příšerně kolísá výkon a pohybuje se mezi 1 IOPS po cca 190 IOPS. U těch nových je to mnohem stabilnější a to mezi 300-400 IOPS.
Co jsem ale nyní u těch starých Kingstonů pozoroval, že testovací 10 GB soubor co se vytváří před začátkem testu to vytvářelo neúměrně dlouho. Tak jsem se chtěl vedle v okně podívat co se děje a spustit htop a přestože systém běží na jiném magnetickém disku, htop mi nechtěl naskočit. Čekal jsem řádově minuty a pořád nic až jsem přerušil ten test pomocí ctrl+c, což ale na reakci také čekalo cca minutu. Zjevně se ty Kingstone disky dovedou úplně zaseknout i na velmi dlouho dobu a způsobovat tak zvláštní a náhodné potíže i libovolné jiné aplikaci pracující s diskem. Pořád přemýšlím jestli je to jejich vlastnost, nebo nějaká vadná série. Je ale pravda, že při běžné práci v notebooku podobné stavy budou asi vzácné a nikdo to jen tak běžně reklamovat nebude.  Případně si nebude jistý, že za to může disk, takže míra reklamací a množství negativních recenzí může být pro Kingstone přijatelná a nemotivuje jej si chybu opravit. I když vytvořit 10 GB soubor není zase něco tak zvláštního.Protože by se nějaká aplikace zasekla na celé minuty jen proto, že jiná aplikace více zapisuje (neskutečně pomalu) asi nebude běžné chování i u těch nejlevnějších disků. Předpokládám proto, že to musí být nějaký Kingstone šlendrián. Je ale pravda, že dražším diskům by tohle rozhodně neprošlo už také proto, že jej používají zdatnější uživatelé na náročnější věci, kteří by si to líbit nenechali a rozmazali by to v recenzích.

Děkuji všem za rady a nápady, snad to pomůže i někomu dalšímu. Ono se podobné chování může přihodit i drahých disků (jeden z prvních SSD disků co jsem měl - určených pro servery byl tak problémový, že po několika reklamacích nakonec vrátili peníze).

[messagebus]

Rozdily mezi ssd disky urcenymi pro desktopy s jejich charakteristickou zatezi a servery se na forech resily a vyresily uz pred mnoha lety. Rozumnym lidem nezbyva nez tyto konstrukcni rozdily akceptovat a prestat chtit pouzivat medicinbal na hrani kosikove, prestoze oba mice jsou urcene pro sport.

[ondrej _]

Rozdily mezi ssd disky urcenymi pro desktopy s jejich charakteristickou zatezi a servery se na forech resily a vyresily uz pred mnoha lety. Rozumnym lidem nezbyva nez tyto konstrukcni rozdily akceptovat a prestat chtit pouzivat medicinbal na hrani kosikove, prestoze oba mice jsou urcene pro sport.

Plny suhlas a cudujem sa, ze sa stale niekto najde, ktory to ignoruje.

To xsouku04:

Tie nove disky, co si kupil su lespie ale stale to su consumer grade. V dnesnej dobre roznych SLC cache a TLC/QLC NAND s neznamym spravanim sa pod zatazou, ta obdivujem, ze nieco take mas tam odvahu davat. Ten prvy kingston A400 bol riadna odvaha(skor hlupost, bez urazky). To su SSD do uplne lacnych laptopov/PC, ktore po par sekundach padaju na/pod uroven kalsickych diskov s nevyspytatelnou odozvou. Necudujem sa, ze si nevidel rozdiel medzi nimi a klasickymi diskami. Osobne taketo SSD ani nikomu nemontujem ani ako upgrade stareho PC/laptopu. Standardne davam Samsungy EVO, to je istota.
Na taketo pouzitie by som z consumer SSD asi rozmyslal len nad Samsungami 970Pro s este MLC NAND.

Pri na to urcenych a drahych diskoch sa to moze stat ale len chybou. U tychto consumer je to vlastnost a to je ten rozdiel a hlavne to ziaden vyrobca nema zdokumetovane a bez otestovania nezisits akos a ten disk sprava. Skus si pozriet test, kde testuju stabilitu IOPS pri serverovskomz atazeni a consumer SSD sa nechytaju na akykolvek serverovsky SSD. To uz plati od dob starych SATA SSD.

Inac neviem, co si urobil dobre si pouzil rozne SSD. kazdy vyrobca ma inac nastavene spravanie SLC cache a jej velkost, co moze robit problemy alebo mozes narazis na neocakvane/kolisave priebehy. Max by som sa snazil pouzit rozne vyrobne serie ale nie rozne SSD. Rozne SSD by som spolu dokopy nedaval, tam su ovela vecsie rozdiely ako medzi klasickymi diskami od roznych vyrobcov.

To spravanie s tym 10GB suborom pri tak lacnom SSD je normalne. Taky lacny SSD vies dostat do kolien jednoducho a v niektorych situaciach bude na tom horsie ako klasicky disk. Preto su vhodne len na nenarocne pouzitie.