Fórum Root.cz
Hlavní témata => Server => Téma založeno: xsouku04 17. 08. 2022, 00:05:34
-
Zjistil jsem, že když mi běží hodně používaná mysql na zfs (z historických důvodů myisam), ročně to způsobí až 800 TB zapsaných dat. Používám 1 TB SSD disky s životností 300 - 2000 TB. Tedy životnost disku je něco mezi půl rokem a dvěma a půl lety v závislosti na typu a štěstí, což je žalostně málo. Představoval bych si teoretickou životnost alespoň 8 let.
Optimalizace jako noatime, ashift a velikost bloku jen 4K používám, ale nemají zásadní vliv.
Pokud ta stejná databáze se stejným provozem na ext4, tak za 6 let provozu provede jen 25 TB zápisu a 6 let staré disky SSD disky navíc jen o velikosti 256 GB jsou opotřebeny jen z malé části.
Vyplývá to z toho co vrátil smart. smartctl -a /dev/nvme0n1
Také trpí výkon databáze, kdy na ext4 je podstatně lepší i při menší paměti a pomalejších discích.
Nerozumím tomu, jak je možné, že všichni propagátoři zfs zapomínají zmínit takto podstatnou věc. Tedy že zfs není příliš vhodná pro případy, kde je hodně drobných zápisů a změn.
Asi nezbývá než /var/lib/mysq/ dát na ext4.
Kdybych to byl věděl, tak bych nevolil zfs, ale lvm+DRBD+ext4 s podobnou funkcionalitou, ale bez ničení disků a poklesu výkonu.
Máte někdo podobnou zkušenost?
-
Nejak si matne pamatuji, ze pro btrfs se pro urcite aplikace doporucovalo vypinat CoW.. nebude to i tvuj problem ? Co rika google na ZFS + mysql/myisam + SSD write amplification ? Mas oddeleny write intent log nebo je na stejnem zarizeni?
-
Symfony, Laravel z tech vetsich. V CR stale asi jednoznacne nette
EDIT - to sem samozrejme nepatri, opet se mi komentar z jineho tematu poslal do uplne jinyho vlakna. Kouzelny forum
-
Tady je nějaké nastavení pro mysql na zfs.
https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html#mysql
Na zfs IMHO nejde CoW vypnout. Takže asi ext4 bude lepší.
-
Nejak si matne pamatuji, ze pro btrfs se pro urcite aplikace doporucovalo vypinat CoW.. nebude to i tvuj problem ? Co rika google na ZFS + mysql/myisam + SSD write amplification ? Mas oddeleny write intent log nebo je na stejnem zarizeni?
Mám zraid 1, dva 1GB nvme disky, tedy vše je na těch dvou discích. Kompresi zapnutou. Díky za heslo k hledání "SSD write aplification". Našel jsem nějaké stížnosti a rady typu.
Cituji např. odsud https://www.reddit.com/r/zfs/comments/khh19e/mariadb_and_zfs/
- Parity RAID is not a good idea with a workload with updates.
- Copy-on-write is not a good idea with a mostly update-in-place workload.
- Compressed records is quite bad with updates-in-place.
Depending on circumstances, using mirror VDEVs for a set of "ZVOL"s might be a good idea.
Ale že to bude až taková katastrofa nikde nepíší, navíc se to mezi těmi pochvalnými návody o zfs úplně ztrácí.
-
Je nejaky dovod neprejst napr na to ext4?
Apropo, nejak sa negativne body stracaju medzi pozitivnimi -> ste prvy mesiac v praci (akejkolvek)? Vzdy sa vyzdvihuju pozitiva produktu, a jeho negativa sa bud nespomenu vobec, alebo sa daju 4kou pismom niekde na spodok stranky/dokumentu/...
-
Na ZFS se musí minimálně nastavit recordsize na stejnou velikost jako má databáze, aby se předešlo write amplification jevům. CoW to ale bohužel vypnout neumí.
-
[...]
EDIT - to sem samozrejme nepatri, opet se mi komentar z jineho tematu poslal do uplne jinyho vlakna. Kouzelny forum
to se mi deje kdyz sem na nejakej vlakne, vsimnu si ze me root odhlasil, dam prihlasit, tak login to refreshne do jineho vlakna ;-)
-
Na ZFS se musí minimálně nastavit recordsize na stejnou velikost jako má databáze, aby se předešlo write amplification jevům. CoW to ale bohužel vypnout neumí.
Nikde jsem nebyl schopen jaký má MyISAM velikost bloku.
Zde někdo zmiňuje, že má různou velikost bloku.
https://zfsonlinux.topicbox.com/groups/zfs-discuss/Ta83e026003c8ee06
MyISAM doesn't use fixed size pages for data, so leave recordsize=128k
Ale ono platí obecně, že zfs není moc vhodná na databáze, když jde hlavně o rychlost a nyní i rozumnou životnost SSD disků. Špatný výkon jsem naměřil i s inodb a různé nastavení to nijak zvlášť nezměnilo. Opotřebení disků jsem tehdy nesledoval. Kdyby měl ale někdo v databázi třeba účetnictví, může dát přednost konzistenci,protože těch záznamů a updatů nemá miliony jako my.
-
Je nejaky dovod neprejst napr na to ext4?
Apropo, nejak sa negativne body stracaju medzi pozitivnimi -> ste prvy mesiac v praci (akejkolvek)? Vzdy sa vyzdvihuju pozitiva produktu, a jeho negativa sa bud nespomenu vobec, alebo sa daju 4kou pismom niekde na spodok stranky/dokumentu/...
Jde o to, že jsme přešli se všemi virtuály na zfs kvůli pohodlné správě a možnost udělat snapshot/kopii za běhu. A nyní ale musíme kvůli databázím opět zpět na ext4, alespoň pro ty databáze.
Ještě mne napadlo, jestli třeba nepřejít zvol a nad tím ext4, ale nemohu o tom najít nikde moc informací. Nejspíš bych si nepomohl.
-
1, já bych to moc nehrotil. Vzhledem k tomu jak funguje zápis na NAND buňky a wear leveling v SSD tak ssd interně dělá cow stejně jako zfs. Akorát IO co udělá zfs počítá do smartu a ty co dělá samo ne. Takže nejspíš rozdíl v opotřebení disku nebude tak hrozný jako naznačuje smart.
2, je divné že i při recordsize 4KB by ext4 udělala 25TB zápisu za 6 let a zfs 800TB za rok. To by zfs zapisovalo téměř 200x víc dat než ext4
3, 4kB jako recordsize je málo. Předpokládám že máte ashift 12, tedy velikost bloku také 4kB. Pak ale nefunguje komprese. V zfs funguje komprese tak že se vezme blok (o velikosti maximálně recordsize) a ten se zkomprimuje a pak se uloží do tolika bloků o velikosti ashift kolik je potřeba. Pokud tedy máte recordsize 4kB tak se zkomprimuje na například 2kB ale to se stejně kvůli ashift uloží na 4kB.
Ideální velikost pro mysql je 16kB. Je to dost malá hodnota kdy je write amplification malé a zároveň dost vysoká aby se projevila komprese.
Ještě se zeptám jak se projevuje že je na zfs horší výkon? Jde jen o zápis a nebo i o čtení? Chápu správně že je to mirror z dvou nvme?
Já mám totiž zkušenost že se s zfs dá získat většinou vyšší výkon než s ext4. Samozřejmě záleží podle dat a použití, ale u zápisu většinou pomáhá komprese (průměrná db se kterou pracuji má kompresní poměr kolem 2 s zstd kompresí) a to že se v mysql může vypnout doublewrite.
U čtení pomáhá také komprese a to že data jsou v arc cachi uložena komprimovaně. Tedy pokud mám například 100GB RAM pro cache tak u ext4 tam mám 100GB dat a u zfs 200GB a většinou ještě vyšší hitrate kvůli lepšímu chívání arc cache vs LRU cache.
Samozřejmě jsem se setkal i s případy kdy při migraci na zfs poklesl výkon. Ale byly to většinou extrémní případy typu statisíce malých tabulek v mysql nebo ukládání už komprimovaných dat do mysql. Ale většinou migrace na zfs pomůže.
-
1, já bych to moc nehrotil. Vzhledem k tomu jak funguje zápis na NAND buňky a wear leveling v SSD tak ssd interně dělá cow stejně jako zfs. Akorát IO co udělá zfs počítá do smartu a ty co dělá samo ne. Takže nejspíš rozdíl v opotřebení disku nebude tak hrozný jako naznačuje smart.
2, je divné že i při recordsize 4KB by ext4 udělala 25TB zápisu za 6 let a zfs 800TB za rok. To by zfs zapisovalo téměř 200x víc dat než ext4
3, 4kB jako recordsize je málo. Předpokládám že máte ashift 12, tedy velikost bloku také 4kB. Pak ale nefunguje komprese. V zfs funguje komprese tak že se vezme blok (o velikosti maximálně recordsize) a ten se zkomprimuje a pak se uloží do tolika bloků o velikosti ashift kolik je potřeba. Pokud tedy máte recordsize 4kB tak se zkomprimuje na například 2kB ale to se stejně kvůli ashift uloží na 4kB.
Ideální velikost pro mysql je 16kB. Je to dost malá hodnota kdy je write amplification malé a zároveň dost vysoká aby se projevila komprese.
Ještě se zeptám jak se projevuje že je na zfs horší výkon? Jde jen o zápis a nebo i o čtení? Chápu správně že je to mirror z dvou nvme?
Já mám totiž zkušenost že se s zfs dá získat většinou vyšší výkon než s ext4. Samozřejmě záleží podle dat a použití, ale u zápisu většinou pomáhá komprese (průměrná db se kterou pracuji má kompresní poměr kolem 2 s zstd kompresí) a to že se v mysql může vypnout doublewrite.
U čtení pomáhá také komprese a to že data jsou v arc cachi uložena komprimovaně. Tedy pokud mám například 100GB RAM pro cache tak u ext4 tam mám 100GB dat a u zfs 200GB a většinou ještě vyšší hitrate kvůli lepšímu chívání arc cache vs LRU cache.
Samozřejmě jsem se setkal i s případy kdy při migraci na zfs poklesl výkon. Ale byly to většinou extrémní případy typu statisíce malých tabulek v mysql nebo ukládání už komprimovaných dat do mysql. Ale většinou migrace na zfs pomůže.
Děkuji za navedení. Asi to do velké míry bude špatnou kombinací ashift a recordsize.
zpool get all | grep ashift
vrátí 12.
Vytvářelo se to příkazem. Na shift=12 jsem přešel, protože to částečně pomohlo zvýšit výkon.
zpool create -o ashift=12 -O compression=lz4 -O atime=off -O dedup=on ovps mirror /dev/nvme1n1 /dev/nvme0n1
Běží na tom conteinery v lxc.
Na jednom stroji mám virtual s databází s recordsize s 8K - tam to ale za 1,3 roku nadělalo jen 120 TB zápísu
Na druhém stroji mám virtuál s databází recordsize 128K - tady to za rok provozu nadělalo těch 806TB až z toho jeden disk v raidu odešel a proto jsem to začal řešit. Těch 128K je tam ale špatně, plánováno bylo 8K. Rozdíl mezi 128 a 4 je 32 násobek. Tedy vypadá to, že jsem si to tím 32 krát zhoršil.
Všechno jsou to online clony hlavní databáze, která běží na ext4 na podstatně starším hardware.
Tedy z toho plyne, že aby se to nenásobilo u malých updatů a zápisů recordsize nikdy nesmí být větší než ashift? A pokud je recordsize omylem 32 krát větší, nesmyslně si zvýší množství zapsaných dat 32 krát? To by pak už dávalo smysl. Několikanásobně více zápisů je kvůli větší režii zfs a COW + třicetinásobně kvůli špatně nastaveným recordsize.
To doporučení nastavit si asfit na 12 jsem našel jako radu na více různých místech, pro zvýšení výkonu databáze. A při records size 4K nebo 8K to částečně opravdu pomohlo. Stále byl ale výkon menší než s ext4, prostě nový výkonnější stroj se zfs a SSD disky nezastal stejný výkon (množstí uložených logovacích záznamů) jako starší stroj magnetickými diska a ext4.
-
V principu ano, pokud chcete potlačit write amplification tak je nejlepší mít recordsize stejný jako ashift. Ale někdy je lepší to mít vyšší a potlačit to kompresí. U recordsize 128kB pokud změníte jeden 4kB blok tak se na disk zapíše na jiné místo modifikovaných 128kB, to může být důvod toho množství zápisu ve smartu.
Jen pro zajímavost: kolik vám šetří ta deduplikace? Vzhledem k tomu že se to deduplikuje po blocích a Vy máte bloky 4kB velké tak deduplikační tabulka bude hodně velká a je otázka jestli se vyplatí.
Pokud dáte zpool status -D tak ve výpisu bude podobný řádek:
dedup: DDT entries 188696705, size 601B on disk, 194B in core
Když vynásobíte počet záznamů velikostí jednoho záznamu (on disk, in core) tak dostanete kolik zabírá deduplikační tabulka na disk, respektivě v ram.
Tohle může být příčina toho že je to pomalé. Je možné že deduplikační tabulka zabírá zbytečně moc ram která by se dala využít efektivněji pro db. A při každém zápisu bloku se musí upravovat počty referencí v tabulce což hodně sníží výkon zápisu.
Ještě bych prověřil jak je nastavená velikost bloku na nvme disku. Většinou nvme disky emulují 512B sektor (kvůli winXP) a to stojí také výkon. Je nesmysl aby aplikace pracovala se sektory o velikosti 4KB aby se pak překládali na 512B sektory které disk tvrdí že používá a přitom interně pracoval opět s 4KB.
Když to vezmu osobně tak pokud připravuji server pro db tak:
1, nastavím na nvme velikost sectoru na 4kB https://wiki.archlinux.org/title/Advanced_Format#Setting_native_sector_size (https://wiki.archlinux.org/title/Advanced_Format#Setting_native_sector_size)
2, zpool vytvářím s ashift 12 a parametry (předpoklad je že /boot je na ext4 a ne na zfs):
dnodesize=auto (jinak pokud velikost adresáře překroší 512B tak to uloží jako nový blok)
redundant_metadata = most (omezím počet zápisů na metadata)
compression=zstd
xattr=sa (ukládá rozšířené atributy přímo k souboru, zvyšuje výkon při použití např selinuxu)
atime=off
primarycache nechávám zaplou na all
3, mysql dataset vytvářím s recordsize=16k. Mám to ozkoušené že to poskytuje nejlepší výkon a je to doporučováno pro db i v dokumentaci zfs.
4, u mysql nejvíc pomůže vypnout doublewrite, ale je možné zapnout ještě další optimalizace. Docela pěkně to má popsané letsencrypt když migroval na zfs: https://github.com/letsencrypt/openzfs-nvme-databases#mariadb-settings (https://github.com/letsencrypt/openzfs-nvme-databases#mariadb-settings)
-
Díky za rady. Ta databáze s recordsize 8K ukazuje compressratio 1.67x
dedub je u databáze vypnuto, těch několik GB co to maximálně vezme v paměti s těch 64 nebo 128 GB paměti ztratí.
Bohužel většinu rad ohledně mysql nemůžu udělat, protože používám pořád myIsam.
Kdybych tak změnou dosáhl desetinásobné zlepšení, tak zvýším životnost disku z 1 roku na 10 což je dostatečné. Ale rozdíl oproti ext4 je pořád řádový, což by mohlo vysvětlovat to zpomalení.
Napadá mne, jestli to nemůže být třeba i tím, že SSD disky se tváří že mají block jen 512 a u ext4 512 bajtů opravdu započítají, když se v tabulce provede update jedné hodnoty. Rovněž přidání záznamu do méně košaté tabulky by se také mohlo vejít do 512bytů i když ve skutečnosti zapíše SSD disk 4K.
-
To je možné. Ale jak říkám, ssd neumí upravit jen konkrétní bity ale musí přepsat celou buňku. Takže i když na to ext4 zapíše 512B tak se na pozadí provede nejspíš mnohem větší zápis, jen s tím rozdílem že do smartu se započítá těch 512B.
-
To je možné. Ale jak říkám, ssd neumí upravit jen konkrétní bity ale musí přepsat celou buňku. Takže i když na to ext4 zapíše 512B tak se na pozadí provede nejspíš mnohem větší zápis, jen s tím rozdílem že do smartu se započítá těch 512B.
Souhlasím. Já jen, hledám co dalšího může vysvětlit ten obrovský rozdíl. Tohle by mohlo vysvětlit v průměru třeba dojnásobné množství zápisů, takže na samotné méně efektivní fungování ZFS zbývá stále velká část. (největší část je samozřejmě to nevhodně nastavené recordsize )
-
To je možné. Ale jak říkám, ssd neumí upravit jen konkrétní bity ale musí přepsat celou buňku. Takže i když na to ext4 zapíše 512B tak se na pozadí provede nejspíš mnohem větší zápis, jen s tím rozdílem že do smartu se započítá těch 512B.
Souhlasím. Já jen, hledám co dalšího může vysvětlit ten obrovský rozdíl. Tohle by mohlo vysvětlit v průměru třeba dojnásobné množství zápisů, takže na samotné méně efektivní fungování ZFS zbývá stále velká část. (největší část je samozřejmě to nevhodně nastavené recordsize )
Tohle zalezi disk od disku, ty lepsi delaji kompresi a zapisuji na konec volneho bloku, v podstat neco jako zurnal / SMR (a hlidaji si co kam dali), nema smysl kvuli male zmene mazat/zapisovat stejna data.
Proto je lepsi, kdyz ma SSD 512B sektory nez 4Kn, i kdyz FS vrstva tam bude cpat 8x512 pro kazdou zmenu v clusteru.
-
Díky všem za příspěvky. Můj závěr tedy je, že ZFS není vhodné na hodně zapisující databáze, kvůli výkonu i kvůli mnohonásobně většímu opotřebování disků. I když bych se měl při pořízení kvalitního serverového SSD disku a recordsize=4k teoreticky vlézt do jeho životnosti, pravděpodobnost problémů si tím zbytečně zvyšuji.
Nemluvě o tom, že to ta databáze má podle mé zkušenosti několikanásobně menší výkon. Myslím tím rychlost složitější dotazů.
Tedy nezbývá než se pro případ databází se vrátit k RAD1+LVM2+ext4 . Snapshoty to umí též (jen po dobu zálohování - po krátkou dobu mi snížený výkon a větší opotřebení nevadí, navíc zálohy se provádí v noci při minimálním provozu), jinak databázi zálohuji pomocí replikace, snapshot je potřeba jen pro nahození replikace, tedy třeba jednou za půl roku. Opotřebení disků mnohonásobně menší, výkon zase větší. Co mne ale vrtá hlavou je to, že spousta fandů si těchto mnohdy podstatných negativ ZFS vůbec nevšimlo, takže o tom na internetu nenajdeme téměř žádnou zmínku.
-
jako... nemám mnoho co dodat, jenom si tady tak googlím. Páchám metavýzkum od stolu.
Máte pravdu, že na první pokus MySQL ZFS SSD (https://www.google.com/search?q=MySQL+ZFS+SSD) mi google hodí na prvních dvou místech oslavné (https://www.percona.com/blog/mysql-zfs-performance-update/) ódy (https://shatteredsilicon.net/blog/2020/06/05/mysql-mariadb-innodb-on-zfs/) na tenhle nápad = že ZFS je pro tohle použití naprosto boží. Výkonově podobné jako Ext4, možná nepatrně slabší - ale to pohodlí. A jak přesně na to.
Pokud čtu mezi řádky, tak mi tam chybí posouzení právě "write amplification". Je tam hodnocen jenom výkon pro vyšší=uživatelské vrstvy a pak také geniální features.
Teprve když přitlačím, třeba MySQL ZFS SSD write amplification (https://www.google.com/search?q=MySQL+ZFS+SSD+write+amplification), dostanu (odkaz na toto vlákno a) dva (https://www.mail-archive.com/stable@freebsd.org/msg00098.html) odkazy (https://blog.erben.sk/2022/03/08/do-not-use-consumer-ssd-with-zfs-for-virtualization/) k věci.
Prostě jste průkopník, přišel jste si na to sám :-( Respect.
Ohledně ZFS vidím pár ladících parametrů, jako velikost bloku a nějaké další věci. Ty oslavné ódy to popisují podrobně. A přesto to nestačí. Často v souvislosti se ZFS čtu zmínky o letmé kompresi - ale mám pocit, že letmá komprese v režii ZFS může write amplification na SSD jedině zhoršit, protože IMO problematizuje pracně vyladěné zarovnání na velikost bloku. Taky jsem si všiml v souvislosti s MySQL zmínek o IO scheduleru - že raději deadline nebo ještě noop než CFQ. Ale toto by podle mého taky nemělo mít vliv na write amplification (i když... přeskupování transakcí ve frontě... jeden nikdy neví jistě.)
Ty dvě "kapitoly z černé kroniky" zmiňují fallback na Ext4, stejně jako Vy. Jsou ale i jiné FS - jako alternativa k Ext4 je často zmiňován XFS, a někdy taky BTRFS. Bohužel většina pojednání na toto téma je stará, cca 2012. Ovšem od té doby Ext4 prodělal jakousi regresi po velkém overhaulu někdy v době 4.x (ze které je snad už venku), naopak starobylý XFS se dočkal poctivé průběžné údržby a momentálně si ve srovnání s Ext4 zřejmě vede poměrně slušně (https://scalegrid.io/blog/xfs-vs-ext4-comparing-mongodb-performance-on-aws-ec2/). BTRFS (https://btrfs.wiki.kernel.org/index.php/Main_Page) pod MySQL zřejmě není dobrý nápad (https://www.percona.com/blog/taking-a-look-at-btrfs-for-mysql/) (doporučuji i diskusi pod článkem) - údajně BTRFS má mizernou průchodnost pro "random přepis", což je přesně případ databází...
Hehe kde jsou ty časy, kdy se tablespace dával na holé blokové zařízení, bez FS. Hm - koukám (https://www.google.com/search?q=MySQL+tablespace+on+raw+device), že MySQL toto taky zatím ještě umí :-) Ale nevýhody zřejmě převažují nad výhodami.