Dotaz: IOPS na btrfs

[lertimir]

Přílohy:

• diskstats_iops-day.png (44123 bytů)
• diskstats_throughput-day.png (46775 bytů)

Ví tu některý z btrfs guru, jak se dají ovlivňovat IOPS na FS? PRoč se ptám. Kopíruji archiv svých fotek na externí disk pro zálohu a uchování mimo byt a protože dělám kontinuální monitoring všiml jsem si velkého množství IOPS na čteném systému (soubor iops).

Situace: zdroj: btrfs raid1 na 4 discích

Label: 'archiv'  uuid: d1722103-0c1e-4627-bbc7-9f1f0bf91739
        Total devices 4 FS bytes used 4.56TiB
        devid    1 size 3.64TiB used 3.30TiB path /dev/mapper/archiv
        devid    2 size 3.64TiB used 3.30TiB path /dev/mapper/com
        devid    3 size 1.36TiB used 1.03TiB path /dev/mapper/miraza
        devid    4 size 1.82TiB used 1.49TiB path /dev/mapper/securestorage

cíl: extení disk USB 3.0 připojený jako sdo má ntfs filesystem. Kopírování rsync -av zdroj cíl To co mne zaráží je mrňavé požadavky na IOPS pro zápis na ntfs a naopak obrovské IOPS, které se koncentrují do disku com. Soubor throughput ukazuje, že co se přečte, to se zapíše. mount btrfs je

/dev/mapper/archiv                              /disky/archiv             btrfs   commit=100,defaults 0 0

(v mount je type btrfs (rw,relatime,space_cache,commit=100,subvolid=5,subvol=/) ) a ntfs je standardní automount(v mount je type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)) Případně jak pole mountnout aby výkon byl větší (každý /dev/mapper toho pole je LUKS2 volume)

Odpovědi

[debian+]

rsync --size-only

[j]

To ale nema moc spolecnyho s FS (byt btrfs muze byt trosku narocnejsi, kvuli fragmentaci vznikajici pri CoW a pripadne vyuzivani snapshotu) ... co myslis ze ten rsync dela. On musi precist informace o vsech souborech, ale zapsat jen zmeny.

Naopak kdybys mel btrfs na obou stranach, tak se tomu paradne vyhnes, protoze ti staci prenaset snapshoty => neresis co se zmenilo, protoze to vis.

[Heron]

Naopak kdybys mel btrfs na obou stranach

Pokud je to záloha, tak je dobré mít pro zálohu jiný FS než na zálohovaném systému. Kdyby byl bug v kernel modulu daného FS, který by ten FS zničil, tak ti to zničí jak originální FS tak i zálohu. Takže jiný FS je zde na místě. (Otázkou je proč zrovna NTFS přes fuse...)

[Heron]

A v čem je vlastně problém?

To co mne zaráží je mrňavé požadavky na IOPS pro zápis na ntfs a naopak obrovské IOPS

Ano, tohle je docela běžné, protože pro zápis se používá mnoho technik pro odložený zápis, aby si to FS mohl srovnat v paměti a zapsat to co nejefektivněji.

Při čtení těch souborů se příliš optimalizovat nedá, program ty soubory čte v neoptimalizovaném pořadí (protože ho ani nemá jak zjistit), FS musí vyhledat soubor v adresářovém stromu a FS musí vyhledat polohu bloků daného souboru v inodě. Tzn při náhodném čtení mnoha souborů je tam těch IOPS víc než při zápisu, kdy to FS může zapsat všechno naráz (po větších celcích). (Jaké přesně má optimalizace NTFS nevím, ale výše popsané platí třeba pro XFS nebo pro ext4 - delayed allocation).

které se koncentrují do disku com

Podle obsazeného místa soudím, že v tom raid1 byly nejdřív disky archiv a com, které jsou plné a potom se tam přidaly ty dva další disky. Tedy ty fotky budou asi zřejmě uloženy pouze na devid 1 a devid 2 a btrfs je čte pouze z jednoho disku (proč taky ne).

Celkově na té situaci nevidím nic zvláštního (teda až na poměrně creativně pojmenované disky v tom r1).

[lertimir]

Při čtení se optimalizovat moc nedá pokud se čtou dost malé soubory, ale obsah toho zálohování byly fotky, Typická velikost souborů byla 1-4MB u jpg 20-30MB u raw. Fakticky jsem dosáhl rychlosti jen asi 50-60 MB/s což mi připadalo trochu málo. Limitace nebyla na straně USB z jiného disku jsem tam několikrát přihazoval zápis nizkách desítech GB a zápis se na tu chvili zvýšil na 120MB/s. 1k iopsů mi připdá, že to četl po velmi malých kouscích a přimět jej aby alokaci dělal po vetších kusech.

[Heron]

Fakticky jsem dosáhl rychlosti jen asi 50-60 MB/s což mi připadalo trochu málo.

No pokud tam jsou soubory o velikosti 1MB a ten disk předpokládám 7200rpm, tak pro každý soubor je potřeba přečíst inode a potom začít číst bloky toho souboru. Tj 2 operace per soubor (a to jen pokud není fragmentovanej). 60*2 = 120 IOPS, což přesně odpovídá 7200rpm (7200rpm/60s = 120IOPS). Čtení těch rawů by mělo jít rychleji.

Ono taky záleží, kde na tom disku ta data jsou, protože rychlost čtení rotačního disku na obvodu disku je nejrychlejší (to jsou úžasné hodnoty v testech) a potom to ke středu disku klesá docela znatelně. Tj disk zvládající 140MB/s může u středu klidně spadnout až pod 80MB/s.

[lertimir]

Příloha:

• memory-day.png (52025 bytů)

No reálně se rychlost nezměnila na jakékoliv velikosti souborů. V tom grafu je 1k IOPS, ne 120 takže to čte po menších kvantech než je soubor. Fakticky těch 1MB je menší množství souborů, to jsou jpeg fotky se starého 300D jpeg 1MB raw 6MB, pozdější 5dMarkII dává 4,5MB jpegy a 30 MB. V tom dotazu mi primárně šlo o to, jak se dostat na číslo řádově tech 120, ostatně ani to inode by nemusel číst při každé operaci, ale načíst si dopředu nějaký blok. ještě přihazuji graf paměti. operace je tam ještě vidět, začíná v út cca 18:00 a z 24 GB systému naalokoval asi 2-3GB na buffery, ale na rychlosti čtení to nepomohlo

[j]

Samosebou ze to necte po souborech, cte to po sektorech. A ty sou u starsich/mensich disku velky 512B, u novsich a vetsich 4kB. To je presne ta jednotka, ktera ti generuje jednu IO operaci.

Pochopitelne pri nizky fragmentaci a vicemene linearnim cteni na tom muzes neco malo vytezit, ale ten vliv neni ve finale nijak zasadni, pocet IO ktery ti da disk nezmenis a prave to je limitujici faktor pri naprosto drtivy vetsine operaci s ulozistem. Spickovej 15k disk je schopen atakovat hranici 200 IOps. Vic z mechanickyho disku nedostanes.

V pripade raidu se ti pak ty dosazitelny IOps pro cteni ve vsech pouzivanych variantach (tzn R1/10/5/6) nasobej poctem disku (tady jen pozor na to, ze nikoli v pripade widloraidu). Pro zapis je to min v zavislosti na typu raidu.

Jinak disk si pochopitelne umi optimalizovat cteni, bezne to funguje tak, ze mu system da seznam logickych sektoru ktere chce cist, elektronika disku si to prevede na sektory fyzicky a pak muze prehazet poradi cteni tak, aby hlavicka postupovala z jednoho okraje na druhy a nelitala tam a zpet.

[Heron]

ostatně ani to inode by nemusel číst při každé operaci

Psal jsem per soubor. Program si vyžádá data souboru, FS se musí podívat na to, které bloky má přečíst (tj v inode) a potom je začne číst. To jsou dvě operace. Navíc je to btrfs, takže by si měl na druhém disku číst ještě checksum a porovnávat jej s těmi čtenými daty. Tj další operace, ale na druhém disku.

[lertimir]

Myslel jsem to tak, že by přečetl balík inode dopředu a ty měl v paměti a pak už je jen z paměti vybral. Přece jen je to na stroji s 24GB paměti. Celkem se četlo a kopírovalo 100 000 fotek v 900 adresářích o velikosti asi 800 GB. A patrně dost inode už bylo také v paměti, protože jsem s fotkami už pracoval. Nyní po kopírování i když uběhl další den jsou v paměti všechny inode a jakékoli zjištování přes du je pod vteřinu

 time du -a * | wc -l   
105632
du -a *  0,10s user 0,42s system 99% cpu 0,524 total
wc -l  0,03s user 0,31s system 64% cpu 0,523 total

[Heron]

Myslel jsem to tak, že by přečetl balík inode dopředu a ty měl v paměti a pak už je jen z paměti vybral.

Pro x různých souborů? Ten FS neví, které další soubory bude ten program po něm chtít.

Jasně, kdyby existovala možnost tomu fs říct: "připrav si všechny tyhle soubory, za chvíli je po tobě budu chtít", tak je to jiná. Ale FS tohle neumožňuje.

[Peter Golis]

Tie zdrojové disky sú zaplnené na približne na 90%. Pri akom zaplnení sa začne prejavovať zníženie výkonu kvôli fragmentácii?

Len sa pýtam, či to nebude zdroj problému.

[debian+]

Vytvor 2GB odiel a otestuj ;)

[Peter Golis]

Pošli SD kartu.

BTRFS ma bude zaujímať keď bude mať na priamo vstavanú deduplikáciu na pozadí, ako to má napr. ZFS.

[j]

Ktery sice jen tak aby se nereklo ztraci data, ale hlavne ze deduplikuje .... a bonusem, potrebujes na kazdy 1TB kapacity 8GB ram, nejde pridat (natoz odebrat) disk a vubec ma spoustu dalsich uzasnych vlastnosti ...

Apropos, mas predpokladam uloziste ktery je schopny davat setrvale aspon 10k IOps.

15ti diskovy uloziste s bezici deduplikaci (nikoli zfs shit) dava pri cteni (a ty bezici deduplikaci) cca 10MB/s ... max. Coz je uchvancancujici predevsim v okamzik, kdy z toho chces neco obnovit. Tech 15 disku da neco kolem 2k IOps.

[Peter Golis]

Tak to si veľmi dobre nakúpil, len čo je pravda.

[Max]

To, kolik je potřeba ram, lze jednoduše vypočítat a při běžném použití by neměl být problém se vejít s dedpu tabulkama do 3GiB ram. K tomu pak je potřeba připočítat klasické režie, ale do 5GiB by to mělo projít snad vždy. 8GiB je už podle mně hodně.
Ale to já jen tak pro info. Každopádně zajímá mně to ztrácení dat při dedup. Osobně dedup nepoužívám a nemám to v plánu, jen mně zajímá nějaký zdroj, abych si početl a případně si dal pozor. Nebo to jsou tvé zkušenosti?
díky
Zdar Max

[Peter Golis]

K tomuto sa prikláňam, ale ja o deduplikáciu mám záujem. Presnejšie povedané o FS s podporou trojkomba deduplikácie, RAID a TRIM/Discard. To zvláda z dostupných riešení len minimum FS.

PS: Deduplikácia na FS bez RAID nemá zmysel kvôli silent data corruption. A prínos RAIDu ktorý je oddelený od FS mi nepríde moc veľký.

[Heron]

Můžu se jen pro zajímavost zeptat co od té deduplikace očekáváš? Ptám se proto, že lidé od toho často chtějí zázraky (nasypu tam sbírku filmů a ono to pár GB ušetří) nebo by bylo lepší použít jiný systém (tj zálohuju 40 skoro stejných VM a ta deduplikace mi ušetří 40x stejná data v OS).

Na úplně obecná data se deduplikace nehodí vůbec, protože těch náhodně stejných bloků bude limitně nula.

Na speciální data, u kterých se předpokládá, že budou stejná, se mnohem víc hodí ta znalost, že jsou stejná a nenechávat to na obecném deduplikátoru bloků.

Možná existuje ještě nějaká třetí skupina dat, na kterou se obecná deduplikace hodí a já o ní nevím, ale obecně jsou náklady na deduplikaci mnohem vyšší než přínosy.

[Max]

Já jsem u dedup přemýšlel jen v jednom případě, dumpy db. Export má 270GiB a full backup má 480GiB. Full se dělá jednou týdně + se uchovávají transakční logy a Export db se dělá jednou denně. Backup + transakční logy držíme na věky a export pár let. Odlévám to na pásky, ale přecijen, poslední měsíc včetně nějaké historie nechávám na storage. Podobně jsou řešeny i jiné db, i když tam už se nedrží taková historie.
Toto je podle mně jeden z mála důvodů, proč by se dedup mohlo vyplatit.
Každopádně v současné době mně to netrápí, jelikož můj ZFS storage má zatím slušnou dimenzaci (pool poskládaný z 4x RAID-Z2 po 8x4TB WD RE4, tzn. 24/7 SATA disky s 7200ot a prodlouženou zárukou, použitelná kapacita tedy přes 80TiB mínus nějaké procentuálně vyžadované volné místo) a jen přemýšlím nad dvěma SSD a do vzduchu se začíná dostávat myšlenka, zda nepostavit druhý storage, aby byl failover zálohy nejen na úrovni disků, ale i na úrovni celého hw.
Zdar Max

[Heron]

Nevím, jak je tomu u Oracle, ale u PG je base backup v podstatě kopie datového adresáře DB. K tomu si uchováváš wal logy.

PG data uchovává v souborech max 1GB velkých. Tj pokud mám 500GB table, mám k ní na disku 500 souborů. Pokud se table příliš nemění (třeba jen insertuje), tak ty 1GB soubory těch různých base backupů jsou stejné.

Tohoto (a dalších vlastností) využívá třeba PGBarman, který dělá pravidelně base backup (tj full záloha) + sbírá wal logy a umí deduplikovat ty base zálohy (pokud to admin povolí). Tj na disku máš jen unikátní 1GB soubory tabulek a hromadu logů a fullku můžeš dělat tak často, jak potřebuješ.

Tohle je právě ta znalost dat, která ti (podle mého názoru) pomůže mnohem víc, než obecný dedup.

[Max]

Oracle má datafile (soubor, ve kterém je db/tabulky a vše okolo) velký podle toho, jak si určíš velký block. Tzn. nějak takto :

 2k: 4194303 *  2k =   8 GiB
 4k: 4194303 *  4k =  16 GiB
 8k: 4194303 *  8k =  32 GiB
16k: 4194303 * 16k =  64 GiB
32k: 4194303 * 32k = 128 GiB

Každopádně je rozumné mít full backup v nějakých intervalech, protože je mnohem rychlejší obnovit full dump a dohrát pár dní transakčních logů, než dohrávat transakční logy třeba za měsíc. Obzvláště, pokud se jede na minimální rollback a každou minutu, někdy i častěji z db padají logy a za den je těch souborů třeba 15 000.
Zase nevím jak PG, ale asi to bude podobné, že dohrávání transakčních logů je opravdu formou aplikování transakcí, což je mnohem náročnější proces než tam sekvenčně naládovat velký binární dump.

Export dat je zase v některých případech výhodný v tom, že se lze dostat k nějaké tabulce z noční zálohy do pár minut. V rámci Oracle existují i jiné možnosti, jak toho docílit (třeba pravidlné snapshoty db, kdy si lze v záložní lokalitě přepínat db do různých časů a zase zpět aniž by došlo ke změně db / porušení aplikace transakčních logů do standby), ale je to zase o licencích.

Takže ano, znalost dat dobrá, ale pokud je tlak mít velkou historii a co nejkratší čas se dostat do nějakého data, tak vše nelze řešit jen achivací transakčních logů.
Zdar Max

[PetebLazar]

Export dat je zase v některých případech výhodný v tom, že se lze dostat k nějaké tabulce z noční zálohy do pár minut.

Pokud tedy rebuild potřebných indexů nad tabulkou netrvá déle než úplná záloha/obnova.

OT: Jak často rotujete s logfile? Činí se tak automaticky až při jejich zaplnění(což by naznačovala frekvence přepínání), nebo máte nastavenu vynucenou rotaci po uplynutí určité doby? Jde mi o zajištění explicitně definované časové ztráty dat v případě total disaster (k dispozici je pouze poslední záloha a následný archiv redologů na jiné lokalitě). Případně, máte více memberů logfile group rozmístěných na různých typech storage, aby se dal aspoň některý z memberů živé RedoLogGroup v případě selhání storage-HW snadněji externě "vytěžit" (ztráta se minimalizovala "uplně")?

[Max]

Obnova s exportu se dělá do testovací db jen v případě, když se řeší nějaký devel bug a potřebují rychle vidět stav dat třeba z předešlého dne. Jsou to malé tabulky.
Jinak v současné době máme DataGuard v úrovni nejvyššího výkonu(async), takže se tvořený log tvoří automaticky i na standby. Rollback dat do 1min.
Zdar Max

[Peter Golis]

Napríklad si tam nasypem plnú zálohu smradfónu aj s filmami a fotkami ktoré tam už mám na inom mieste. A znova, a znova. Čas neriešim keďže si ten smradfón ajtak musím nabiť. A potom to prečistím. Z veľmi starých záloh si odmažem filmy, fotky presypem do fotiek a pretriedim do albumov. Podobne aj v prípade horeuvedených rýchlych záloh z fotoaparátu kde človek potrebuje presypať obsah karty ktorý pretriedi počas dlhých zimných večerov. Pred pretriedením človeku stačí spomenúť si na ktorom zariadení bol ten obsah vytvorený, a v akom časovom horizonte. Zvyšok zabezpečia náhľady.

Deduplikáciu na zbierke filmov by som riešil len ak by som mal stiahnutých viacero filmov pod rovnakým názvom, ale to je ftákovina ktorá sa ma netýka. Okrajové záležitosti ako stiahnutý film s názvom "čo nového v kinách" a jedným frame v ktorom je namaľovaný text "stiahni si mallware aby si ten film videl" sa síce dajú deduplikovať, ale len v prípade moc malého IQ alebo spolupodieľania sa na tvorbe.

Ale je pravda že deduplikácia sa hodí hlavne do firemného segmentu kde je samozrejmosťou ECC RAM, a vysoká pravdepodobnosť že sa dáta nachádzajú v rôznych kópiách jednej verzie. Či už spomínaná serverová farma (aj s databázami), alebo vnútrofiremné file servre kam si viacej ľudí nasype ku sebe jeden a ten istý obežník.

[Heron]

Nevím, zda to bylo míněno jako vtip nebo vážně, ale raději to sem napíšu. BTRFS používá alokační skupiny o velikosti 1GiB. BTRFS je navrženo pro xTB disky. Testy na xGB oddíle velice rychle způsobí vyčerpání alokačních skupin, hlášky typu ENOSPC a naštvání uživatele na neschopné btrfs, které je "plné" při 30% zaplnění daty. Jak se již na abclinuxu mnohokrát v minulosti řešilo. To fakt není FS na 2GB flashku.

[Käyttäjä 11133]

Tak proc ho odbornici z CZ.NIC pouzivaji na Turris Omnia?

[Heron]

Asi aby mohli snadno udělat rollback po update. To se nějak vylučuje s mým komentářem, nebo sis chtěl jen rejpnout?

[Käyttäjä 11133]

To fakt není FS na 2GB flashku.

[Heron]

Tak Omnia má 8, ale hlavně na to mají odborníky z NICu a nechodí si stěžovat na abclinuxu, jak je to nepoužitelné (což by bylo dost divné, když si to sami vybrali).

Ta pointa mého komentáře je v tom, že se objevuje nemálo lidí, kteří se rozhodnou "důkladně" otestovat BTRFS na něčem velmi malém a potom na to nadávají. Na to ten FS opravdu není stavěný. Toto tvrzení není v kolizi s tvrzením, že pokud někdo ví co dělá a ví s čím pracuje a ošetří si to, tak to může s výhodou použít.

Prostě testovat fragmentaci na btrfs na 2GB je blbost. Použít btrfs pro 8GB interní storage může být výhodné.