Fórum Root.cz
Hlavní témata => Server => Téma založeno: 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?
-
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ší.
-
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
-
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ý.
-
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
-
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/)
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?
-
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ší.
fio --direct=1 --ioengine=libaio --bs=16k ...
Např. konkrétně:
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í.
-
Pokud onen test dělám na zfs výsledek je tohle:
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:
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
-
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.
-
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.
-
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.
-
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ů?
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
Chapu, jsou to amateri. Taky tam nepisou, ze to ma problem s rychlosti zapisu, kdyz se do toho vsi silou mlati kladivem.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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ů.
-
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ě
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).
-
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.
-
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.