Zobrazit příspěvky
1
Server / Re:Rychlé úložiště pro virtualizaci
« kdy: 02. 12. 2023, 18:35:17 »
Pár poznámek k této diskuzi:
O tom že bude HW RAID rychlejší než zfs si také nejsem jistý. Ta cache tam není jako nějaká zázračné zrychlení ale spíš na odstranění problémů které má HW RAID a RAIDZ ne (RAIDZ má vlastní problémy). Zde je zajímavý článek od jednoho z autorů zfs o RAIDZ. RAIDZ totiž není jen cool název pro RAID5/6 ale interně je to úplně jiný raid.
https://web.archive.org/web/20111214214904/http://blogs.oracle.com/bonwick/entry/raid_z
Občas se to hodí jako rychlý hotfix výkonu například u HDD NAS kdy se větší část čtení odbaví z SSD.
https://letsencrypt.org/2021/01/21/next-gen-database-servers.html
Citace
3x mirrorovaný SLOGZde bych upozornil na málo známý fakt že SLOG stačí jen o velikosti jednotek GB. Praktické maximum jsou 4GB. A SLOG sníži jen latenci, nezlepší propustnost a funguje jen u synchronních zápisů.
Citace
- ZFS nad RAID5 (to mě sice obere o část výhod ZFS, ale výhodou je rychlost RAID5)Hlavní problém je že přijdete o ochranu před bitflipem na disku. Pokud dojde k bitflipu tak HW raid to neumí detekovat a předá vadná data ZFS. A ZFS sice detekuje že jsou data poškozená ale když vidí jen hw raid tak nemůže ty data opravit.
O tom že bude HW RAID rychlejší než zfs si také nejsem jistý. Ta cache tam není jako nějaká zázračné zrychlení ale spíš na odstranění problémů které má HW RAID a RAIDZ ne (RAIDZ má vlastní problémy). Zde je zajímavý článek od jednoho z autorů zfs o RAIDZ. RAIDZ totiž není jen cool název pro RAID5/6 ale interně je to úplně jiný raid.
https://web.archive.org/web/20111214214904/http://blogs.oracle.com/bonwick/entry/raid_z
Citace
ZFS a "dost rychle uloziste" se vetsinou nevyskytuje v jedne vete (podotykam, ze ja mam ZFS vsude, nejsem antifan). A tyhle diskuse se vzdy zmeni v alchymistickou diskusi "tajnych kombinaci parametru"S tím většinou nemám problém. Ve většině případů se mi podaří vyladit ZFS že je rychlejší než ext4. Někdy i výrazně. Ale ano, je to alchymie s parametry modulu, parametry datasetu a případně způsobem vytvoření poolu a výsledek není jistý
Citace
p.S. zazracne pomoci by mohlo ZFS Metadata Special Device. Ja se toho bojim a bez trojiteho miroru bych se k tomu ani nepriblizil.Jo, special device to umí hodně zrychlit. Ale určitě bych se ho nebál. Trojitý mirror nemá smysl. V tomto případě když se řeší RAID5 odolný proti výpadku jednoho disku tak nemá smysl míd metadata odolná proti výpadku 2 disků. Provozuji i RAIDZ2 (odolný proti výpadku 2 disků) s metadaty v mirroru. Protože zfs umí od verze 2.0 sekvenční rebuild. Takže pokud by mi odešel jeden z SSD disků s metadaty tak se rebuild toho mirroru provede sekvenčně a tedy rychlostí SSD (450-500MB). Takže redundanci mám obnovenou za čtvrt hodiny. A většinou vím podle smartu včas že SSD odchází tak udělám dočasně mirror ze 3 disků a pak ten opotřebený odeberu.
Citace
Takze muzes vyvodit z rozhodovaciho Matrixu L2ARC, je to jen cool slovo. Vsechny ty "solidni ZFS Cache" tam jsou, aby kompenzovaly straslivy dopad ZFS na vykon, nejsou primarni benefit ZFS.L2ARC se hodí pokud víme velikost working setu se kterým se často pracuje. Pak můžeme dát tak velkou L2 cache aby se to do ní vešlo. Ale zase je to docela alchymie. L2ARC má své hlavičky v ARC. Takže když se dá neadekvátně velká L2 cache tak se významně sníží použitelná ARC cache a to může mít naopak negativní dopad na výkon.
Občas se to hodí jako rychlý hotfix výkonu například u HDD NAS kdy se větší část čtení odbaví z SSD.
Citace
ZFS se umí vypořádat s vadnými sektory, dopočítává kontrolní součty, řeší CRC v průběhu celé životnosti dat...proto je logické, že to má nějakou významnou režii. Jen nemám představu jak moc...To je pravda, režie tam je a není úplně malá. Zase na druhou stranu zfs má integrovanou kompresi a například u DB se běžně dostávám na kompresní poměr větší než 2. To výrazně pomáhá. Zapíše se méně dat a kvůli tomu že data v ARC jsou komprimovaná tak se do ARC cache vejde víc logických dat což pomáhá při čtení.
Citace
Každý čtený blok jde do ARC, což je v podstatě na úrovni Least Recently Used cache.Na tak úplně. ARC opět není jen ZFS cool název pro LRU. ARC cache algoritmus byl vyvinutý nezávisle na ZFS a ZFS ho jen jako jediné využilo. Hlavní rozdíl je že ARC je složeno z MRU (most recently used) a MFU (most frequently used) cache a interně vyvažuje poměr mezi těmito cachemi podle toho jaký mají hitrate. Tím že bere úvahu i frekvenci použití tak dosahuje výrazně vyššího hitrate než cache v kernelu. Navíc kvůli tomu je scan resistent, ted jednorázové čtení nějakých jindy nevyužitých dat nezaplní ram zbytečnými daty a nesníží hitrate.
Citace
Nejspíš - někdy - lze ve výchozích nastaveních dospět ke stavu, kdy je databáze 2-3x pomalejší než na EXT4.Například Lets Encrypt si svoji novou DB postavil na ZFS s 24xNVMe, 2TB RAM a 2x64c EPYC. a hodně si to tam chválí. A je tam i proklik do gitu kde mají tunning pro zfs i mysql který používají.
https://letsencrypt.org/2021/01/21/next-gen-database-servers.html
Citace
Zajímavé je, že těch lidí ohledně výkonu ZFS brblá poměrně dost. A pak jiní lidé pouští podobné testy a jejich výkony jsou naopak lepší nebo stejné jako u EXT4.Tohle je například tím že zfs má defaultní record_size 128kB a mysql má v inndob pagesize 8kB. Takže pokud vezmu defaultní nastavení zfs a rozjedu nad tím mysql tak bude amplifikace zápisu 16x. S něčím sice pomůže komprese ale i tak ten výkon bude tragický. Pokud ale snížím recordsize například na 16kB (sweet spot mezi malým recordsize které snižuje write amplification a velkým recordsize které zlepšuje kompresi) tak se při zapnuté kompresi dostanu na rychlosti jako má ext4 nebo lepší (samozřejmě existují patologické případy kdy je zfs pomalejší). Druhá věc je že například zfs umí atomicky modifikovat data až do velikosti record_size. Takže je bezpečné vypnout doublewrite v mysql protože se oproti ext4 nikdy nestane že by se z 8kB InnoDB stránky zapsala jen první polovina a druhá zůstala stará (například kvůli pádu serveru uprostřed zápisu).
)