Fórum Root.cz
Hlavní témata => Server => Téma založeno: hknmtt 31. 08. 2024, 12:35:22
-
Ktory file system by ste odporucili na databazovy server(mysql, maria, postgres...)?
Pozeral som nejake videa kde sa porovnavalo asi 6 FS a najlepsie vysiel xfs a ext4. Ale napriklad btrfs som videl ze ma snapshoty a vie revertnut cely stav, co moze byt uzitocne?
-
neni i volba nechat partisnu bez filesystemu a db si to sama zpracuje?
-
Rozdíl ve výkonu různých FS je třeba 30% podle typu FS. Ale obvykle ten výkon nepotřebuješ.
Chápeš, když potřebuješ převéz kyblík štěrku, nepotřebuješ kupovat sklápěčku.
Můžou převážit jiné výhody.
Naopak u milionu transakcí za minutu už výkon FS řešit chceš. Pak jde o důsledné oddělení DB a Transakčních logů, optimalizace na úrovni komfigurace DB, FS i tabulek.
-
bylo by zajimave zkusit in-memory databazi, nebo ji rozjet na partisnou vytvorenou z kusu ramky.
-
bylo by zajimave zkusit in-memory databazi, nebo ji rozjet na partisnou vytvorenou z kusu ramky.
Máš InMemoryTable a jsou kua rychlé. Navíc tam nemáš to zbytečné IO okolo FS.
Ale to je věc programátora, aby to vymyslel.
DB na RAMdisku...jen pro rychlé přemrdlání dat a musí mít ECC...
-
Desítky let (letí to) na databáze s řádově tisíci až desetitisíci tps používám xfs. Občas jsem zkoušel alternativu (kdysi třeba i jfs, později ext4, btrfs apod.) a zatím jsem se k němu vždy vrátil. Ale záleží možná na workloadu. HA a backupy (viz snapshoty) řeším prostředky databáze (replikace, pgbackrest).
-
HA a backupy (viz snapshoty) řeším prostředky databáze (replikace, pgbackrest).
Což je asi to nejchytřejší, co můžeš udělat.
Ale není od věci mít i kompletní image/snapshoot z rána ;-)
-
Ktory file system by ste odporucili na databazovy server(mysql, maria, postgres...)?
Pokud bych bez další znalosti konkrétního workloadu, aplikace a prostředí zvolit fs na standardní server s db, tak by to za mě bylo XFS.
Nejmíň problémů za léta používání (RHEL a klony, SUSE), dobrý, predikovatelný výkon. I většina kompletních systémů, co byla přednastavené a instalované dodavateli, používalo XFS a bylo s ním podporované.
Ale samozřejmě může být hromada dalších aspektů, které souvisí s konkrétním nasazením. Některé CoW fs (ZFS, BTRFS) můžou být za určitých podmínek lákavé, protože umožní flexibilní práci s vnitřními snapshoty a můžou rozšířit možnosti nebo zjednodušit zálohování. Na stranu druhou je tam typicky nutné daleko intenzivnější ladění s nastavením konkrétní databáze, protože se tam ve výchozím nastavení některé věci funkčně duplikují (WAL na databázi, CoW u FS atp.), což má za následek, mnohem víc zápisů než je nutné. To má pak samozřejmě vliv nejen výkon, ale i třeba na množství zápisů u SSD.
Plus některé kombinace se mohou chovat opravdu divně a přidělat vám spousty starostí (zkuste si pogooglit např. BTRFS +innodb +mysql +issues).
Takže to chce dobře rozmyslet a otestovat. Někdy nemusí být ten nižší výkon sám o sobě až takový problém (ne každého brzdí množství OLTP transakcí, záleží na struktuře databáze, aplikace), pokud to něco přinese jiné benefity, nicméně jestli to potom ohrozí spolehlivost a dostupnost systému, a projeví se to třeba až časem, už je to větší problém.
Zároveň, jak už tady zmínili ostatní, můžete mít třeba zálohování vyřešeno jinak.. např. logická záloha z repliky db, nebo nějakými inkrementálními zálohami za jízdy (hot backups), což třeba jde přes mariabackup z MariaDB, nebo u komerční MySQL enterprise.
Případně ty snapshoty na zálohování jdou implementovat i pod standardním XFS s pomocí LVM. Není to tak elegantní, musíte si dopředu spočítat, kolik na to bude potřeba místa, ale je to funkční a používá se to dekády.
Další možnost jsou pak třeba snapshoty celých virt. disků s databázovými soubory, pokud to rozběhnete na nějakém hypervizoru (ať už nějaké otevřené řešení, nebo například VMWare + Veeam). Typicky je tam nějaká plánovaná doba snapshotu, hypervizor zakomunikuje s vm, spustí uvnitř nějaký skript, který flushne db a zamkne pro zápis. Pak hypervizor udělá snapshot disku pro zálohu, a uvnitř vm spustí skript, který db zase odemkne.
Spousty možností, ale jak jsem psal, kdybych měl odpovědět úplně obecně, šel bych do XFS.
-
šel bych do XFS
+1
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?)
Já chápu, že takový Pavel Stěhule řeší asi úplně jiné hardcore úlohy, ale pro ten základ myslím dobré.
-
Snapshoty jsou příjemné, pohodlné. Pokud nemáte mnoho Tps, je to asi OK.
V principu ale, snapshoty jsou implementovány pomocí Copy on Write. Pouze pro změny se alokuje nové místo. Kde? No "někde jinde", bokem mimo stávající data. Databáze navíc nezapisuje lineárně, ale seekuje v zásadě náhodně. Výsledek za mě může být jediný: filesystém se tím obscénně zfragmentuje. A dále: když uloupnete snapshot, a provoz jedete dál do toho CoW, a následně odzálohovaný snapshot zrušíte, tak Vám zbydou právě ty CoW špagety. Nemám dost přehled, abych tohle dokázal tvrdit s jistotou, možná se proti tomuto chování dá v rámci FS nějak bojovat... (mohlo by se jednat o jeden z aspektů BTRFS rebalance?) ale je to velice častá námitka proti použití BTRFS pod databází.
Ono se v BTRFS to CoW chování dá zakázat pro běžný provoz bez snapshotů (= nedělej CoW když nemusíš) - ale zrovna snapshot je situace, kdy tenhle zákaz CoW implicitně padá, což je v dokumentaci zmíněno :-(
-
BTW je to už mnoho let, co jsem trápil diskové subsystémy pomocí benchmarků - v té době s rotující rzí a direct-attached RAIDy jsem byl schopen, přivést filesystémy skupiny EXT vysokou zátěží IOps (Bonnie++) do divného stavu, 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. Nikde žádná chybová hláška, co nešahalo na disk to běželo dál, ale cokoli s diskem zůstalo viset.
V té době XFS a ReiserFS (Reiser 3) tenhle problém neměly, Bonnie++ vždycky proběhla celá, klidně jsem mohl spustit několik instancí simultánně.
-
zda za ze bud ext4 alebo xfs tym ze ext4 je znacne rozsirenejsi tak je to bezpecna a solidna, a univerzalna, volba
https://www.youtube.com/watch?v=O9QZVzq-rX4
-
přivést filesystémy skupiny EXT vysokou zátěží IOps (Bonnie++) do divného stavu
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á.)
A teď rozdíl pole ze serverových a desktopových disků:
Pole ze serverových disků pokrčí rameny, dopočítá chybějící data a nějak se s tím vypořádá.
Pole z desktopových disků rameny nepokrčí, dopočítá chybějící data a začne na tom strašit.
Další problémy mohou nastat v případě, kdy je pole složeno z disků s nevhodnými firmware.
Taky jsem měl takové pole a dostat ho do úzkých nebylo až tak těžké.
Pole začalo kravit po vložení nového disku s novějším firmware!
Po nahrazení disku za starý disk (ze zásob) bylo chování pole opět normální.
(RAID 6+hotspare...byť se to tak nemá dělat, ale...)
Prostě dostat FS do úzkých pomocí databáze prostě často není tak těžké.
Jestli si to chcete zkusit, sežeňte si QLC disk s SLC cache, kde se kapacita SLC mění s obsazeností disků, které se někdy prostě zamyslí, jak přenáší data z SLC cache do normálního prostoru :-D
To se umějí dít věci :-D Když část probíhá, část timeoutuje, co to pak loguje... :o ;D
ext4 je znacne rozsirenejsi tak je to bezpecna a solidna, a univerzalna, volba
No osobně bych se spíš bál třeba ZFS...ale třeba jsem jen srab...
-
přivést filesystémy skupiny EXT vysokou zátěží IOps (Bonnie++) do divného stavu
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á.)
Respekt k Vašim zkušenostem, a děkuji za tuto poznámku.
Ze své strany doplním, že jsem tento problém tehdy pozoroval v průběhu let na různých druzích disků a RAIDů. Ano používali jsme "desktopové" Barracudy, taky tehdejší Barracudy NS/ES, a sice vzácně, ale občas taky Cheetahy (U320 SCSI a později SAS). Sem tam nějaký Raptor/Velociraptor. A došel jsem k poměrně dobře podloženému závěru, že RAID a disky za to nemohly. Já jsem tu věc nakonec tuším pozoroval i na prostém HBA proti jedinému Cheetahu. A na iSCSI na 10Gb lince proti protějšímu boxu, který měl hodně RAM (a diskový subsystém se mu v tom stavu nezablokoval).
Stačilo restartovat hostitelský počítač, externí RAID na SCSI jel dál bez restartu, a problém zmizel (do další reprodukce).
Pokud jsem na tomtéž diskovém subsystému použil XFS nebo Reiser 3, jely testy klidně několik dní bez problému.
Když se Vám zamyslí disk, tak na RAIDu vidíte, že jednotlivému disku svítí kontrolka "activity". Podle toho se "jeden zpomalený disk" snadno pozná. Takové závady jsme samozřejmě taky vídali, a rutinně jsme je řešili výměnou disku.
Ten systematický problém, o kterém mluvím, vypadal jinak. Směrem na RAID a disky nic neteklo. Na ně se nečekalo. Prostě kernel z nějakého důvodu "čekal sám na sebe". Aniž by byl vytížený diskový subsystém nebo CPU, aniž by zamrzlo uživatelské rozhraní samo o sobě.
-
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/
(A je vidět, že se ten člověk s diagnostikou docela nadřel!)
Ovšem nejvíc vtipné je rozuzlení... :-\
Doplním, že jsem zkoušel vygooglovat nějaké informace o tom, jestli už to bylo opraveno, ale náhodou jsem vygoogloval něco, co jsem spíš popisoval já... ;D
Mimochodem, je to záludné v tom, že takový disk by mohl s jiným FS nebo jiným rozdělením možná pořád dál fungovat :-D A to jednoduše proto, že se data jinak rozhází a chyba se přestane projevovat. Asi. Nesadil bych na to ani stovku :-D
Tím ovšem nepopírám vaše pozorování nebo nerozporuji vaše závěry.
Zreplikovat problém = možnost nechat to spravit...
Jen by to mělo chcípnout na kernelpanic...ne? ...když to nic nereportuje, hrozně blbě se to diagnostikuje, ale...mělo by to chcípnout na KP, když to nemůže logovat...
-
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. (https://doc.coker.com.au/projects/bonnie/) 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ží.
-
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.
-
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.
-
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.
-
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í.
-
+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
-
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.
-
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.
-
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.
-
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.)
-
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).
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.
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.
-
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á.
-
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
-
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.
-
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 :-)
-
Ohledně fragmentace CoW FS (a nejspíš i CoW block device v LVM), nad rámec toho co psal Michal Šmucr:
ano SSD svou nulovou latencí seeku (v porovnání s mechanickým diskem) v principu odstraní tento konkrétní problém. Ale nějaké další problémy zbydou. A řekněme, že nebudu řešit dvoupatrové mapování a všelijaké snaživé chytristiky uvnitř SSD.
CoW znamená obecně "Copy On Write" = změny zapisuj na jiné místo, než kde jsou původně uložena měněná data. Takže pokud byl soubor původně uložený hezky sekvenčně, tak teď některé bloky (na jakési úrovni alokace) "vystupují mimo řadu". Pokud jsou ty zápisy drobné a rozházené, tak těch "vystoupení mimo řadu" je velká spousta, a je potřeba tato "evidovat" jednotlivě každé zvlášť. V zásadě to vede k otázce na organizaci metadat FS. Pokud sekvenční alokace vyžaduje relativně prostý záznam [počáteční blok; počet] tak "celý soubor sekvenčně" si vyžádá ideálně jediný záznam :-) A jak do něj začnete CoW stylem zapisovat, začne se ta sekvence drolit do většího počtu dílčích úseků. Při sekvenčním čtení si toto vyžádá větší počet jednotlivých I/O operací skrz blokovou vrstvu vůči disku. Při náhodném čtení je potřeba "pouze" projít delší/hlubší "index v rámci metadat" (spojový seznam, strom apod.) než najdete informaci o umístění žádaného bloku. Mimochodem zkratka BTRFS podle mého původně znamenala B-TRee FS - ale podrobnosti jsem nezkoumal. Obecně průchod BTree indexem (asociativním polem) při vyhledávání záznamu škáluje jak... log(n) ? Samozřejmě objem metadat je maličký ve srovnání se souborem jako celkem, mohou být uložena a načtena nějak optimálně, takže v optimistické variantě jde fakt jenom o to projít ten per-file stromeček v RAMce.
BTRFS má CoW chování by default šmahem zapnuté na jakýkoli soubor, na celý FS - takže se při drobných lokálních modifikacích souborů musí strašně fragmentovat :-) Ono to má asi nějaké optimalizace proti tomuto jevu, ale dával bych si na to bacha. Tohleto CoW chování je nejspíš výhodné z hlediska bezpečnosti FS = na disku jsou vždycky jak původní tak nová data, a "okno příležitosti pro poškození při výpadku napájení" představuje okamžik "přehození výhybky v metadatech", který lze pro jistotu napřed žurnálovat. (Přehlédněme na moment škatule batule, které v dnešní době potichu dělá interně SSD). Především je to výhodné / prostorově efektivní pro vytváření snapshotů: co se nezměnilo, to se alokuje jenom jednou, pro "snapshot původního stavu" i pro aktuální živá data. Zamrzlý snapshot předchozího stavu i "aktuální náhled" mají vlastně jenom oddělené stromečky metadat (a to možná ještě oddělené jenom do jisté míry) - opět jsem nestudoval detaily.
Zde v tomto vlákně se řeší DB server. Databáze běžně mění data ve svých záznamech. Drobné kousky dat. Taky celé záznamy odmazává, což řeší víceméně interní dealokací ve svém DBMS, následně může dealokovaný prostor recyklovat (což FS pod DB extentem vnímá jako přepis souboru). Pokud FS dělá při přepisech zásadně CoW, tak potěš koště, ten BTree v rámci FS bude bobtnat. Konkrétně u BTRFS se CoW chování dá potlačit - dokud nevyrobíte snapshot.
Podobně pokud BTRFS použijete v hypervizoru jako storage pro image blokových zařízení virtuálů, by default bude provoz virtuálů ty image brutálně fragmentovat. Osobně navrhuji, CoW chování pro tyto potřeby zakázat - tuším se to dá udělat per adresář - nebo per subvolume? (není třeba to dělat na celý FS). Pokud máte image virtuálek jako soubory o pevné velikosti, tak se potom přepisy budou dít in-place (dokud neštípnete snapshot, třeba kvůli pořízení zálohy).
Kolmá poznámka: další dobrou fintou je protáhnout z virtuálu na hostitele TRIM/discard, a ty image vyrobit jako "sparse files" (prázdné místo v podkladovém btrfs zůstane předem nealokované). Stalo se mi nedávno, že se ve virtuálu cosi zbláznilo a během okamžiku přetekl disk... (image na podkladovém BTRFS). Po smazání souboru uvnitř virtuálky jsem zvenčí nedostal zpátky zdaleka celé uvolněné místo, ani po BTRFS rebalance - asi že ta dealokace nebyla hezky zarovnaná zevnitř-ven na celé alokační "chunky" podkladového BTRFS :-(
BTRFS dělá CoW hezky uvnitř filesystému - a pokud ho omezíte na snapshoty, tak snapshot = subvolume = adresář v rámci namountovaného "celého" volume (oddílu na blokovém zařízení). Snapshot=subvolume "sdílí alokační pool" s ostatními subvolumy v rámci blokového oddílu. Je v tomto smyslu užitečné, mít snapshoty implementovány v rámci FS, protože tím pádem fungují "téměř per file" (pro admina opticky per directory subtree) a je tam právě ten sdílený alokační mechanismus, což zřejmě umožňuje jistou efektivitu (oproti CoW v rámci LVM).
CoW snapshot v rámci LVM je historicky starší a funguje taky, ale pak děláte snapshot na celé blokové zařízení (volume). Mimochodem jsem našel zmínku o jedné fičuře, která mi připadá "nenápadně půvabná" pro potřeby pořizování záloh: jmenuje se "snapshot-origin". V tom případě CoW funguje tak, že při zápisu změn (do blokového zařízení o pevné velikosti) se změny zapíšou především do živého "primárního volume", který pojede dál, a zároveň taky do "CoW space mimo sekvenci", kde žije zamrzlý snapshot. Pořídíte si takový "zamrzlý snapshot", uděláte z něj zálohu, a smažete ho. Ve výsledku původní "primární volume" nijak neutrpěl CoW fragmentací, protože ten fragmentovaný chumel jste po použití zahodili. Bylo by fajn, kdyby tohle umělo BTRFS - ale nějak nedokážu najít žádnou zmínku, že by tohle šlo.
https://unix.stackexchange.com/questions/756366/is-there-a-reverse-cow-filesystem-or-lvm-feature-for-linux
Mimochodem ten nápad, hintovat SSDčku zda jde v rámci souboru o konkrétní append nebo konkrétní přepis, ten je hodně hezkej :-) Taky jsem tuším viděl nějaký návrh, diktovat SSDčku ještě mnohem podrobněji interní mapování - už nedohledám, kde jsem to viděl, ale šlo v zásadě o návrh "transparentního vendor-independent rozhraní pro pro manipulaci s erase bloky". Připadalo mi, že si navrhovatelé chtějí z SSDčka udělat "pool NAND bloků na způsob prehistorického MTD". Tuším to byl někdo jako Google/Amazon... (operátor velkých cloudů).
-
Celou dobu se tu řeší SSD, což v zadání nebylo explicitně uvedeno. Vzhledem k tomu, že se v zadání píše o MariaDB a MySQL, tedy žádné velké databáze, dá se SSD předpokládat.
Nicméně pokud byste přeci jen chtěl stavět server pro databázi s velkým objemem dat, ke kterým se nepřistupuje až tak často, a řešilo se to pomocí HDD (rotačních disků), tam je CoW souborový systém nevhodný, protože sabotuje to, o co se DB při zápisu na disk snaží (tedy přepisovat data na místě, aby se minimalizoval zápis, a řídit fragmentaci dat).
Docela by mne zajímalo, zda se DB nějak přizpůsobily SSD (případně CoW souborovým systémům) – nic takového jsem nezaznamenal (ale je možné, že mne to jen minulo). Konkrétně jestli se DB umí při zápisu na disk (tabulky, indexy) přizpůsobit tomu, že zapisuje na disk, kde seek není penalizován – a DB by vynechala „složitost“ související se snahou nefragmentovat data. (A druhá věc je, zda se DB přizpůsobuje velikosti bloků na SSD, které – alespoň dříve – typicky bývaly větší, než bloky souborového systému.)
-
Já jsem teď ne moc do hloubky hledal vhodný FS pro Postgre. Nakonec mi z toho vyšla podle nějakých benchmarků podobná věc, jako tady píší ostatní - XFS nebo EXT4. A protože EXT4 je rozšířenější a běží na ní i zbytek systémů, zvolil jsem ji. Propadlo BTRFS, to bych pro DB nedoporučoval.
Co může být pro ostatní užitečný parametr, tak možnost rozšířit partition, když dochází místo. Partition pro DB vždycky stavím nad LVM, aby to šlo snadno. EXT4 to umí, XFS předpokládám taky, ale doporučuju si to prostě ohlídat.
-
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...
Skvělý kolega.
-
Docela by mne zajímalo, zda se DB nějak přizpůsobily SSD (případně CoW souborovým systémům) – nic takového jsem nezaznamenal (ale je možné, že mne to jen minulo). Konkrétně jestli se DB umí při zápisu na disk (tabulky, indexy) přizpůsobit tomu, že zapisuje na disk, kde seek není penalizován – a DB by vynechala „složitost“ související se snahou nefragmentovat data. (A druhá věc je, zda se DB přizpůsobuje velikosti bloků na SSD, které – alespoň dříve – typicky bývaly větší, než bloky souborového systému.)
Zdaleka neznám všechny databázové servery, ale myslím, že to bohužel zůstává pořád na adminovi nebo možná dnes i adminovi s ChatGPT :)
Každý ten engine má už relativně dlouho konf. parametry, které ovládají nějakou formou paralelismus při I/O operacích, co se dá potencionálně zvýšit při použití na SSD.
Také můžete narazit na možnost ladit query planner tak, aby víc preferoval buď náhodný, nebo sekvenční přístup.
Většinou je to formou nějakého vážení (U Oracle je to volba optimizer_index_cost_adj, u Postgresu pak třeba random_page_cost resp. seq_page_cost), u některých workloadů to může hrát roli.
Nakonec tam mohou opravdu být i specifické optimalizační mechanismy primárně pro točivé disky, což je asi to, na co jste narážel. Např. innodb_random_read_ahead nebo innodb_flush_neighbors. Tam třeba nějaké změny byly, innodb_flush_neighbors byl u MySQL 5.x ve výchozím stavu povolený a od MySQL 8 to musíte explicitně zapnout.
MariaDB jde trochu dál. Nejen že to není ve výchozím nastavení povoleno, ale snaží se opravdu detekovat SSD a když se jí to povede, tak volbu ignoruje.
https://mariadb.com/kb/en/innodb-system-variables/#innodb_flush_neighbors
To je asi zatím jediné místo, kde je použitá podobná autodetekce.
U těch CoW systémů, tak tam jde o to dohledat, jestli se zbytečně nezapisuje vícekrát, než je nutné, a nezvyšuje WAF. Např. u ZFS a innodb s vypnutím doublewrite mechanismu, tam je to vcelku jasné. U některých jiných voleb to ale může být trochu sporné, viz třeba ten ZFS logbias, co jsem zmiňoval. Jedna věc může být nějaký rychlý benchmark, druhá pak jak ten výkon bude vypadat po dvou letech provozu. Atd.
U toho ZFS a innodb je tam pak ještě další aspekt, který v určitých situacích může hrát roli. A to vyladění velikostí innodb_buffer poolu a ARC u ZFS, resp. nalezení jejich optimálního mixu při dané velikosti RAM a výrazně větší databázi.
Nakonec ty velikosti bloků, to je také relativně komplexní téma, aspoň pro mě.
Vstupuje do toho hodně různých vrstev a subsystémů ovlivňuje to workload atp. V tuhle chvíli jsou, co vím, výchozí hodnoty (4k - Oracle; 8k - Postgres, MSSQL, Firebird; 16k - innodb). Osobně bych se primárně koncentroval na ten workload, výchozí bude asi v pohodě pro valnou většinu věcí, a jakákoliv změna má logicky i nějaké negativum. V určitých situacích, kdy tam bude hodně souběžných krátkých zápisů a modifikací, tak může kratší 4k stránka pomoct, naopak třeba pokud se u nějaké db používá komprese, tak ty delší (32, 64k) můžou znatelně zvýšit její efektivitu. Takže člověk může dojít k různým závěrům,
pokud dělá např. transakčně orientovanou službu s vysokou mírou souběžného přístupu, nebo třeba někam ukládá hromady logů a jednou za čas z toho něco vytáhne.
Nicméně vy jste spíš narážel na velikost db stránky ve vztahu ke konkrétnímu SSD.
Jak jste zmiňoval blok na SSD, tak jste nejspíš myslel stránku, což je standardně nejmenší adresovatelná jednotka na SSD. Blok u SSD pak spíš brán ve smyslu více stránek, co se mažou jedním P/E cyklem, a může mít i několik MB.
U nativní velikost stránky bude asi záležet na generaci SSD, bývalo to 4k, u novějších velkých TLC/QLC disků to může být i 8, 16k. Do systému se to, co vím, žádným standardním způsobem neindikuje, abyste to použil v nějaké autodetekci. Některá pokročilejší NVME SSD mají možnost přes standardní namespace id-ns zjistit, že podporují víc režimů komunikace s hostem (např. 4k - výchozí, 8k - optimální). Následně se pak dá režim SSD přes nvme format příkaz změnit (destruktivně!).
To přepne vnitřní režim SSD, který do té doby typicky fungoval na úrovni tzv. sub-pages, a do hosta se indikuje nová velikost fyzického sektoru.
Pak se třeba dá zvětšit i velikost log. bloku na novém FS (tam myslím i dokonce nějaká autodetekce bude) a následně i porovnat s délkou stránky v DB. Pokud bude stránka stejně dlouhá nebo delší než na FS resp. u fyz. sektoru, fajn. Jestli bude kratší, pak bych režim disku nejspíš nechal být.
Motivací k tomu přepnutí by mohla být efektivnější činnost všech vrstev. Nicméně reálný výkonnostní dopad by se pak samozřejmě musel ověřit.
Nejspíš, a to už se dívám za roh, by se mohl snížit WAF v hardware. Pokud to SSD podporuje reportování zapsaných dat na úrovni buňek i to se dá samozřejmě zjistit s nějakým referenčním workloadem.
-
Navážu ještě obecně na ty SSD. Resp. proč si nemyslím, že by provoz s tou emulovanou velikostí bloku byla nutně až tak zásadní tragédie. Nebo, že by bylo zásadně nutné se zkusit vždy trefovat s délkami zápisů do nějakých interních struktur v SSD (page, stripe napříč čipy, neřkuli P/E blok). Ano samozřejmě pokud ta optimalizace nic nestojí, a je to úplně evidentní, směle do toho. Na druhou stranu, pokud je to na hraně a člověk si není jistý benefity, tak to nechat být.
Ano můžou se najít některé návody, kdy to trefování třeba velmi pomůže, dost často např. na laciných dram-less SSD.
Stejně tak třeba chybně vyvodit, že když to člověk neudělá, tak mu za půl roku chcípne SSD, protože razantně zvýší WAF v hardware.
Tady je na místě připomenout jeden aspekt, který občas zapadá. Když výrobce SSD specifikuje výdrž (TBW, DWPD), tak pokud to neuvede jinak, tak je podle daných JEDEC standardů 218, 219 přesně definovaný workload.
Pro serverové disky je to náhodný zápis, náhodných dat (kvůli kompresi) a přesně daná distribuce délek zápisů. Teď z hlavy je tam 2/3 zápisů s 4k délkou, 1/10 s 8k délkou, zbytek nějaký definovaný mix různých délek. Výdrž se udává ve velikostí zápisů z hosta (ne do buněk) a využije se celá logická kapacita disku.
Tzn. tenhle údaj už má v sobě kompenzovaný WAF v hardware s tímhle konkrétním workloadem.
Není to tak, že by na to někdo sypal v sekvenčním zápisu, a s blokem tak, aby to bylo "příjemné" pro SSD (pak je ta výdrž ještě vyšší).
Takže pokud je někdo schopen aspoň nahrubo odhadnout (nebo extrapolovat z měření, simulace) množství zápisů za den, neměl by být extra překvapený. A ve většině případů to se slušnými disky je naprosto v pohodě, mimo nějakých extrémních workloadů. SSD používám na serverech asi 12 let (tzn. tak tři generace disků) a na problémy s výdrží jsem během celkové životnosti serverů nenarazil i na relativně dost exponovaných místech.
Ano viděl jsem i SSD, která se přepnulo do R/O a mělo wearout 100%. Ale to šlo o vyloženou blbost, kdy někdo použil nejlacinější SATA SSD (level - upgrade notebooku pro sestřenici) na vytěžovanou cache s metadaty.
-
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.)
Přesně tak, jak se BTRFS dojebe tak je makačka to dát dokupy :(
-
SAP HANA pro své partitions s logy a daty požaduje XFS
-
Přesně tak, jak se BTRFS dojebe tak je makačka to dát dokupy :(
Ťukám, zatím se mi nestala situace, ze bych se z něčeho standardními nástroji nedostal a přišel o data. Ale jakože bych za to dal ruku do ohně :)) Měl jsem to s BTRFS na etapy, vždycky jsem si to zhruba po dvou letech vyzkoušel, nejdřív super skvělé, subvolumes, snapshoty a končilo to typicky tím, že to přestalo reagovat, koukal jsem na backtracy z kernelu a přemýšlel, jestli na to mám ještě hledět, nebo už to PC můžu vzít tlačítkem power a jít si lehnout. Pak vždycky zpátky na zem, a zas pauza :)
Ale je fakt, že ten základ se asi ustabilizoval. Když si člověk najde aplikaci, kde to nedělá zásadní potíže a vyhne se problematickým věcem jako je třeba ten multi-device, dá se s tím existovat.
Jak jsem zmiňoval, přijde mi to fajn na rolling distribuce, nebo věci, co se i v případě zásadního problému dají v podstatě rychle deployovat znovu.
Krom postupného vychytávání chyb se taky přizpůsobily výchozí nastavení (např. dup profil na metadata) a distribuce mají obvykle naplánovanou periodickou údržbu FS s nějakým rebalancem. Do toho jsem si samozřejmě u pokusů předtím šlápl taky, klasika volné místo a nejde zapisovat.. Pak jsem taky chvíli uvažoval, jestli jsem si místo s BTRFS neměl hrát s Tamagoči, které se taky vyznačovalo tím, že když se mu nedalo najíst a nepohladilo se, tak samo chcíplo.
Je tam sice pár věci, co mě pořád štvou, třeba dlouhé výtuhy při povolených kvótách s práci se snapshoty atp., ale nakonec to nějak jede, PCčka, Synology, kontejnery atp.
Nicméně i přesto, pro dedikovaný db server bych BTRFS fakt asi neřešil. I kdyby s tím nebyly žádné potíže, tak tím jak je to teď relativně neefektivní s krátkými random přepisy, bych to fakt neřešil pro nic jiného než nějaké malé, nenráročné db.
Straight from the horse's mouth, BTRFS guru Mr. Bacik:
https://www.percona.com/blog/taking-a-look-at-btrfs-for-mysql/#comment-10973474
-
Docela by mne zajímalo, zda se DB nějak přizpůsobily SSD (případně CoW souborovým systémům) – nic takového jsem nezaznamenal (ale je možné, že mne to jen minulo). Konkrétně jestli se DB umí při zápisu na disk (tabulky, indexy) přizpůsobit tomu, že zapisuje na disk, kde seek není penalizován – a DB by vynechala „složitost“ související se snahou nefragmentovat data. (A druhá věc je, zda se DB přizpůsobuje velikosti bloků na SSD, které – alespoň dříve – typicky bývaly větší, než bloky souborového systému.)
Prizpusobovat se SSD nestoji za namahu. Oracle i Postgres maji uz od pradavna parametry optimizeru pro nahodne a sekvencni cteni. Takze se dokazi v pohodo SSSD prizpusobit. Pokud uz se to predelava, tak se to prepise kompletne.
AWS Aurora - klon Posgresu - nepouziva WAL logy pro replikaci, a pri zapisu na "disk" pouziva API EFS filesystemu.
Oracle pouziva pluginy pro zapis na ruzne "disky". Jeden plugin treba umi "direct NFS", coz je userspace klient pro NFS. Oracle Exadata pouzivala Infiniband, kdy cluster nekolika DB serveru pozival zapis do clusteru nekolika "cell serveru". Dneska to pokrocilo o kousek dal a z Infinibandu se vyvinulo "RDMA - remote DMA". Tahle technologie umi prenest data z pameti jednoho serveru na druhy, bez toho aby se toho ucastnil OS anebo CPU s minimalni latenci. Krome Infunibandu je tu jeste "RoCE" - RDMA over Converged Ethernet.
Takze bych rekl, ze databaze se spis prizpusobuji tomu, ze nebudou mit zadne disky, a misto toho budou komunikovat s nejakou distribuovanou sitovou sluzbou.
-
Docela by mne zajímalo, zda se DB nějak přizpůsobily SSD (případně CoW souborovým systémům) – nic takového jsem nezaznamenal (ale je možné, že mne to jen minulo). Konkrétně jestli se DB umí při zápisu na disk (tabulky, indexy) přizpůsobit tomu, že zapisuje na disk, kde seek není penalizován – a DB by vynechala „složitost“ související se snahou nefragmentovat data. (A druhá věc je, zda se DB přizpůsobuje velikosti bloků na SSD, které – alespoň dříve – typicky bývaly větší, než bloky souborového systému.)
Prizpusobovat se SSD nestoji za namahu. Oracle i Postgres maji uz od pradavna parametry optimizeru pro nahodne a sekvencni cteni. Takze se dokazi v pohodo SSSD prizpusobit. Pokud uz se to predelava, tak se to prepise kompletne.
AWS Aurora - klon Posgresu - nepouziva WAL logy pro replikaci, a pri zapisu na "disk" pouziva API EFS filesystemu.
Oracle pouziva pluginy pro zapis na ruzne "disky". Jeden plugin treba umi "direct NFS", coz je userspace klient pro NFS. Oracle Exadata pouzivala Infiniband, kdy cluster nekolika DB serveru pozival zapis do clusteru nekolika "cell serveru". Dneska to pokrocilo o kousek dal a z Infinibandu se vyvinulo "RDMA - remote DMA". Tahle technologie umi prenest data z pameti jednoho serveru na druhy, bez toho aby se toho ucastnil OS anebo CPU s minimalni latenci. Krome Infunibandu je tu jeste "RoCE" - RDMA over Converged Ethernet.
Takze bych rekl, ze databaze se spis prizpusobuji tomu, ze nebudou mit zadne disky, a misto toho budou komunikovat s nejakou distribuovanou sitovou sluzbou.
Postgres Neon https://neon.tech/ se snaží o takovou architekturu. Jinak samozřejmě Aurora Postgres a Aurora MySQL.