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

Přecházíme nyní z OpenVZ ext4 na lxc ZFS. Výhody ZFS jsou zřejmé jako snapshoty a tím snadná záloha a klonování.
Ale nyní jsem narazil i na podstatnou nevýhodu a to podstatně nižší výkon.

Jedná se o databázovou aplikaci, která snímá diagnostická data a zapisuje je do databáze.  Je tam tedy velké množstvím inzertů a podobně velké množství updatů, kdy se nasbíraná data vyhodnocují. Po přesunu této aplikace na lxc/ZFS co používá SSD byl výkon oproti starému stroji s rotačním diskem cca poloviční. Co mne ale zaráží je, že jiné kontejnery začaly bezdůvodně ztrácely rtp pakety.
Očekával jsem tak cca čtyřnásobné zvýšení výkonu (kvůli použití SSD) a místo toho se rychlost snížila.

U Openvz se v podstatě nikdy nestávalo, že by přetížení jednoho kontejneru vyvolávalo podstatné problémy v jiném, lxc je o tolik horší? Zkoušeli jsme to stejné ještě na jiném stroji, abychom vyloučili chybu hardwaru, ale výsledek byl velmi obdobný. Dále jsme omezili paměť pro ZFS aby jsme se s jistotou vyhnuli možnému swapování.  Zkoušeli jsme též použít jak inodb tak myISAM. MyISAM je pro nás o něco málo výkonnější, ale žádný podstatný rozdíl.  Jediné co mělo výrazný vliv, je snížení parametru recordsize na 4K.  Např. viz návod https://blog.programster.org/zfs-record-size . Tím se dalo docílit podobné rychlosti jako na starém počítači s rotačními disky.  Stále mi ale nejde do hlavy, jak je možné, že se při využití SSD disků nedostavilo žádné zrychlení. Nečekal jsem že bude ZFS rychlejší, ale rozdíl jsme čekal podstatně menší. Máte někdo s tím zkušenost? Takto si připadám, že co se rychlosti a spolehlivosti týče je to krok zpět. Samozřejmě ZFS může být lepší co se týče integrity dat, ale pokud by to mělo znamenat takto výrazné snížení rychlosti, je otázka, jestli to stojí za to. A pokud je to jen analýza ne úplně důležitých dat, je lepší se ZFS úplně vyhnout?

Máte s tím někdo zkušenost?
« Poslední změna: 16. 03. 2021, 17:05:17 od xsouku04 »


by_cx

  • ****
  • 290
    • Zobrazit profil
    • E-mail
Ja bych se na ZFS u databaze vybodnul. Da se to vytunit ale lepsi nez default ext4 to asi nebude.

https://www.percona.com/blog/2018/02/16/why-zfs-affects-mysql-performance/

Co je to za SSD?

lets encrypt se moc pěkně rozepsali o tom, jak ladili zfs pro mariadb, začti se https://github.com/letsencrypt/openzfs-nvme-databases a pak se případně zeptej co ti není jasné, co jsi zkoušel a jaké jsi měl výśedky.

openvz má nastavení určité limity a priority přes cgroup, lxc je čistá kniha, musíš to tam nastavit a vyřešit sám jinak se ti může a bude stávat, že jeden vytíží celý server a ostatní si nemusí vrznout.

Nemá ZFS něco na vypnutí copy-on-write, tak jako se doporučuje chattr +C u databází na btrfs?


Nemá ZFS něco na vypnutí copy-on-write, tak jako se doporučuje chattr +C u databází na btrfs?

nemá, zfs neumí in-place zápis. Používá se ale stejný block size (record size u zfs) jako je page size u databáze, která zapisuje, pak každý zápis skončí v novém blocku a není potřeba dělat žádné kopírování přepisovaného blocku.

V jaké topologii jsou disky? Obecně více mirrorů je na IOPS lepší než jeden raidz.

Je zaplá komprese? Komprese není na zatížení CPU poznat a u DB dociluje kompresního poměru většinou víc než 2 a to už je na výkonu poznat

Zkuste nastavit hodnotu recordsize 16kB. 4KB jsou málo, velikost stránky v mysql je 16kB. Navíc počítám že ashift je nastavený na 12, tedy nejmenší velikost bloku je 4kB a pokud je i recordsize 4kB tak komprese už nemůže ten blok zmenšit a proto se nepoužívá a tím se ztrácí výkon.

Pokud je dost RAM tak bych používal jako engine InnoDB a nastavil dost velký innodb buffer a pro ten dataset s mysql nastavil primarycache=metadata aby nedocházelo k dvojitému cachování v mysql a v zfs.

Protože u zfs nemůže nastat partial write tak se může v mysql vypnout doublewrite, to také přinese nějaký nárust výkonu.

Tohle co jsem uvedl tak by mělo výkonově dostat zfs blízko k výkonu ext4. Jen ještě upozorním že změny hodnot jako je komprese a nebo recordsize se aplikují jen na nová data takže pro změnu existujících dat je ideální poslat si pomocí zfs send ten dataset do nového a pak ten nový jen namountovat na místo původního.

Co je to za SSD?

Jsou to běžné nejlevnější Kingstone ssd disky v raid 0.  Dříve s nejlevnějšími kingstone nebyly žádné problémy.

pool: ovps
state: ONLINE
scan: scrub repaired 0B in 0h20m with 0 errors on Sun Mar 14 00:44:25 2021
config:

NAME                                            STATE     READ WRITE CKSUM
ovps                                            ONLINE       0     0     0
mirror-0                                      ONLINE       0     0     0
ata-KINGSTON_SA400S37480G_50026B77839D2E97  ONLINE       0     0     0
ata-KINGSTON_SA400S37480G_50026B778397A84B  ONLINE       0     0     0

Ja bych se na ZFS u databaze vybodnul. Da se to vytunit ale lepsi nez default ext4 to asi nebude.

https://www.percona.com/blog/2018/02/16/why-zfs-affects-mysql-performance/

Zajímavý článek. Nechápu ale proč výkon pro median je nižší než 95 percentil a to jak  u ext4 tak u zfs. Median - update u zfs  má třetinový výkon oproti ext4.
Také nerozumím tomu,  proč dotyčný neuvádí jaký má nastavený recordsize, když ten má zásadní význam pro rychlost databází se zfs. Z popisků grafů na https://github.com/dotmanila/zfs-mysql/tree/master/base-results/zfs to vypadá, že nechal defaultních 128K. Kdyby nastavil  32K nebo menší, mohl mít zjevně výkon dvojnásobný. Taky to vypadá, že měl špatně nastavený logbias=throughput . Tedy jeho špatné výsledky je snad možné vysvětli neoptimálním nastavením. Zato moje špatné výsledky si vysvětlit neumím.  Očekával bych že bude mít zfs třeba o 20% nižší výkon, ale ne že bude několikanásobně pomalejší.
« Poslední změna: 17. 03. 2021, 09:15:01 od xsouku04 »

xsouku04: pokud chceš konkrétně poradit, tak sem musíš strčit konfiguraci databáze, zfs a sysctl, bez toho tě můžeme odkazovat pouze na obecné doporučení.

Bejvaly doby, kdy se databázím dával na hraní surový diskový oddíl (nebo disk), tzn. databáze nerada fungovala skrz filesystém :-) Jasně, uznávám, už je nové tisíciletí...

Za druhé, jste si jistý, že SSD je pro databázi přínosem? Zejména v situacích, kdy aplikace do DB především zapisuje, nejlíp spoustu drobných transakcí... Já flashkám nevěřím ani dobrýtro :-)

Ale pravda je, že pokud máte "po změně" nižší průchodnost na disky a zároveň vyšší zátěž CPU, tak to vážně vypadá spíš na vliv filesystému...

Dobrý den,

provozujeme SQL databáze většinou nad Proxmox ( KVM ) a využíváme ZFS. 

S výkonem MySQL jsme vcelku laborovali. Máme hodně malých transakcí což generuje malý datový tok, ale velké množství zápisů na disk tedy fsync.

V našem případě dramaticky pomohla změna nastavení
 - pro zápis změnit fsync  viz https://www.percona.com/blog/2018/02/08/fsync-performance-storage-devices/
 - Pro čtení jsme alokovali dostatek paměti tedy čtení nešlo skoro vůbec z disku.

Nakonec to stejně nebylo dostatečně výkonné a tak jsme přešli pro část dat k REDISu potažmo keydb.dev
a aplikačně pak v časových intervalech propisujeme do DB.

Testovali jsme jak levné tak dražší SSD disky.
Problémem u SATA/SAS byl většinou výkonnost RAID řadiče.

Nakonec jsme zvolili variantu NVMe s pro jistotu větším TBW jako je
https://www.alza.cz/corsair-force-series-mp510b-960gb-d5863484.htm

A aby jich šlo dát do standardního serveru více tak PCIe switch jako kupříkladu :
https://www.supermicro.com/en/products/accessories/addon/AOC-SLG3-2M2.php
https://www.supermicro.com/en/products/accessories/addon/AOC-SHG3-4M2P.php

Je to dva roky a mezi tím se HW raketově posunul.

Vřele mohu doporučit Davida Karbana. https://freelancing.eu/davidkarban/
Byl jsem u něj na školení a MySQL a následně nám pomáhal s laděním výkonu v kombinací s bezpečností dat.

V.

Dobrý den,

provozujeme SQL databáze většinou nad Proxmox ( KVM ) a využíváme ZFS. 

S výkonem MySQL jsme vcelku laborovali. Máme hodně malých transakcí což generuje malý datový tok, ale velké množství zápisů na disk tedy fsync.

V našem případě dramaticky pomohla změna nastavení
 - pro zápis změnit fsync  viz https://www.percona.com/blog/2018/02/08/fsync-performance-storage-devices/
 - Pro čtení jsme alokovali dostatek paměti tedy čtení nešlo skoro vůbec z disku.

Nakonec to stejně nebylo dostatečně výkonné a tak jsme přešli pro část dat k REDISu potažmo keydb.dev
a aplikačně pak v časových intervalech propisujeme do DB.

Testovali jsme jak levné tak dražší SSD disky.
Problémem u SATA/SAS byl většinou výkonnost RAID řadiče.

Nakonec jsme zvolili variantu NVMe s pro jistotu větším TBW jako je
https://www.alza.cz/corsair-force-series-mp510b-960gb-d5863484.htm

A aby jich šlo dát do standardního serveru více tak PCIe switch jako kupříkladu :
https://www.supermicro.com/en/products/accessories/addon/AOC-SLG3-2M2.php
https://www.supermicro.com/en/products/accessories/addon/AOC-SHG3-4M2P.php

Je to dva roky a mezi tím se HW raketově posunul.

Vřele mohu doporučit Davida Karbana. https://freelancing.eu/davidkarban/
Byl jsem u něj na školení a MySQL a následně nám pomáhal s laděním výkonu v kombinací s bezpečností dat.

V.
Díky za info.  Z odkazují je zřejmé, že rozdíl mezi běžným diskem a nejlevnější SSD sata diskem je podobně velký jako mezi SSD sata diskem a  SSD NVMe. Jak v rychlosti odezvy tak v množství dat za vteřinu. Normálnímu desktopu nebo aplikaci je to téměř jedno, ale v případě databáze to opět může být několikanásobné zrychlení. Tedy v případě náročnější databáze s větším počtem zápisů (to větší RAM neurychlí) to chce opravdu investovat do SSD NVMe

by_cx

  • ****
  • 290
    • Zobrazit profil
    • E-mail
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.

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ý.