ZFS + mysql ničí SSD disky

ZFS + mysql ničí SSD disky
« kdy: 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?


RDa

  • *****
  • 1 997
    • Zobrazit profil
    • E-mail
Re:ZFS + mysql ničí SSD disky
« Odpověď #1 kdy: 17. 08. 2022, 01:34:55 »
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?

robin martinez

  • *****
  • 1 031
  • Have you hugged your toilet today?
    • Zobrazit profil
    • Null Storage
    • E-mail
Re:ZFS + mysql ničí SSD disky
« Odpověď #2 kdy: 17. 08. 2022, 06:28:32 »
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
One machine can do the work of fifty ordinary men. No machine can do the work of one extraordinary man.

I do Linux, Hardware and spaghetti code in PHP, Python and JavaScript

Re:ZFS + mysql ničí SSD disky
« Odpověď #3 kdy: 17. 08. 2022, 09:12:57 »
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ší.

Re:ZFS + mysql ničí SSD disky
« Odpověď #4 kdy: 17. 08. 2022, 09:30:33 »
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/
Citace
  • 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í.


Re:ZFS + mysql ničí SSD disky
« Odpověď #5 kdy: 17. 08. 2022, 09:57:22 »
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/...

Re:ZFS + mysql ničí SSD disky
« Odpověď #6 kdy: 17. 08. 2022, 11:59:21 »
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í.

k3dAR

  • *****
  • 2 438
  • porad nemam telo, ale uz mam hlavu... nobody
    • Zobrazit profil
    • E-mail
Re:ZFS + mysql ničí SSD disky
« Odpověď #7 kdy: 17. 08. 2022, 13:15:17 »
[...]
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 ;-)

Re:ZFS + mysql ničí SSD disky
« Odpověď #8 kdy: 17. 08. 2022, 13:24:54 »
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.

Re:ZFS + mysql ničí SSD disky
« Odpověď #9 kdy: 17. 08. 2022, 13:35:51 »
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.

Re:ZFS + mysql ničí SSD disky
« Odpověď #10 kdy: 17. 08. 2022, 14:25:54 »
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.

Re:ZFS + mysql ničí SSD disky
« Odpověď #11 kdy: 17. 08. 2022, 15:45:39 »
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.
« Poslední změna: 17. 08. 2022, 15:52:15 od xsouku04 »

Re:ZFS + mysql ničí SSD disky
« Odpověď #12 kdy: 17. 08. 2022, 16:50:40 »
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

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

Re:ZFS + mysql ničí SSD disky
« Odpověď #13 kdy: 17. 08. 2022, 19:08:26 »
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.

Re:ZFS + mysql ničí SSD disky
« Odpověď #14 kdy: 17. 08. 2022, 21:38:06 »
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.