Write bariéry umožňují využití diskové cache (resp. cache nezálohované baterií obecně) bez rizika nebezpečného poškození souborového systému. Podporuje-li to souborový systém a používáte-li zálohovanou cache (např. akumulátorem), můžete write bariéry bez obav vypnout - získáte tak výrazně vyšší výkon, jak je vidět z tohoto obrázku

Je zřejmé že zejména pro menší databázové bloky je zisk oproti výkonu se zapnutými write bariérami značný (až 100%), a to byla použita jen velmi malá cache (32MB přímo na disku). Současně se výrazně zvětšil rozdíl mezi malými a velkými databázovými bloky.

I z výše uvedených obrázků je zřejmá určitá anomálie v levém horním rohu, kdy se tři kombinace velikostí bloků chovají výrazně jinak. Zajímavé je že s využitím write bariér je chování přesně opačné než když použity nejsou. Například u souborového systému ext3-ordered se zapnutými write bariérami je chování takového

tj. výkon v levém horním rohu (mírně) klesá, zatímco v případě jejich vypnutí je chování takovéto

tj. výkon v levém horním rohu velmi výrazně roste. Toto chování vykazují všechny varianty souborových systémů ext3 a ext4, byť v "journal" módu se zapnutými write bariérami je pokles téměř neznatelný

Podobně se ale při vypnutých write bariérách chová např. i XFS

Úspěšnost databázové cache

Podíváme-li se na úspěšnost databázové cache, tj. procento databázových bloků nalezených v shared buffers (tj. bez nutnosti načítat je z disků) je velmi vysoká - dokonce výrazně vyšší než v případě read-only zátěže, kde se pohybovala mezi 60% a 70%.

Stejně jako v případě read-only zátěže je maximální úspěšnosti dosahováno pro 2kB bloky, závislost na velikosti databázového bloku je ale výrazně nižší - hodnoty se pobyvují zhruba v intervalu 2% (u read-only zátěže byl interval cca 10%).

Průběh tps

Zatímco u read-only zátěže se pro jednotlivé souborové systémy průběh TPS během benchmarku nijak výrazně nelišil, v případě read-write zátěže se chvání jednotlivých souborových systémů poměrně výrazně liší. Podívejme se tedy podrobněji na jednotlivé souborové systémy - pro základní srovnání byla zvolena standardní kombinace bloků (4kB pro souborový systém, 8kB pro databázi).

Je zajímavé sledovat zejména několik základních věcí

• Jak se souborový systém chová v okamžiku kdy běží checkpoint?
• Jak se souborový systém chová v okamžiku kdy neběží checkpoint?
• Je výkon stabilní nebo výrazně fluktuuje?

Všechny obrázky jsou pro případ se zapnutými write bariérami - pokud vás zajímají výsledky s vypnutými bariérami, najdete je tady.

Ext2

V případě "tradičního" linuxového souborového systému je chování poměrně nepříznivé, tj. v okamžiku checkpointu dochází k velmi znatelnému poklesu výkonu (ze 150 na necelých 20 tps)

přitom ale pro jiné velikosti bloků je chování výrazně příznivější - například pro 16kB databázové bloky je chování takovéto

tj. výkon sice výrazně fluktuuje okolo 90 tps, nedochází však k natolik brutálnímu poklesu jako u 8kB bloků. Zajímavé také je že k fluktuaci dochází již před zahájením checkpointu a přetrvává i po jeho skončení ...

ext3

V případě ext3 (a také ext4) je třeba brát v potaz také žurnálovací mód. Pokud je zvolen nejnižší mód (data=writeback), graf vypadá takto

přičemž při zapnutí žurnálování (data=ordered) se sice nezmění chování mimo checkpoint (tps zůstává zhruba na hodnotě 120), během checkpointu je ale znatelný pokles výkonu (a vyšší rozptyl transakcí).

No a konečně při zapnutí plného žurnálování (data=journal) poklesne tps ze 120 na 80, a současně dochází k výraznějším výkyvům během checkpointu.

Obecně se ale dá říci že mne chování ext3 příjemně překvapilo - čekal jsem horší.

ext4

Souborový systém ext4 je víceméně potomek ext3, vylepšující např. chování během checkpointu a využití write bariér. Má tedy stejné módy žurnálování - "data=writeback" se chová téměř stejně jako u ext3 (ale dosahuje mírně lepších výsledků)

zatímco "ordered" je ve srovnání s ext3 výrazně plynulejší (v podstatě se rovná "writeback" módu ext4)

V módu "journal" se chování v podstatě přesně shoduje s ext3, i když je o trochu učesanější.

Takže ano, vypadá to že ext4 je krok správným směrem, byť relativně malý.

XFS

Souborový systém XFS je od začátku navržen jako žurnálovací (tj. nejedná se o hybrid jako souborové systémy z "ext" rodiny). Uplatňovaná omezení jsou ale spíše slabší a srovnatelná s "writeback" módem ext3/ext4. Chování XFS vypadá takto:

Je zřejmé že dosahuje o něco nižšího výkonu než ext3/ext4 (cca 100 tps oproti 130 tps) a to samé platí pro "ordered" mód. Ale když běží checkpoint, je chování daleko lepší (vyšší výkon, menší kolísání). Při srovnání s ext4-journal je xfs o něco rychlejší i v době kdy checkpoint neběží (asi 100 tps oproti 80 tps).

Poznámka: Původní srovnání s ext4-journal a závěry byly poněkud matoucí, na což poukázal intgr (viz. komentář pod anglickou verzí článku).

jfs

Dalším "nativně žurnálovacím" souborovým systémem je JFS, nemá ale takovou podporu ani aktivní vývoj. Výkon v době kdy neprobíhá checkpoint vypadá velmi zajímavě (140 tps je výrazně vyšší než hodnota 100 tps dosažená u XFS), ale v době checkpointu je znatelný značný pokles výkonu:

Chování v době checkpointu ale výrazně závisí na velikosti databázového bloku - např. po snížení na 4kB se chování změní takto:

I tak se ale jedná o velmi špatné chování - fluktuace výkonu je velmi výrazná, zejména ve srovnání s chováním XFS a ext3/ext4.

ReiserFS

Chování ReiserFS je poměrně zajímavé a do jisté míry ho lze srovnat s ext4 a xfs - výkonem se blíží xfs ale kolísáním v době checkpointu spíše ext3/ext4.

Tím jsem vyčerpal "tradiční" souborové systémy a na řadu přicházejí dva souborové systémy označené jako "experimentální" - btrfs a nilfs2.

btrfs

Btrfs má dva základní módy, podle toho zda se používá "copy-on-write" - nejdříve se podívejme na případ kdy se copy-on-write nepoužívá, tj. případ kdy btrfs připomíná standardní souborové systémy

Toto chování velmi připomíná chování ext4-journal, a to jak chováním mimo checkpoint tak během něj. Podíváme-li se ale na chování se zapnutým "copy-on-write," čeká nás překvapení

nejen že se nijak nesnížil výkon, výrazně se zlepšilo chování během checkpointu, a to tak že se v podstatě neliší od výkonu mimo něj. Neptejte se mne jak to v Oracle udělali ...

nilfs2

Druhým experimentálním "log-based" souborovým systémem (společně s btrfs) je nilfs2, vyvíjený NTT. A stejně jako u btrfs to vypadá více než zajímavě:

Chování sice není tak vyrovnané jako u btrfs, ale i zde je zřetelné velmi positivní chování během checkpointu. Na začátku má dokonce výrazně lepší výkon než btrfs a pokud se vývojářům v NTT podaří odstranit postupný pokles, bude to velmi zajímavá možnost.

Každopádně potenciál tu je, protože pro menší databázové bloky je chování výrazně lepší - například pro 1kB bloky vypadá takto

což vypadá velmi slibně. Svou roli ale nepochybně sehrává také nastavení background writeru, která v případě 1kB bloků vlastně zapisuje 8x méně dat než v případě 8kB bloků.

Překvapení

Prvním překvapením je, stejně jako u read-only zátěže, že nodatacow varianta btrfs (tj. s vypnutým copy-on-write) je pomalejší - opět sice ne příliš, ale je.

Skutečná výhoda nodatacow se projevuje pouze v případě vypnutých write bariér, kde je nodatacow varianta skutečně výrazně rychlejší

Závěr

Na závěr si (stejně jako u read-only zátěže) dovolím uvést několik jednoduchých pravidel

• Nemá smysl používat malé velikosti bloku souborového systému - blok 4kB nemusí znamenat lepší výkon (např. u ext4-ordered), v podstatě nikdy ale znatelně výkon nesnižuje.
• V případě zapnutých write bariér je optimální velikost databázového bloku 4kB  (resp. je shodná se zvolenou velikostí bloku souborového systému), ale rozdíly při změně velikosti bloku jsou relativně malé.
• S vypnutými write bariérami je optimální velikost databázového bloku okolo 2kB a s rostoucí velikostí databázového postupně klesá. Na rozdíl od read-only zátěže ale k hlavnímu poklesu výkonu nedochází mezi 8kB a 16kB bloky, ale již mezi 2kB a 4kB.
• Ext4 a XFS jsou dobrou volbou mezi stabilními souborovými systémy. Velmi slibně ale vypadají také oba experimentální souborové systémy - btrfs a nilfs2.