Filefrag (diskuse)

[Filip Jirsák]

Chápu to správně tak, že ten index byl zhruba půlmilionkrát zvětšen a za celou dobu nebyl nijak optimalizován? Obávám se, že to defragmentace na úrovni souborového systému nezachrání…

[Heron]

Nechám si poradit jak optimalizovat index. Tabulka byla optimalizována mnohokrát. Každopádně defragmentace by ten soubor alepoň spojila dohromady.

No jestli chceš mám tu jiné pikantní příklady souborů, které byly zapsány pouze jednou na oddíl o 50% zaplnění.

[Filip Jirsák]

Nechám si poradit jak optimalizovat index.

V PostgreSQL příkazem REINDEX. U MySQL nevím.

Každopádně defragmentace by ten soubor alepoň spojila dohromady.

A následující zápisy ho zase budou fragmentovat. Myslím, že na udržení málo fragmentovaných souborů pro databázi musí databáze a souborový systém spolupracovat – ale nevidím důvod, co by jim v tom bránilo. Podle mne pokud bude databáze alokovat diskový prostor napřed a používat řídké soubory (tj. oznámí souborovému systému, že bude potřebovat pravděpodobně velký soubor, ale fyzicky si zatím vezme jenom část), a souborový systém bude takové soubory alokovat tak, že (pokud je místo na disku) vynechá na disku místo pro celý takový soubor, pak by k fragmentaci nemělo docházet.

Samozřejmě pokud databáze zvětšuje soubor po malých blocích s tím, že souborový systém se s tím nějak vyrovná, bude soubor fragmentovaný, protože tenhle způsob využití je netypický a obecný souborový systém pro něj asi nemůže být optimalizován.

[Heron]

Řídké soubory naopak budou již ze svého principu velmi fragmentované. Protože FS jejich velikost nealokuje a ani nijak nerezervuje (protože to nejde) a jednotlové bloky řídkého souboru zapisuje náhodně. Zkušenosti s sparse file vytvářené azureusem to jen potvrzují (bez ohledu na použitý FS, výsledek je velmi podobný ať jde o ext3, xfs nebo ntfs).

Chtělo by to obdobu mallocu. Tedy program by sdělil operačnímu systému délku vytvářeného souboru, OS by jej alokoval jak nejlépe by to šlo a program by pak zapisoval data.

[Filip Jirsák]

Proč by to nešlo? Řeknu si FS o 1 GB soubor, FS se podívá na disk a zjistí, že má souvislou oblast 1 GB, tak ji rezervuje pro můj soubor. Já pak zapíšu 1 MB, které se zapíše fyzicky na disk, a zbývající prostor bude označen jako rezervovaný, ale nevyužitý. Dokud bude na disku volné místo, nemusí na ně FS sahat, a využije je teprve v případě, že jinde na disku nebude volné místo.

[Heron]

Ano, tohle by šlo, ale sparse file se takto imho nerezervuje. Jinak souhlasím a přesně tohle jsem myslel tím příkladem s malloc.

[Filip Jirsák]

Asi to zatím nikdo nenaprogramoval… Jinak té databázi by určitě prospěla alespoň odložená alokace diskových bloků (kterou má třeba XFS, ale snad se plánuje i do ext4). A fragmentaci by asi nejvíc pomohlo mít databázové soubory na vyhrazeném oddílu – pak by se do těch databázových souborů nemotaly fragmenty jiných souborů a fragmentace by měla zůstat na nízké úrovni.

[Heron]

A fragmentaci by asi nejvíc pomohlo mít databázové soubory na vyhrazeném oddílu – pak by se do těch databázových souborů nemotaly fragmenty jiných souborů a fragmentace by měla zůstat na nízké úrovni.

Abych nakonec nedopadl jako pan Ponkrác akorát bych měl oddíly dle aplikací. /www /mysql /squid

[Filip Jirsák]

To by pak ale vedlo k použití LVM2. A za pár měsíců si budete stěžovat, že to LVM strašně fragmentuje diskové oddíly, a že by to chtělo nějaký nástroj na defragmentaci volume group

[Heron]

LVM samozřejmně používám .

...
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                96.19 GB
  Current LE             3078
  Segments               3
  Allocation             inherit
  Read ahead sectors     0
...

Jo jo, chtělo by to nějakej LVM defrag .

[petr_p]

fallocate(2)?

[Heron]

fallocate() is available on Linux since kernel 2.6.23.

Wau. Je to hodně mladá funkce, takže asi nebude moc rozšířená, ale je to krok správným směrem. Díky.

[..]

Zase tak mlada ne, navazuje na posix_fallocate a ta uz je funkci o dost dele

[trekker.dk]

No jestli chceš mám tu jiné pikantní příklady souborů, které byly zapsány pouze jednou na oddíl o 50% zaplnění.

Budu hádat - velké soubory, které se zapsaly naráz, ale stejně jsou fragmentované...

[Heron]

V podstatě ano.

[trekker.dk]

Nechtěl bych kecat, ale mám ten dojem, že do určité míry je to tak schválně, aby se zabránilo ještě větší fragmentaci.

Četl jsem nějaké srovnání přístupu (Linux vs. Windows) - linuxové filesystémy fragmentují naschvál, protože když se všechny soubory nasypou do jedné souvislé oblasti a bez volného místa mezi soubory, tak při jejich editaci (zvětšování, zmenšování) dochází ke značné fragmentaci jak volného místa, tak i dalších souborů, které jsou na ten FS zapisovány (tenhle problém se projevuje u FAT). Proto se fragmentuje od začátku, čímž se dosáhne toho, že všechny soubory jsou na tom přibližně stejně.*

Je to dost dávno, zdroj si samozřejmě napamatuju, takže nemůžu garantovat, že jsem si to zapamatoval dobře.

* Samozřejmě potom dochází k různým "podivnostem", jako třeba video, se kterým se už nebude hýbat, ale je rozházené všude možně po disku; s tím se ale těžko dá něco udělat, protože tohle OS těžko rozezná.

Btw. kde se to nechá stáhnout?

[Heron]

Nechávat mezi soubory volné místo (tj "fragmenovat" prázdné místo) je velmi elegantní způsob jak zabránit fragmentování samotných souborů. Zásadní chybou interního defragu ve Windows je snaha vše naplácat na jednu hromadu. Jediný defrag do Windows který umí spojit soubory a nechat místo místem je Raxco Pefrect Disk. Pak je celý proces stejně rychlý jako třeba xfs_fsr. Velký soubor je pak samozřejmně fragmentovaný (protože je nacpán do těch volných míst), ale většinou to není nijak tragické. Pár seeků navíc při čtení mnoha GB souborů průměr rychlosti čtení moc neovlivní.

Btw. kde se to nechá stáhnout?

filefrag? Na Fedoře jej mám v balíčku e2fsprogs.

[trekker.dk]

Na Fedoře jej mám v balíčku e2fsprogs

Aha, ono je to přímo v utilitách pro ext3, tak tam mě nenapadlo hledat. Jdu se stydět do kouta.

[Kyosuke]

Nechám si poradit jak optimalizovat index. Tabulka byla optimalizována mnohokrát. Každopádně defragmentace by ten soubor alepoň spojila dohromady.

Ten soubor by spojila dohromady...a to by se projevilo přesně jak, hm? Copak k indexovým stránkám se přistupuje sekvenčně? Není to takhle náhodou B-strom? Ten se traverzuje značně nesekvenčním způsobem. Krom toho u slušně nakonfigurovaného serveru se stejně minimálně ty indexy vejdou do paměti. "Optimalizovaná tabulka". Chm. Všichni machři na Internetu s tím slovem obratně žonglují, ale ještě z nich dostat vysvětlení, co tím vlastně mají na mysli.

Každopádně to nejlepší, co můžeš udělat, je hodit databázi na raw partition a porovnat výkon se současným stavem. Tím by se ukázalo, kolik ten ext3 vlastně užírá, poněvadž jedině u raw partition má server jistotu, že má bloky skutečně za sebou, a může se tomu i přizpůsobit.

(BTW, ten filefrag mi nepřijde nijak extra použitelný. Kdysi jsem si napsal podobnou toolu, ač velice základní, ale určitě by k ní šel dodělat mnohem hezčí výstup. Hmm. Zamyslím se nad tím. )

[Heron]

Ty sis tu odpověď tedy pěkně užil

Jsem nepsal, že výkon DB klesá v důsledku počtu fragmentů tohoto souboru. To samozřejmně ne. Výkon této DB ne-klesá k vůli něčemu zcela jinému, ale o tom jindy. Ale přece jen z pohledu FS jde o soubor jako každý jiný a jako takový má jistě právo být uspořádán. Mno už stejně neexistuje. Budiž mu InnoDB lehké .

[Valoun]

Zkus defrag. Není to žádný zázrak, ale něco to asi dělá. Defragmentuje tuším prostým kopírováním, metodou pokus-omyl. Výsledné zrychlení nepozoruji, ale pro radost si ho občas pustím, baví mě koukat na čísílka.

[Heron]

Defragmentuje tuším prostým kopírováním, metodou pokus-omyl.

Ano, tohle dělá i shake. Problém je, že to nelze použít pro soubory otevřené pro zápis.

[Krakonoš]

Ano, defrag je super. Je to tuším to samé jako shake (kopíruje a spoléhá na to, že novej soubor si fs uloží lépe, než ten původní). Idea není špatná. Problém nastal při realizaci. Jednoduché kopírování prostě nestačí.

Zkoušel jsem oba programy, oba na různých discích. Nevěděl jsem jak to funguje, tak jsem si vzal dva disky a udělal bitovou kopii mého rootfs. Jsou tam nějaké databáze (maličké, nepoužívané), konfiguráky, binárky, občas nějakej film v homu (Stargate, IT Crowd - do 350MB).

Protože ten FS existuje již (v nezměněné podobě) od r. 2005 a údržba prakticky žádná (pravidelný fsck, po 3 měsících vždy rm -rf /usr/portage a novej sync -- neúnosně se to zpracuje při každém syncu...). Propustnost a hledání v katastrofálním stavu. Fragmentace souborů byla cca 7.2% (vyhodil fsck, filefrag myslím o desetinku vedle).

Pustil jsem fsck, abych opravil případné chyby. Nebyly. Pustil jsem shake na celý fs. Pracoval, vypadalo to docela zajímavě. Jezdily mi tam soubory, makal chvíli, ale celkem rychle.

Nechal jsem si přepočítat fragmentaci. V obou případech byla na 13%! Už nikdy více. Nejlepší defrag je mkfs.ext3...

[kavol]

reiserfs nemá podobný nástroj vůbec

hm, myslel jsem si, že pro reiserfs existuje placený repacker, ale když se to pokouším googlit, tak dostávám samé nesmysly o tom, že repacker bude v reiser4, a když se to pokusím vyloučit, tak dostávám informace typu, že "ještě" nemá z mailinglistů starých sedm let apod. :-/

[alpha]

Nema ho, a Reiser4 zatim taky ne - jeste pred rokem Namesys rikalo ze ho udela az jim nekdo posle $$$, ale ted kdyz Namesys prakticky neexistuje uz to asi neplati.