Fórum Root.cz

Hlavní témata => Server => Téma založeno: xsouku04 16. 03. 2021, 17:02:52

Název: Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: xsouku04 16. 03. 2021, 17:02:52
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?
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: by_cx 16. 03. 2021, 21:14:27
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/
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: kotelgg 16. 03. 2021, 21:49:47
Co je to za SSD?
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: _Tomáš_ 16. 03. 2021, 22:08:28
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: Jakub Štech 16. 03. 2021, 23:08:12
Nemá ZFS něco na vypnutí copy-on-write, tak jako se doporučuje chattr +C u databází na btrfs?
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: _Tomáš_ 16. 03. 2021, 23:12:13
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: rokk42 17. 03. 2021, 08:21:51
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: xsouku04 17. 03. 2021, 09:05:10
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
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: xsouku04 17. 03. 2021, 09:13:21
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ší.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: _Tomáš_ 17. 03. 2021, 10:12:48
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í.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: František Ryšánek 17. 03. 2021, 10:37:12
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...
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: Václav Prokeš 17. 03. 2021, 12:41:32
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: xsouku04 18. 03. 2021, 10:48:45
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
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: by_cx 19. 03. 2021, 02:25:00
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: xsouku04 19. 03. 2021, 17:47:06
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ý.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: _Tomáš_ 19. 03. 2021, 21:18:13
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
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: xsouku04 21. 03. 2021, 00:03:17
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?
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: _Tomáš_ 21. 03. 2021, 00:48:48
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í.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: xsouku04 21. 03. 2021, 11:13:23
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
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: xsouku04 21. 03. 2021, 14:07:22
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: _Tomáš_ 21. 03. 2021, 14:52:13
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: Tomáš Jura 23. 03. 2021, 00:23:25
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: xsouku04 23. 03. 2021, 08:31:19
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ů?
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: _Tomáš_ 23. 03. 2021, 10:09:18
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: Tomáš G. 23. 03. 2021, 20:19:23
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: Tomáš G. 23. 03. 2021, 20:29:12
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
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: xsouku04 24. 03. 2021, 22:23:36
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: xsouku04 27. 03. 2021, 22:21:48
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: messagebus 28. 03. 2021, 10:14:09
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.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 (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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: xsouku04 28. 03. 2021, 22:20:45
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.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 (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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: messagebus 29. 03. 2021, 01:24:17
Chapu, jsou to amateri. Taky tam nepisou, ze to ma problem s rychlosti zapisu, kdyz se do toho vsi silou mlati kladivem.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: Rob Ros 30. 03. 2021, 11:24:28
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: xsouku04 31. 03. 2021, 10:45:18
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: _Tomáš_ 31. 03. 2021, 12:02:14
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: Rob Ros 31. 03. 2021, 12:31:56
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: xsouku04 31. 03. 2021, 14:00:05
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: _Tomáš_ 01. 04. 2021, 10:56:05
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: xsouku04 01. 04. 2021, 11:08:56
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ů.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: xsouku04 15. 04. 2021, 12:18:06
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).
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: messagebus 15. 04. 2021, 14:19:24
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.
Název: Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace
Přispěvatel: ondrej _ 15. 04. 2021, 15:59:17
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.