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

[_Tomáš_]

ještě malý tip, v případě mysql a innodb je vždy nejrychlejší nejprve debugovat přímo O_DIRECT zápis s 16KB, je dobré vyzkoušet více kernelů, zejména po 4.8 byly nějaké regrese na ssd/nvme. Výkonnost mysql to pak reflektuje většinou velice dobře, výjimkou je ext4, který je dost šíleny pro databáze a měření. Pokud máš tak velké rozdíly proti ext4, máš zfs nevhodně nastavený, projdi nastavení znovu, najdi mikrobench, který ti dovolí rychleji zkoušet různé varianty

[Reklama]

[xsouku04]

ještě malý tip, v případě mysql a innodb je vždy nejrychlejší nejprve debugovat přímo O_DIRECT zápis s 16KB, je dobré vyzkoušet více kernelů, zejména po 4.8 byly nějaké regrese na ssd/nvme. Výkonnost mysql to pak reflektuje většinou velice dobře, výjimkou je ext4, který je dost šíleny pro databáze a měření. Pokud máš tak velké rozdíly proti ext4, máš zfs nevhodně nastavený, projdi nastavení znovu, najdi mikrobench, který ti dovolí rychleji zkoušet různé varianty

Jak pomocí microbench debugovat O_DIRECT u zfs jsem nepochopil ani nikde nenašel.  Ale myšlenka že testovat raději přímo výkon disku než výkon databáze je dobrá, protože je to podstatně snandnější a rychlejší.

Testoval jsem pomocí příkazu pro testování náhodného zápisu bloků 4KB:  (způsob jak testovat jsem převzal z blogu zde https://martin.heiland.io/2018/02/23/zfs-tuning/)

Kód: [Vybrat]

fio --filename=test --sync=1 --rw=randwrite --bs=4k --numjobs=1 --iodepth=4 --group_reporting --name=test --filesize=10G --runtime=300 && rm test
Nevím proč, ale největší výkon naměří na obyčejném disku (ne SSD) se ZFS, když mám recordsize=4K. A to.
write: IOPS=1137, BW=4550KiB/s (4659kB/s)(1333MiB/300003msec); 0 zone resets
Je to několikanásobně lepší výsledek než při všem ostatním.
To stejné při defaultním recordsize=128K
write: IOPS=280, BW=1121KiB/s (1148kB/s)(328MiB/300001msec); 0 zone resets
Pokud to stejné pustím na stejném disku ale s ext4, tak dostanu
write: IOPS=277, BW=1109KiB/s (1135kB/s)(325MiB/300088msec); 0 zone resets

Pokud to stjené pustím na SSD disku na zfs s recordsize=4K tak je výsledek pět cca stejný
write: IOPS=288, BW=1154KiB/s (1182kB/s)(338MiB/300006msec); 0 zone resets

Pokud ale nastavím defalutních recordsize=128K pak se ZFS s SSD diskem zmůže jen na cca poloviční výkon
write: IOPS=127, BW=510KiB/s (522kB/s)(149MiB/300001msec); 0 zone resets

Bohužel zkusit SSD disk bez s ext4 nemohu.

Testoval jsem ale svůj nový domácí SSD disk na ext4 nvme
write: IOPS=550, BW=2200KiB/s (2253kB/s)(645MiB/300001msec); 0 zone resets

Z toho vůbec nejsem chytrý. Vypadá to jako by pro zápis malých bloků nebyly SSD vůbec nějak výrazně rychlejší?
Jak si vysvětlit tu rychlost ZFS s běžným diskem a 4KB recordsize?

[_Tomáš_]

Jak pomocí microbench debugovat O_DIRECT u zfs jsem nepochopil ani nikde nenašel.  Ale myšlenka že testovat raději přímo výkon disku než výkon databáze je dobrá, protože je to podstatně snandnější a rychlejší.

Kód: [Vybrat]

fio --direct=1 --ioengine=libaio --bs=16k ...

Např. konkrétně:

Kód: [Vybrat]

fio --name=randrw --rw=randrw --direct=1 --ioengine=libaio --bs=16k --numjobs=8 --rwmixread=80 --size=10G --runtime=1800 --group_reporting

nepoužívej iodepth a ani sync, pro mysql potřebuješ měřit O_DIRECT. O_SYNC znamená použití kernel cache při zápisu a volání fsync(2) po každém blocku, tj. dva syncally, to měříš něco, co mysql nepoužívá, takže výsledky nejsou relevantní.

Nepíšeš jak máš nastavený zfs/ext4, takže těžko soudit z výsledků tvého měření.

[xsouku04]

Pokud onen test dělám na zfs výsledek je tohle:

Kód: [Vybrat]

fio --name=randrw --rw=randrw --direct=1 --ioengine=libaio --bs=16k --numjobs=1 --rwmixread=80 --size=10G --runtime=300 --group_reporting
randrw: (g=0): rw=randrw, bs=(R) 16.0KiB-16.0KiB, (W) 16.0KiB-16.0KiB, (T) 16.0KiB-16.0KiB, ioengine=libaio, iodepth=1
fio-3.12
Starting 1 process
randrw: Laying out IO file (1 file / 10240MiB)
fio: looks like your file system does not support direct=1/buffered=0
fio: destination does not support O_DIRECT
randrw: No I/O performed by libaio, perhaps try --debug=io option for details?
fio: pid=14301, err=22/file:filesetup.c:701, func=open(randrw.0.0), error=Invalid argument


Run status group 0 (all jobs):

Jinak nastavení zfs mám:

Kód: [Vybrat]

zfs get all /ovps/clondbn3
NAME           PROPERTY              VALUE                  SOURCE
ovps/clondbn3  type                  filesystem             -
ovps/clondbn3  creation              Tue Jan  5 11:00 2021  -
ovps/clondbn3  used                  177G                   -
ovps/clondbn3  available             170G                   -
ovps/clondbn3  referenced            177G                   -
ovps/clondbn3  compressratio         1.00x                  -
ovps/clondbn3  mounted               yes                    -
ovps/clondbn3  quota                 none                   default
ovps/clondbn3  reservation           none                   default
ovps/clondbn3  recordsize            4K                     local
ovps/clondbn3  mountpoint            /ovps/clondbn3         default
ovps/clondbn3  sharenfs              off                    default
ovps/clondbn3  checksum              on                     default
ovps/clondbn3  compression           off                    default
ovps/clondbn3  atime                 off                    inherited from ovps
ovps/clondbn3  devices               on                     default
ovps/clondbn3  exec                  on                     default
ovps/clondbn3  setuid                on                     default
ovps/clondbn3  readonly              off                    default
ovps/clondbn3  zoned                 off                    default
ovps/clondbn3  snapdir               hidden                 default
ovps/clondbn3  aclinherit            restricted             default
ovps/clondbn3  createtxg             544563                 -
ovps/clondbn3  canmount              on                     default
ovps/clondbn3  xattr                 on                     default
ovps/clondbn3  copies                1                      default
ovps/clondbn3  version               5                      -
ovps/clondbn3  utf8only              off                    -
ovps/clondbn3  normalization         none                   -
ovps/clondbn3  casesensitivity       sensitive              -
ovps/clondbn3  vscan                 off                    default
ovps/clondbn3  nbmand                off                    default
ovps/clondbn3  sharesmb              off                    default
ovps/clondbn3  refquota              none                   default
ovps/clondbn3  refreservation        none                   default
ovps/clondbn3  guid                  15047711894469677623   -
ovps/clondbn3  primarycache          all                    default
ovps/clondbn3  secondarycache        all                    default
ovps/clondbn3  usedbysnapshots       128K                   -
ovps/clondbn3  usedbydataset         177G                   -
ovps/clondbn3  usedbychildren        0B                     -
ovps/clondbn3  usedbyrefreservation  0B                     -
ovps/clondbn3  logbias               latency                default
ovps/clondbn3  dedup                 off                    default
ovps/clondbn3  mlslabel              none                   default
ovps/clondbn3  sync                  standard               default
ovps/clondbn3  dnodesize             legacy                 default
ovps/clondbn3  refcompressratio      1.00x                  -
ovps/clondbn3  written               10.2G                  -
ovps/clondbn3  logicalused           177G                   -
ovps/clondbn3  logicalreferenced     177G                   -
ovps/clondbn3  volmode               default                default
ovps/clondbn3  filesystem_limit      none                   default
ovps/clondbn3  snapshot_limit        none                   default
ovps/clondbn3  filesystem_count      none                   default
ovps/clondbn3  snapshot_count        none                   default
ovps/clondbn3  snapdev               hidden                 default
ovps/clondbn3  acltype               off                    default
ovps/clondbn3  context               none                   default
ovps/clondbn3  fscontext             none                   default
ovps/clondbn3  defcontext            none                   default
ovps/clondbn3  rootcontext           none                   default
ovps/clondbn3  relatime              off                    default
ovps/clondbn3  redundant_metadata    all                    default
ovps/clondbn3  overlay               off                    default


[xsouku04]

Tak jsem zjistil, že zfs umí O_DIRECT až od verze 0.80 . Zato stable debian buster používá (modinfo zfs | grep version) 0.7.12 . Vypadá ale, že instalovat nejaktuálnější verzi je jednoduché, stačí přidat repozitář buster-backports .
https://packages.debian.org/buster-backports/zfs-dkms
Vzhledem k tomu, že ze ZFS tak dlouho bez onoho DIRECT obešle, je ten O_DIRECT opravdu důležitý? Nikde jsem nenašel článek o tom jak je ZFS kvůli absenci O_DIRECT nevhodný pro databáze.
Zde jsou nějaké informace k O_DIRECT na zfs. https://github.com/openzfs/zfs/pull/7823

Vzhledem k  tomu, že jsem zkusil už skoro vše, tak zkusit novější verzi ZFS dává smysl.

[Reklama]

[_Tomáš_]

Mysql to u innodb používá, viz "To take full advantage of this feature, an innodb_flush_method setting of O_DIRECT is recommended. " na https://dev.mysql.com/doc/refman/5.7/en/innodb-disk-io.html

Řada databází používá O_DIRECT, protože si sami řeší buffer a nepotřebují, aby to fs či OS buffer vedle nich, stejně tak třeba innodb používá doublewrite buffe a je schopná se dosta z chyb, které mohou vzniknout při neúspěšném zápisu O_DIRECT (nemáš totiž jistotu, že data doputovala na disk).

Řešíš tady výkonnost mysql nad zfs, tam je tahle funkce velice důležité, protože to výrazně tu výkonnost ovlivňuje, ale chce to měřit, měřit a měřit. Jiná databáze to bude mít trochu jinak, chceš-li z toho vytlačit víc, musíš si nastudovat jak se chová a jak jí práci ulehči a hlavně jak tu práci neduplikovat.

Různé FS se chovají různé, xfs má konstatní čas pro zápis, ač je pomalejší, je takhle pomalé vždy a nemá občasné pauzy, jak to má ext4. ZFS zase poskytuje silnou podporu pro COW, snapshoty, replikace, snadnějí správu a lepší kontrolu nad samotnými block device, nepotřebuješ pak používat drahé RAID pole. Důvody, výhody a cíle bys měl mít ujasněné dopředu, pak je možné ladit.

[Tomáš Jura]

Důvodem je to, že zápisy pro (OLTP) databáze jsou náhodné, což v případě copy-on-write strategie pro data způsobuje že logicky souvislé soubory jsou nesouvisle roztrhány na disku. Logické sekvenční čtení (=čtení souvislá řada bloků) pak není vůbec fyzicky sekvenční a je spíše náhodné lítání hlavičky po disku podle toho kde jsou zrovna data zapsána. A výkon náhodného čtení/zápisu z disku je řádově nižší než sekvenční čtení/zápis.

[xsouku04]

Důvodem je to, že zápisy pro (OLTP) databáze jsou náhodné, což v případě copy-on-write strategie pro data způsobuje že logicky souvislé soubory jsou nesouvisle roztrhány na disku. Logické sekvenční čtení (=čtení souvislá řada bloků) pak není vůbec fyzicky sekvenční a je spíše náhodné lítání hlavičky po disku podle toho kde jsou zrovna data zapsána. A výkon náhodného čtení/zápisu z disku je řádově nižší než sekvenční čtení/zápis.

Platí to i u SSD disků?

[_Tomáš_]

Důvodem je to, že zápisy pro (OLTP) databáze jsou náhodné, což v případě copy-on-write strategie pro data způsobuje že logicky souvislé soubory jsou nesouvisle roztrhány na disku. Logické sekvenční čtení (=čtení souvislá řada bloků) pak není vůbec fyzicky sekvenční a je spíše náhodné lítání hlavičky po disku podle toho kde jsou zrovna data zapsána. A výkon náhodného čtení/zápisu z disku je řádově nižší než sekvenční čtení/zápis.

Platí to i u SSD disků?

neplatí, u ssd není již takový propad při náhodném zápisu/čtení, naopak sám ssd data rovnoměrně rozděluje po celém disku i v případě zápisu souvislých bloků a nejsem s to tohle ovlivnit, pač se zapisuje do logické a nikoliv fyzické struktury.

Je to i nesmyslu z pohledu jak vlastně databáze funguje, běžně dělá malé inserty a u nich nezajistím souvislé bloky dat, od dob, kdy databáze nepoužívají raw device, ale nějaký FS, je fragmentace jejich dat na pořadu dne, dnes již většinou není potřeba výrazně řešit. Běžné plotnové disky mají AU (alokační jednotka) 4kb, zatímco innodb ukládá data po 16kb, dochází tedy k fragmentaci již i jednotlivých ukládaných bloků, nějaké snahy jako dělat až 4MB předalokaci tady jsou a většinou i fungují, pořád ale platí, že i na plotnových discích se musí na OLTP databázích občas spustit kompakce. Copy on write FS (COW FS) pro databáze v tom nedělají velký rozdíl, innodb samo vždy přepisuje/připisuje 16kb bloky dat, pokud se zachovají stejně velké bloky u na straně FS, je to v pořádku. U hodně specializovaných databází mohu mít pro jednotlivé tabulky specializované disky, pak se data ukládají souvisle, takové řešení jsem ale už dlouho neviděl, nebylo potřeba.

[Tomáš G.]

Z toho vůbec nejsem chytrý. Vypadá to jako by pro zápis malých bloků nebyly SSD vůbec nějak výrazně rychlejší?

Nedaří se mi to najít, ale odhadem tak před dvěma lety jsem někde narazil na diskusi, na 80% tady na Rootu, kde si tazatel stěžoval, že při práci s velkým množstvím malých souborů mu rychlost SSD klesá snad i pod úroveň plotových disků.

Shodou okolní jsem ve stejné době pozoroval totéž. SSD stejné značky. Tazatel tam měl Linux, já si toho všiml na novém PC s Windows 10 u zákazníka, když jsem rozbaloval zazipovanou instalačku Oracle klienta.

[Tomáš G.]

Z toho vůbec nejsem chytrý. Vypadá to jako by pro zápis malých bloků nebyly SSD vůbec nějak výrazně rychlejší?

Nedaří se mi to najít...

Tak bylo to tady:
https://forum.root.cz/index.php?topic=21870.0

[xsouku04]

Z toho vůbec nejsem chytrý. Vypadá to jako by pro zápis malých bloků nebyly SSD vůbec nějak výrazně rychlejší?

Nedaří se mi to najít...

Tak bylo to tady:
https://forum.root.cz/index.php?topic=21870.0

Díky moc. To bude přesně ono. Tedy důvod je ten že dnešním levným SSD diskům při delším zápisu za chvilku dramaticky klesne (až třicetinásobně) rychlost, protože dojde rychle zápisová cache. Při testech je to vidět. SSD disky co jsem kupoval tak před 8 lety byly sice v té době mnohonásobně dražší, ale i když měli papírově rychlosti úplně stejné jako dnes, tohle zpomalení neměli.  Rychlost zápisu byla po celou dobu konstantní a fungují nám na serverech stále k plné spokojenosti. Proto jsem neviděl důvod, proč kupovat něco jiného. Prostě dnešní low end SSD disky nejsou vhodné na déle trvající zápisy. Což ale u běžného použití na starém notebook není úplně typické použití (větší instalace se dělá jednou a na filmy je ssd škoda, když mohu použít původní disk) a proto to až tak nevadí.
Dnes je asi lepší koupit nějaké lepší M.2 disky, které nejenom že by měly být zase několikanásobně rychlejší, ale rychlost by jím neměla při déle trvajícím zápisu výrazně klesat. Bohužel tyto vlastnosti ale prodejci neinzeruji?
 ZFS je zdá se nevinně, tam při dobrém vyladění máte rychlosti podobné jako u ext4, při špatném třeba poloviční, ale není to násobek.

[xsouku04]

Ještě dodám, že ony problémové disky jsou Kingston Now A400, 2,5" - 480GB
https://www.czc.cz/kingston-now-a400-2-5-480gb/213704/produkt
Zkusil jsem začít používat trim, ale výsledek byl, že ono třicetinásobné zpomalení začalo být více náhodně. Celková rychlost ale byla zdá se poté trochu lepší. Nicméně databáze si nemůže dovolit zničehonic třicetinásobně pomalejší zápis. A pokud je to náhodné, je to snad ještě horší, protože i při menším množství zapisovaných dat se tohle zpomalení může vyskytnout v tu nejméně vhodnou chvilku.

[messagebus]

Bohužel tyto vlastnosti ale prodejci neinzeruji?

Ale inzeruji a to zcela zretelne Pro podobny typ zateze je treba vybirat mezi disky oznacenymi jako "serverove", "enterprise", "pro datova centra" apod. (a taky jim pripadne zajistit radne chlazeni.)
https://www.czc.cz/pevne-disky-do-serveru/produkty?q-c-0-f_94358671=sSSD
https://www.mironet.cz/pevne-disky-a-ssd+fc14401/?pn11473%5B%5D=Intern%C3%AD&pn11038%5B%5D=SSD&pn11037%5B%5D=Intern%C3%AD%20-%20Server
atd.

Mimochodem, hned druha reakce v tomto vlakne byla "Co je to za SSD?". Takze tak.

[xsouku04]

Bohužel tyto vlastnosti ale prodejci neinzeruji?

Ale inzeruji a to zcela zretelne Pro podobny typ zateze je treba vybirat mezi disky oznacenymi jako "serverove", "enterprise", "pro datova centra" apod. (a taky jim pripadne zajistit radne chlazeni.)
https://www.czc.cz/pevne-disky-do-serveru/produkty?q-c-0-f_94358671=sSSD
https://www.mironet.cz/pevne-disky-a-ssd+fc14401/?pn11473%5B%5D=Intern%C3%AD&pn11038%5B%5D=SSD&pn11037%5B%5D=Intern%C3%AD%20-%20Server
atd.

Mimochodem, hned druha reakce v tomto vlakne byla "Co je to za SSD?". Takze tak.

Nikde nepíší o tom, že při použití trim reálná rychlost zápisu náhodně skáče mezi uváděnou rychlostí a rychlstí  30 krát nižší. A pokud trim není použit tak plná rychlost zápisu vydrží jen v desítkách vteřin a pak je třicetinásobně nižší. Tohle je podstatný údaj totiž i pro běžné uživatele bez serveru, i když i vzhledem k ceně se může rozhodnout že  mu to nevadí.
Když SSD disky začínali, koupil jsem i nějaké profi serverové, ale byli více poruchové než ty obyčejné Kingstony, které bez problému fungují doposud.