Aky file system pre DB server?

Re:Aky file system pre DB server?
« Odpověď #15 kdy: 01. 09. 2024, 06:46:09 »
Pokud jsem na tomtéž diskovém subsystému použil XFS nebo Reiser 3, jely testy klidně několik dní bez problému.

No, asi bych měl napsat něco jako "to není možné", ale spíš mi přijde odpovídající "ani mě to neudivuje".
Docela mě láká zkusit to vámi zmíněným Bonnie++ dostat EXT4 do stavu smrti.

BTW podobný problém:
https://forum.proxmox.com/threads/heavy-i-o-causes-kernel-panics-deadlocks-and-file-system-corruption-on-ext4.122008/

Znovu děkuji za reakci.

Tušímže v té době jsem k EXT4 ještě nepřilnul, jednalo se o EXT3.

Ten člověk na Vašem odkazu vidí kernel panic, dokonce je tam vidět konkrétně "drive ready, sense error" - to je už na první pohled cosi od disku. A jestli na to fórum správně koukám (nepřihlášenej) tak jsme se ani nedozvěděli model toho 8TB disku, co měl připojenej zvenčí přes USB, kterej mu to podle všeho dělal.

Mně se to tehdy dávno chovalo tak, že prostě ustala disková aktivita, obě/všechny instance Bonnie++ se zastavily, na další konzoli běžel top který se dál refreshoval a ukazoval 0% zátěž CPU (nový už nastartovat nešel, protože shell chtěl přístup k VFS). Nikde žádný panic - na fyzické VGA konzole, kterou nic nepřepisovalo. Zároveň to podle mého bylo už pár let po odstranění giant locku. Matně si pamatuju, že stroje u nás na dílně měly tehdy běžně asi 2-4 logická CPU jádra, a já jsem spouštěl zvlášť instanci Bonnie++ na každé jádro (bez vzájemné synchronizace, option -p jsem neznal).
Bonnie++ má v závěru sady testů jednu "stage", kde vyrábí mraky drobných souborů (a možná adresářů) a nějak s nimi šachuje. Tuším potřebovala každá instance svůj vlastní "aktuální adresář", aby si nešlapaly navzájem do zelí. A právě v téhle fázi benchmarku to pravidelně uvázlo.

Upřesnění: pracoval jsem tehdy se dvěma verzemi: bonnie++ 1.03 ("původní") vs. bonnie++2 , binár v mém studeném archivu obsahuje označení verze 1.93c = nějaká tehdejší "beta dvojky" . A dělala to tuším jenom ta dvojková verze - byla krutopřísnější. Tady je něco jako changelog dvojky. Viz též
https://linux.die.net/man/8/bonnie++/
https://www.coker.com.au/bonnie++/
https://github.com/mer-tools/bonnie
https://sourceforge.net/projects/bonnie/files/Bonnie%2B%2B%20Experimental/
Je to dávná historie. Zejména verze Bonnie jsou hodně staré, ale já jsem tu testovací sadu (user space) přestal poměrně záhy aktualizovat, mnoho let jsem aktualizoval jenom kernel, skončil jsem tuším někde na čtyřkových verzích. Tohle pozorování jsem zkoušel naposledy možná na trojkových kernelech.

Bacha ten benchmark si fakt nebere servítky a do FS dost hnojí, zejména bych tím netrápil SSD na kterém Vám záleží.


Re:Aky file system pre DB server?
« Odpověď #16 kdy: 01. 09. 2024, 07:07:39 »
Já chápu, že takový Pavel Stěhule řeší asi úplně jiné hardcore úlohy, ale pro ten základ myslím dobré.

Přiznám se, že tohle se snažím neřešit. Doplnění jednoho chybějícího indexu u relativně často používaného dotazu u tabulky nad pár GB vám přinese řádově víc výkonu než hodiny tůningu filesystému. Tomáš Vondra dělá pravidelně benchmarky Postgres OLTP vůči různým FS - namádkou jsem našel https://fosdem.org/2024/events/attachments/fosdem-2024-3605-postgres-vs-linux-filesystems/slides/22850/postgres-vs-filesystems-fosdem-2024_QQG6Ha7.pdf

a co si pamatuju, tak XFS nebo EXT4 jsou plus mínus v pohodě, COW je potřeba dokonfigurovat, aby rozumný výkon. Určitě bych to neřešil u aplikací, kde máte pár tisíc tps. Pokud budete mít problém s výkonem, tak ne, že by za to filesystém někdy nemohl, ale mnohem častější problémy jsou chybějící indexy (nebo zase příliš velké množství indexů), neúdržba db (neprovádí se reindexace) nebo velké množství subtransakcí (zahlcení určitých bufferů v pg), užití antipatternů, atd. Je možné, že exotické nebo speciální FS výkonnostní problémy mít budou - umístění db na distribuovaný FS může být problém - zvlášť pokud pro to není profi hw.

Co je problém, který s tím souvisí částečně, je špatný výkon IO, s kteým se občas potkám - za COVIDu jsem dlouho hledal  výkonnostní problém u jednoho zákazníka, při trochu větší zátěži úplně kolaboval výkon, a nakonec se ukázalo, že viníkem je "optimalizace cache" v proxmoxu. Se správným nastavením už 3 roky není jediný problém. Teď nedávno jsem u dvou zákazníků řešil problémy s výkonem a u obou hlavním problémem byl limit 3000 iops u Amazonu.

Re:Aky file system pre DB server?
« Odpověď #17 kdy: 01. 09. 2024, 07:18:09 »
Já chápu, že takový Pavel Stěhule řeší asi úplně jiné hardcore úlohy, ale pro ten základ myslím dobré.

Přiznám se, že tohle se snažím neřešit. Doplnění jednoho chybějícího indexu u relativně často používaného dotazu u tabulky nad pár GB vám přinese řádově víc výkonu než hodiny tůningu filesystému.

Pokud chcete mít klidné spaní, minimum incidentů a stabilní provoz, tak nikdy na produkční db nemějte dlouhodobě 100% utilizaci IO. Tak 70% max. Tuplem u Postgresu, kde se vám může "neplánovaně" automaticky pustit VACUUM FREEZE (JEN EXPERT NEBO NAPROSTÝ BLB MǓŽE VYPNOUT AUTOVACUUM). Tudíž limity IO, FS nejsou až tak důležité, protože byste je  normálně neměli dosahovat.

Re:Aky file system pre DB server?
« Odpověď #18 kdy: 01. 09. 2024, 11:16:20 »
Rozdíl mezi serverovými a desktopovými disky je třeba v tom, že ten serverový se ve stanovené době přestane pokoušet o přečtení chybného sektoru. (Desktop se snaží data zachránit. Serverový spoléhá na paritu Raidu, tak to vzdá.)
Nazor, ze desktopovy disk se pozna podle vypnuteho TLER/ERC, lze povazovat za smesny.

Re:Aky file system pre DB server?
« Odpověď #19 kdy: 01. 09. 2024, 11:32:54 »
https://www.phoronix.com/review/optane-linux-raid/4

XFS má právě docela dobrý výkon, hlavně když se to všechno trochu poladí.
Nicméně klidně EXT4 a všechno mít na jednom device, protože u 50 zápisů za minutu je to prostě fuk.
(Víc FS vs jediný? Jeden Device vs několik? Složitá konfigurace vs jednoduchá? Default parametry vs vytuněné? Vynaložené úsilí vs má to cenu?)

Souhlas.

A samozřejmě hodně závisí na konkrétní aplikaci a databázi, vytížení. Jsou situace, kdy to nemá moc smysl řešit a uspokojivě zafunguje i ta nejpomalejší varianta, příklad může být třeba nějaký Own/NextCloud pro pár lidí na Synology NASu, který má standardně BTRFS nad MDRAIDem. Podobně nějaká menší lokální webová aplikace.
Pro dedikovaný db server, nebo třeba na hostingu už to ale může být výrazně větší problém a optimalizace se vyplatí.

Akorát s tím Phoronixem, beru to s velkou rezervou. U nějakých testů mezi verzemi kernelu, testování CPU - O.K.
Tyhle testy mezi různými produkty (FS, kompilátory, různé Linux vs BSD vs..) jsou do jisté míry velmi zavádějící. Beru to tak, že je primárně autor, který logicky nemá moc času na optimalizace, zkoumání, ty věci jsou relativně složité a stačí jeden blbý parametr, aby to totálně změnilo výsledky. Se základním vhledem do konkrétní problematiky tím prohučí baterii testů v defaultním nastavení, což sice může mít svou hodnotu, ale v produkčním prostředí to moc lidí nudělá.
Takže konkrétně třeba ZFS se dá poměrně dobře vyladit, jak s MySQL, tak, co vím i s Postgresem, a zdaleka to není takový průšvih. Doporučuji spíš Perconu, případně přímo diskuze okolo OpenZFS.

Jinak ext4 vs XFS. Nemyslím, že by mezi nimi byl nějaký zásadní rozdíl ve výkonu u většiny vytížení.
Já osobně k tomu výběru zjednodušeně přistupuju tak, že pokud je to server (v normálním prostředí, s UPS), není moc důvodu nepoužít XFS. Pokud je to nějaké normální PC, appliance, Raspberry atp., používám ext4.

Kdybych to měl trochu rozpitvat, primárně pro tazatele, tak oba FS jsou výborně podporované, pořád dostávají další optimalizace, jsou testovány, přidávají tam průběžně nové funkce (samozřejmě v rámci možností těch fs) atp.

Výhody ext4 jsou (podle mě)
- trochu menší režie na zařízeních s omezeným výkonem
- možnost vynutit žurnálování dat i metadat pro specifické účely
- možnost zmenšení odpojeného FS
- širší kompatibilita (sdílení mezi různými operačními systémy, s různými implementacemi ovladače pro fs)
- v případě problému pak jednodušší FS s mnoha volnými i komerčními nástroji na obnovu

U XFS
- od začátku navržený pro škálovatelnost při paralelním přístupu k FS (nemusí se nutně projevit v jednoduchém benchmarku, ale s odpovídajícím workloadem a pokud to není limitováno hardwarem pod tím - řekněme při provozu na nějakém enterprise diskovém poli, nebo NVME úložišti, tak to může být znát, při zápisech a operacích s metadaty, latencích)
- testováno a provozováno na opravdu velkých oddílech s mnoha soubory (nejde jen o teoretické limity, že nedojdou někde bity, ale i o praktické používání těch souvisejících userspace nástrojů)
- slušná optimalizace pro nízkou fragmentaci (prakticky - pokud se člověk udrží s volným místem a není tam nějaký  patologický pattern používání, nemusí se o to vůbec starat)
- project kvóty na adresáře
- porpora reflink na novějších jádrech. I když XFS samozřejmě není CoW FS se snapshoty, tak tohle je v určitých situacích skvělý nástroj a může je to do jisté míry suplovat. Sám to občas používám na rychlé "ad-hoc" zálohy třeba u image disků pro VM, ale klidně si dovedu představit, že by to mohlo zafungovat i pro databáze. Předesílám - nešel jsem do detailního zkoumání, co to pak následně udělá s fragmentací, při pravidelném dlouhodobém používání.


CPU

  • *****
  • 906
    • Zobrazit profil
    • E-mail
Re:Aky file system pre DB server?
« Odpověď #20 kdy: 01. 09. 2024, 12:25:52 »
+1  ;)
Já si myslím, že se v principu shodujeme.

A mimořádně důležitý je pohled i pana Stěhule
Doplnění jednoho chybějícího indexu u relativně často používaného dotazu u tabulky nad pár GB vám přinese řádově víc výkonu než hodiny tůningu filesystému.

Já se k tomu dopracoval z druhé strany, kdy jsem nejprve ladil hromadu věcí, které znám a řeším poměrně běžně.
- přidání paměti
- oddělení OS a databáze
- v rámci DB oddělení databáze a logů na samostatné RAID
- změna FS
- povypínání zbytností
- změna běhových parametrů DB
(innodb_buffer_pool_size,join_buffer_size,innodb_log_file_size...)

A pak BUM, přijde kolega a nějakou chytrostí z toho leze 10x víc dat...navíc machruje a neprozradí, jak to udělal...
EDIT: Teď se ještě naučit ladit DB tak, abych takovou věc viděl :-D
« Poslední změna: 01. 09. 2024, 12:29:27 od CPU »

Re:Aky file system pre DB server?
« Odpověď #21 kdy: 01. 09. 2024, 14:13:24 »
A pak BUM, přijde kolega a nějakou chytrostí z toho leze 10x víc dat...navíc machruje a neprozradí, jak to udělal...
EDIT: Teď se ještě naučit ladit DB tak, abych takovou věc viděl :-D

Začátek je umět číst prováděcí plány, vědět co co znamená a z toho se dá docela dobře vyčíst, kde chybí index. A pak mít statistiky pomalých nebo častých dotazů a u nich se dívat na prováděcí plány. A pak mít trochu zkušeností a citu, aby člověk rozeznal, co je normální, a co je už divné nebo patologické. Databáze se nechovají lineárně - pokud jste na hranici výkonu (třeba kvůli tomu, že vám u jednoho dotazu chybí index), tak hromada dalších dotazů se může chovat špatně, zvětšuje se souběh, což může způsobovat problémy se zámky, zámky vám mohou vyžírat CPU, aplikace pak zbytečně otevírá spojení, a to zase žere CPU a paměť, atd atd. A pak je potřeba zhruba tušit jak funguje optimalizace a to pro každou konkrétní db - protože každá db má vlastní optimalizátor (něco se podobá, ale je tam dost specifik), případně vědět, kde se zeptat. Když umíte používat perf, tak to taky může pomoct - u jednoho zákazníka jsem např. zjistil, že 80% výkonu CPU mu žere jeho neefektivně napsaná funkce na odstranění diakritiky. Občas je to magie - pro začátek stačí docela málo - hledat neefektivní sekvenční čtení nebo neefektivní index scan. Nevím na kolik procent - ale dost často je moje práce jen v přidání pár jednoduchých indexů a pár vícesloupcových - a v 50% to hodně pomůže.

hknmtt

  • ***
  • 132
    • Zobrazit profil
    • E-mail
Re:Aky file system pre DB server?
« Odpověď #22 kdy: 01. 09. 2024, 14:39:06 »
Podla tohoto https://www.salvagedata.com/btrfs-zfs-xfs-ext4-how-are-they-different/

sa zda ze ZFS je dobry na cluster.

XFS je dobry na, akurat ze nema ziadnu detekciu zlyhani disku alebo "bit rotu"(zlyhanie pametovych buniek v pcb), takze pre DB alebo kriticke datove ulozisko to nie je vhodne lebo moze odfajcit celu db.

EXT4 sa zda byt po vsetkych strankach optimalne, az na to ze nevie pracovat s raidom dobre lebo je to len "blby" FS.

Takze tam vychadza najbezpecnejsie BTRFS.

V konecmom dosledku je to teda o tom, ci chce clovek viac vykonu(XFS, EXT4), pripadne riesi velky cluster(ZFS), alebo bezpecnosti(BTRFS), povedzme atomicity.

Kedze som sa pytal na databazovy server, tak mi tu vychadza najlepsie EXT4 kvoli vykonu a ked neriesim viac diskov. Inak  BTRFS.

PS: o snapshoty na urovni disku mi vobec nejde. To som len tak spomenul ako vyhodu BTRFS ale nie je to nieco co riesim/chcem.. Ide mi primarne o to aby FS vedel zabranit poskodeniu dat a neodfajcil rychlo disky(privela zapisov a citani). Proste nieco na com ma bezat kriticka db a nie obycajna db pre webstranku kde problem s diskom nie je koniec sveta.
« Poslední změna: 01. 09. 2024, 14:42:39 od hknmtt »

Re:Aky file system pre DB server?
« Odpověď #23 kdy: 01. 09. 2024, 15:20:11 »
XFS je dobry na, akurat ze nema ziadnu detekciu zlyhani disku alebo "bit rotu"(zlyhanie pametovych buniek v pcb), takze pre DB alebo kriticke datove ulozisko to nie je vhodne lebo moze odfajcit celu db.
...
PS: o snapshoty na urovni disku mi vobec nejde. To som len tak spomenul ako vyhodu BTRFS ale nie je to nieco co riesim/chcem.. Ide mi primarne o to aby FS vedel zabranit poskodeniu dat a neodfajcil rychlo disky(privela zapisov a citani). Proste nieco na com ma bezat kriticka db a nie obycajna db pre webstranku kde problem s diskom nie je koniec sveta.
XFS muze resit integritu dat pres T10/DIF/DIX, ale to uplny socka HW neumi.

Re:Aky file system pre DB server?
« Odpověď #24 kdy: 01. 09. 2024, 16:05:31 »
Takze tam vychadza najbezpecnejsie BTRFS.

Do chvíle, než se to sesype a už to nikdo nedá dohromady. Jinak bych doporučil kritická data hlavně zálohovat. (RAID a snapshoty nejsou záloha.)

Re:Aky file system pre DB server?
« Odpověď #25 kdy: 01. 09. 2024, 16:17:59 »
Podla tohoto https://www.salvagedata.com/btrfs-zfs-xfs-ext4-how-are-they-different/

sa zda ze ZFS je dobry na cluster.

ZFS v sobě žádné vestavěné clusterování nemá. Pokud tohle nutně potřebujete, tak musíte mít buď vyloženě clusterovací FS, např. GPFS od IBM, StorNext, OCFS od Oracle, který má nějakou sdílených (distribuovaných) zámků. Nebo pak musíte kombinovat víc věcí dohromady. Tzn. např. ZFS a nad tím glusterfs, CEPH.

Nicméně tady je dobré zároveň zmínit, že jste se ptal na FS pro databázi. Což je jeden konkrétní specifický use case. Většina databázových serverů s určitou formou vnitřního clusterování přímo počítá. Pokud bychom pominuli např. Oracle RAC Cluster, tak se to typicky neřeší na úrovni FS.
Je to vždy specifické pro konkrétní projekt a vybranou databázi, a bývá tam víc způsobů realizace. Nicméně pokud chcete clusterovanou db pro zvýšení dostupnosti, rozhodně nepotřebujete ZFS, ale spíš musíte prozkoumat možnosti vybraného serveru (db engine).

Citace
XFS je dobry na, akurat ze nema ziadnu detekciu zlyhani disku alebo "bit rotu"(zlyhanie pametovych buniek v pcb), takze pre DB alebo kriticke datove ulozisko to nie je vhodne lebo moze odfajcit celu db.

Ta online verifikace checksumů, je jeden s těch argumentů pro ZFS. Bit-rot, poškození dat samozřejmě určitou roli hrát může (zvlášť když si děláte nějakou dlouhodobou statistiku v obrovských datacentrech), ale přijde mi, že ve většině případů je to strašně vyhypované.
Řekl bych, že valná většina běžících systému za poslední dekády vůbec žádný on-line checksuming na úrovni FS neměla a nemá, normálně to běhá a není tam žádný excesivní výskyt chyb. Když máte slušný serverový HW a odladěný systém, tyhle problémy typicky nemáte.
Samozřejmě, určité formy ověřování jsou navíc implementováno i na mnoha dalších místech. Od sběrnic, přes ECC paměti, u enterprise storage systémů může být pak navíc použité T10 (DIF, DIX).
Navíc i některé databáze mají možnost konfigurovat ověřování checksumů u stránek.
Ano není to self-healing, ale dokáže to indikovat problém. A stejně když máte něco důležitého, musíte stejně mít dobře vyřešenou strategii pro zálohování (kontrolu záloh, restoru) atp.

Takže za mě, tohle není určitě ta hlavní věc, proč bych šel na databázi do CoW systému.

Citace
EXT4 sa zda byt po vsetkych strankach optimalne, az na to ze nevie pracovat s raidom dobre lebo je to len "blby" FS.

V konecmom dosledku je to teda o tom, ci chce clovek viac vykonu(XFS, EXT4), pripadne riesi velky cluster(ZFS), alebo bezpecnosti(BTRFS), povedzme atomicity.

Kedze som sa pytal na databazovy server, tak mi tu vychadza najlepsie EXT4 kvoli vykonu a ked neriesim viac diskov. Inak  BTRFS.

PS: o snapshoty na urovni disku mi vobec nejde. To som len tak spomenul ako vyhodu BTRFS ale nie je to nieco co riesim/chcem.. Ide mi primarne o to aby FS vedel zabranit poskodeniu dat a neodfajcil rychlo disky(privela zapisov a citani). Proste nieco na com ma bezat kriticka db a nie obycajna db pre webstranku kde problem s diskom nie je koniec sveta.

Upřímně s tímhle vyhodnocením taky úplně nesouzním. Nemyslím, že by automaticky vše převážila výhoda mít FS s vestavěným RAIDováním (multi device). Třeba konkrétně u BTRFS je tam zrovna tohle docela nedodělané/nedomyšlené, nemyslím tím jen RAID5/6 (který je už léta v neprodukčním stavu), ale např. i u jednoduchého mirrorování.
Například tam není spolehlivý mechanismus jak zajistit, že se po vykopnutí jednoho (vadného) disku z mirroru FS automaticky správě připojí po rebootu tak, aby se spolehlivě detekoval a použil ten druhý (zdravý), který má poslední zápis.
Musíte to jen manuálně připojit s explicitním použitím optionu degraded a správným zařízením. Což je třeba super, když máte BTRFS mirror jako rootfs, vzdálený server a ten se vám po nějakém násilném rebootu zastaví v initrd. Ale i u datového disku je to podle mě docela problém.
Na mailing listech BTRFS a fórech se o tom debatovalo už před deseti lety a pořád se to chová stejně (pravděpodobně jiné priority).
To je třeba jeden z důvodů, proč se to pořád používá dohromady s MDRAIDem, který udělá jedno blokové zařízení, je spolehlivý, akorát pak samozřejmě můžete zapomenout na veškerý self-healing.
ZFS je na tom v tomhle ohledu mnohem líp, ale také má svá specifika a vyžaduje značné ladění.
Jinak jedna ze základních charakteristik CoW filesystémů (jak BTRFS, tak ZFS) je že z principu zvyšují write amplification factor,
tzn. jestli vám jde o to, abyste "neodfajcil rychlo disky(privela zapisov...", tak to také není nutně ten nejlepší nápad.

Za těchhle okolností budu mít na databázi daleko radši MDRAID (nebo HW RAID kartu) a slušná serverová U.2 / U.3 SSD s dobrou výdrží. Navíc nebudu muset nutně řešit jak spolu "bojuje" chytrý FS a vestavěné mechanismy v databázovém serveru..
Ušetřený čas pak můžu věnovat optimalizaci databáze, a vychytávání mechanismu pro zálohování. Připadaně pokud je to opravdu důležité, a je potřeba vysoká dostupnost, tak udělat DB cluster.

Jinak aby to nevyznělo tak, že en-bloc odsuzuji CoW FS. Vůbec ne a jsou spousty oblastí, kde to může přinést reálné benefity, rychlé snapshoty jsou super pro obecné file servery, kontejnery atp. Relativně cenově dostupná ZFS úložiště s JBOD a hromadou disků atp.
BTRFS zase rád používám jako systémový FS na rolling distribucích, protože se můžu snadno vracet a nabootovat ze staršího snapshotu, když se něco pokazí atp.
Ale u těch databází mi přijde, že pokud se vyloženě člověk nemusí přizpůsobit nějakému cízímu serveru, nebo systému, kde už je tohle dané (např. ZFS na FreeBSD), tak si akorát může přidělat starosti.


Re:Aky file system pre DB server?
« Odpověď #26 kdy: 01. 09. 2024, 17:33:15 »
Opakovaně tu byla zmiňovaná CoW fragmentace, jak je to vlastně s takovou fragmentací na SSD? Např. pro mysql je doporučená velikost bloku ZFS 16k. Chápu, že to může mít vliv na životnost, když je erase block size třeba 1MB. Ale na čtení/zápis? Řadič v disku přece stejně všechny zápisy rozhazuje a na čtení je celkem jedno, z jakých částí prostoru to poskládá.

Re:Aky file system pre DB server?
« Odpověď #27 kdy: 02. 09. 2024, 02:34:33 »
Opakovaně tu byla zmiňovaná CoW fragmentace, jak je to vlastně s takovou fragmentací na SSD? Např. pro mysql je doporučená velikost bloku ZFS 16k. Chápu, že to může mít vliv na životnost, když je erase block size třeba 1MB. Ale na čtení/zápis? Řadič v disku přece stejně všechny zápisy rozhazuje a na čtení je celkem jedno, z jakých částí prostoru to poskládá.

Ano je to zajímavé téma, protože se člověk setká se spoustou různých a i protichůdných vyhodnoceními problému, z různé doby a třeba i popisující různé technologie.. Není to určitě takové peklo jako u točivého disku, co seekuje :)

Mrkněte na tohle.
https://www.usenix.org/system/files/fast24-jun.pdf

Je to docela čerstvý paper, se spoustou referencí k danému tématu v předchozích výzkumech a dokumentacích.

TL;DR
- reálně to je problém i u SSD
- oproti předchozím výzkumům vyhodnotili, že největší vliv na ztrátu výkonu při čtení má nerovnoměrné rozložení stránek, které obsahují data, na čipy v SSD. Zhorší to paralelizaci při čtení a za určitých podmínek i razantně sníží výkon. Při optimální kontinuální alokaci se čipy střídají v round-robin režimu jak při čtení, tak při zápisu - funguje to jako RAID0.
- při zápisu souboru se může rozhodit správné střídání čipů, protože firmware to točí pouze podle pořadí I/O requestů ze systému. To může být ovlivněno fragmentací souboru, souběžným zápisem více souborů, I/O schedulerem, optimalizacemi ve FS atp.
- jejich řešení spočívá v rozšíření NVME příkazů pro zápis tak, aby se posílaly další metadata ohledně zápisů. Pokud append, tak se pošle navíc i logická adresa předchozího bloku, pokud overwrite, tak jen hint, že jde o přepis a ne o normální zápis. Ve výsledku to přizpůsobí rozložení stránek na čipy podle pořadí logických bloků na FS. Takže když se pak soubor čte, zafunguje paralelizace při čtení napříč všemi čipy.
- vyžaduje to modifikaci FS a firmware SSD (mimo simulátor), aby se to dalo realizovat. Patch pro ext4 už existuje, a tím že jsou ze Samsung university, tak ani ten firmware nebude nejspíš úplně nereálný.
Jinak logicky se to nemusí projevit se stejnou intenzitou ve všech workloadech a zdaleka každý nemusí narazit na limit.

I kdyby se tohle nechytlo, je to zajímavý vhled do fungování současných NAND SSD.

Fragmentace ma samozřejmě i praktický přesah do nastavení třeba ZFS. Tam je kupříkladu volba logbias, která se týká práce s ZIL (tzn. synchronními zápisy, např. z některých databází, NFS) a která ovlivní, jestli se při práci se ZILem data zapisují víceméně nadvakrát s menší fragmentací, nebo přímo naopak s výrazně větší fragmentací. První nechcete kvůli zvyšování WAF, druhé pak kvůli potencionálně horšímu výkonu při čtení. Pick your poison ;)
Btw. výchozí je to s těmi dvěma zápisy

Wasper

  • ***
  • 122
    • Zobrazit profil
    • E-mail
Re:Aky file system pre DB server?
« Odpověď #28 kdy: 02. 09. 2024, 04:54:51 »
kdy na disk netekly žádné transakce, a jakýkoli syscall pro přístup k souborovému systému se zablokoval navěky. Prostě deadlock v kernelu.
Nepamatujete si, co v tu chvíli ukazoval top kolem paměti?

Možná nesouvisející, ale někdy dávno (3.x nebo 4.x kernely) jsem na jedné, dost brutálně poddimenzované mašině (to ještě snad nebyl oom killer) dostaval do podobného stavu co popisujete, kdy to vypadalo, že kernel nemůže něco naalokovat (a mnohem háklivější to bylo, když to nemělo alespoň minimální swap). Dělalo to i na jiných, ale mnohem méně častěji - vše na ext4.

Tak jestli se Vám třeba nepodařilo odtriggerovat podobný bug třeba zaplněním dirty cache apod.

Re:Aky file system pre DB server?
« Odpověď #29 kdy: 02. 09. 2024, 05:59:19 »
kdy na disk netekly žádné transakce, a jakýkoli syscall pro přístup k souborovému systému se zablokoval navěky. Prostě deadlock v kernelu.
Nepamatujete si, co v tu chvíli ukazoval top kolem paměti?

Možná nesouvisející, ale někdy dávno (3.x nebo 4.x kernely) jsem na jedné, dost brutálně poddimenzované mašině (to ještě snad nebyl oom killer) dostaval do podobného stavu co popisujete, kdy to vypadalo, že kernel nemůže něco naalokovat (a mnohem háklivější to bylo, když to nemělo alespoň minimální swap). Dělalo to i na jiných, ale mnohem méně častěji - vše na ext4.

Tak jestli se Vám třeba nepodařilo odtriggerovat podobný bug třeba zaplněním dirty cache apod.

Co psal "top" kolem paměti Vám neřeknu :-( Ale jinak to byla jedna z mých hypotéz. Ty testy bootovaly ze sítě, diskless, bez swapu. Userspace byl ručně minimalizovaný, samotný OS zabral pár MB RAM z osazených několika stovek (spíš kolem 1 GB, v některých případech přes 4 GB), historicky to prostředí bylo schopné nastartovat asi na 8 MB RAM - ale je velmi dobře možné, že při intenzivních zápisech se něco zaplnilo writeback bufferem.

Například výpis /proc/meminfo nemám - možná hlavně proto, že po reprodukci problému se zaseknul taky shell, nedokázal spustit ani "cat". Což by asi šlo vyřešit spuštěním nějakého procesu, který by neforkoval žádné děti, jenom by tu paměť vypsal jednou za pár sekund ve smyčce... inu až se někdy budu nudit, tak to ještě zkusím :-)
« Poslední změna: 02. 09. 2024, 06:02:07 od František Ryšánek »