https://forum.root.cz/index.php?action=post;topic=29358.15;last_msg=408311#postmodifyPodle mne získání 10% procent výkonu není moc důležité. Jde spíše o to lépe vyhovuje životnosti disku. A zde může být lepší, když jde na disk zapsat jen 512B, když se např. updatuje index databáze. Nebo jak to vlastně funguje?
A také jde o to, co se vlastně započítá, jestli jeden blok, nebo rovnou bloků 8 kvůli jedinému zápisu.
Ty čítače ve SMARTu z NVME disku nekecají, jsou to dva standardizované atributy (07h, 08h), které říkají kolik dat šlo při čtení resp. zápisu z hosta (ne kolik se zapsalo na NAND buňky). Je to vždy přepočítáno na bloky 512 bajtů.
Tzn. když se zapíše jeden 4k request, tak se čítač inkrementuje o 8, pokud se zapíše čtyři 16k requesty, tak se inkrementuje o 32 atp. Z hlediska tohohle akumulovaného čítače je víceméně jedno, jaké délky requestů se používají a případně jaká je minimální délka v systému (jestli 512 B nebo 4 kB).
Navíc jsou tam dva další čítače (09h, 0Ah), Host Read Commands a Host Write Commands. Když podělíte velikost (v bajtech) z předchozích atributů těmihle hodnotami, dostanete průměrnou délku requestu.
Pokud byste chtěl zjistit kolik se skutečně zapsalo do buněk a potažmo, jaká je amplifikace zápisu (WAF) v hardware, tak to není ve standardních atributech v NVME disku. To je typicky v detailnějším c0 logu, který musíte vytáhnout a dekódovat přes konkrétní utilitu v nvmi-cli, ale formát je specifický pro každého výrobce, takže např. pro Intel to bude něco jako - nvme intel smart-log-add
https://manpages.debian.org/testing/nvme-cli/nvme-intel-smart-log-add.1.en.html To pak zobrazí i celková data zapsaná data do buněk (obvykle počet 32MB bloků).
Hardwarový WAF ovlivníte primárně tím, co jsme tu naťukli v ostatních postech.. Tzn. třeba podle situace např. volným místem na FS a pravidelným trimováním.
Ale to, jak jsem to pochopil, není ta hlavní potíž. Vy spíš řešíte zvýšení WAF a množství zápisů, kvůli nastavení filesystémů, resp. databáze.
Jak zaznělo v předchozích postech, tak tohle bude primárně věc souběhu určitých mechanismů v ZFS a v innodb, které se pak projeví tak, že se do toho blok. zařízení zapisuje mnohem víc, než se standardními souborovými systémy.
Něco už tu padlo. Innodb má standardně zapnutý doublewrite do separátního souboru, tzn. dělá to víceméně totéž jako CoW u ZFS. Další věc je, že když se dat. soubor, index, nebo ten DW soubor otevře v synchronním řežimu, tak to na ZFS jede vždy přes ZIL (což je takový specifický žurnál buď v datasetu, nebo na samostatném zařízení). Data jdou nejdřív tam, pak se potvrdí zápis tomu procesu a následně zapíší na cílové místo v datasetu. Takže zas o zápis víc. Když už se použije ZIL, tak se dá ozkoušet různé nastavení volby logbias.
Dají se pak samozřejmě ladit i další parametry jak na úrovni ZFS, tak innodb, které nemusí nutně amplifikovat počet zápisů, ale mohou v určitých situací negativně ovlivnit výkon nebo třeba i spolehlivost ukládání dat, pokud se to rozhasí. Např. metoda synchronizace (flushování bufferů), ZFS nemá implementovaný O_DIRECT (vrací, že ano, takže nespadne aplikace, ale nechová se jako na klasickém fs), další věc je to nastavení bufferů, práh, kdy to začne flushovat, úroveň paralelizace atp. Na určitých konfiguracích, kde je třeba agresivnější bufferování v innodb může mít smysl v ZFS datasetu vypnout fakticky vypnout ARC pro data.
Relevantní volby jsou popsány přímo v dokumentaci OpenZFS a je tam i od
https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html#innodbPřípadně aktualizovaný dokument o výkonu u Percony:
https://www.percona.com/blog/mysql-zfs-performance-update/Stran velikosti těch bloků, to je asi další téma (a držel bych se toho defaultu, ashift podle nativní velikosti na SSD - např. 4k, recordsize na datasetu podle velikosti stránky innodb), ale jiné nastavení by nemělo primárně způsobovat ten zásadně vyšší WAF.
Jak jsem zmiňoval, kdybych si to měl testovat a porovnávat s EXT4, potom, co budu měnit jednotlivé volby. Vůbec na počítání zápisů není potřeba to konkrétní SSD, udělal bych nějakou testovací databázi, čerstvé ext4 a ZFS třeba nad nějakými loop devicey a odečítal bych to rovnou z /proc/diskstats.. Dá se to zapéct rovnou do nějakého skriptu, co odečte aktuální hodnotu čítače s počtem zápisů, provede operaci s mysql klientem (nějaký SQL skript s insert, update, delete např.) a pak zas zjistí aktuální počet a odečte předchozí hodnotu. ZFS bude mít víc I/O než ext4, ale nemělo by to být 10x.
Uff, trochu delší
Zobrazit příspěvky
. 