Dotaz: Pohádka o rsyncu a deseti milionech souborů.

[OgeeN]

Ahoj, žila byla jedna farma webových serverů. A ta farma servírovala spolehlivě data několik dlouhých let. Jak šel čas, množství dat rostlo a bobtnalo, až jednoho dne nabyla objemu cca 200GB v cca 10 milionech drobných souborů. No a adminovi začaly šedivět vlasy ...

Tolik k pohádkovému úvodu. :)

Potřebuji poradit, jak takové množství dat efektivně přenášet a synchronizovat na záložní svazek.

Rsync spuštěný s parametry -ropgt --numeric-ids --delete-during --archive --timeout=30 --delete-excluded trvá nad takovým množstvím dat cca 8 hodin. A to je příliš douho pro naše potřeby.

Existuje nějaký způsob jak přenést soubor na druhý svazek okamžitě po změně jeho obsahu?

Případně, je možné nějak zaznamenávat změněné soubory do textového souboru a ten pak v pravidelných intervalech předhazovat rsyncu? Jde mi o to, jak se zbavit času, který rsync stráví tím, že musí zkontrolovat u deseti milionů souborů zkontrolovat, zda se změnily.

Díky za nasměrování.

Odpovědi

[drunkezz]

mozno findom a roznymi atime ctime mtime  najst to co potrebujes a to syncnut..ale to je len cisty vystrel do tmy.

ale tu by sa mozno uz oplatilo postavit tu webfarmu nad sharovanym storidzom

D.

[OgeeN]

Na přechodu na sdílené úložiště se právě pracuje. Ale i tam potřebujeme mít data na dvou samostatných svazcích a ony svazky mezi sebou synchronizovat.

[drunkezz]

mozem vediet dovod preco na dvoch? D.

[OgeeN]

Na jednom svazku (říkejme mu READ) jsou data, ze kterých čtou webové servery. Na druhém svazku (EDIT) jsou data, nad kterými pracují editoři a programátoři. Po dokončení úprav a jejich verifikaci, jsou změněné soubory přeneseny na svazek READ a servírovány uživatelům. Pak

Jde tedy o to, aby někdo na svazku READ, který je viditelný v internetu, neprovedl nějakou úpravu, která by vedla třeba k chybnému zobrazení stránky.

[Jirka]

pokud jde o okamžité přenesení souboru po změně, tak to už potom můžete rovnou použít raid1, nebo něco jako drbd ? a jestli lze průběžně zaznamenávat změnivší se soubory, tak to by mě teda taky zajímalo:)

[chochi]

Zalezi jak je struktura a co chces sledovat. Pokud jsou soubory jen v par adresarich (maximalne stovky, ci tisece) a staci sledovat vytvoreni noveho souboru, smazani a zmenu obsahu (neni tam zadne prejmenovavani, nebo vytavareni adresaru - to by situaci zkomplikovalo), tak by se dalo jednoduse pouzit inotifywait, ktery rekne jake soubory se zmenily. Priklad:

$ inotifywait -m -e close_write -e delete .
Setting up watches.
Watches established.
./ CLOSE_WRITE,CLOSE cc
./ CLOSE_WRITE,CLOSE cc
./ DELETE cc

Z toho pak to vyextrahovat a zkopirovat. Pokud hrozi vytavareni adreasaru, tak to lze, ale asi to chces nejaky skript nad inotify.

[Stanislav Petr]

Neni co resit - http://gluster.org

[OgeeN]

Tohle nám asi nepomůže. Na sdíleném úložišti je už použitý filesystém OCFS2. Ke svazku na sdíleném úložišti totiž přistupuje najednou deset různých fyzických serverů. Pokud tedy GFS neumí fungovat nad OCFS2.

[Ivan]

Asi je to offtopic, ale existuji i jine nastroje na zalohovani nez rsync. Napr. nektere FS podporuji binarni inkrementalni zalohy. Popr. TSM (komercni produkt) ma demona, ktery pres inotofy prijima informace i zmenach souboru a uklada si je do zurnalu. Inkrementalni zaloha pak "pouze" prochazi tenhle zurnal. Pri tomhle objemu bych zkusil neco co pouziva inotify.

PS: Jak moc stabilni je OCFS2 pri tomhle objemu dat? Kdyz jsem to naposledy testoval tak to nebylo nic moc.

[OgeeN]

Něco takového právě asi hledám. Průběžně vytvářet žurnál a tenhle žurnál třeba jednou za minutu předhodit rsyncu. Něco takového by nám asi stačilo.

Zatím to máme k diskovému poli připojené tři servery v testovacím provozu. Ještě jsme na to nepustily, žádný větší provoz, takže zatím nedokážu odpovědět.

Od vyladění nastavení se to zatím chová stabilně.

[Josef Kufner]

Můžeš zkusit incron. Ale ten rsync bych tam stejně čas od času spustil (každou neděli?).

[OgeeN]

To vypadá dobře. Díky za tip.

Zatím testuji toto: http://code.google.com/p/lsyncd/

a další kandidát je zde: http://code.google.com/p/rsync-inotify/

[OgeeN]

Tak bohužel mi asi nepomůže nic založeného nad inotify. Potřebuji hlídat příliš mnoho adresářů. Jen spuštění lsyncu nad všemi adresáři vy trvalo několik hodin.

[linuxik]

Uz jsem to tady psal, ale proc proste nezkusis find + cp, je to dvouradkovy skript. neco jako:

find source_dir  -type d -exec mkdir -p '{}' /dest_dir/'{}' \;
find source_dir  -type f -cmin -1440 -exec cp -v '{}' /dest_dir/'{}' \;

Samozrejmne si budes muset pohrat s cestou k source a dest adresari, aby se vse kopirovalo do spravnych adresaru, ale na 99,9% nic rychlejsiho nenajdes(pro spoustu malych souboru).

[camel1cz]

Rychlost find a rsync bude řádově srovnatelná - teda pokud bude ten find napsaný optimálně a ne jako to co uvádíte. rsync na jehož nedostatečnou rychlost si tazatel stěžuje tráví 99,99% jalové práce na procházení souborů a testování existence/aktuálnosti souborů - vy jste to akorát rozepsal na 2 příkazy, kde oba obsahují většinu režie původního rsync - podle mého názoru to bude tak o 250% pomalejší než původní řešení.

[linuxik]

Ach jo, to co tady pisu mam z praxe a rsync je pro velke mnozstvi malych souboru zoufale pomaly. Proc to opravdu nevim, ale je to tak ze i s parametrem -w se rychlosti find+cp ani nepriblizi.

To ze mam na konci find strednik a ne plus je take vyzkouseno jako nejrychlejsi moznost. Testoval jsem to asi na 7M souborech, naprosta vetsina mela mezi 10 a 100KB a denne se zmenilo kolem 5% souboru. Netusim proc ale typnul bych si ze to bude mit neco spolecneho s diskovou cache. Kopirovani jednotlivych malych souboru, ktere od sebe oddeluje relativne dlouhy cas hledani pomoci find funguje nejspise lepe nez davkove kopirovani stovek MB dat najednou, ale to opravdu jen hadam.

[camel1cz]

Tak to se omlouvám!

Možná blbý dotaz, ale máte namoutěno s noatime?

Ze zvědavosti: máte někdo teorii, na čem tráví rsync tolik času? ten find přece také udělá stat každého souboru, což považuju za nedražší (a navíc 2x - kvůli adresářům a pak kvůli souborům). A ten protokol výměny seznamu souborů a jeho procházení přece nemůže být tak extrémně pomalý?

[Ash]

Netusim proc ale typnul bych si ze to bude mit neco spolecneho s diskovou cache.

Udeřil jste hlavičku na hřebíček, jednoznačně.

Je rychlejší F1 nebo T60? Mám-li dojet z Prahy do Brna (všichni znají stav D1), volím jednoznačně tank, protože ten bude v Brně rádově rychleji než monopost F1. F1 se kus za prahou rozpadne, možná i havaruje, a než ho dáte dohromady, jste v Brně dávno tankem. Výsledek - tank je jednoznačně rychlejší než formule.

Konkrétně v našem případě, find je samozřejmě z principu řádově pomalejší, navíc když ho tak neoptimálně pouštíte (10 000 000 procesů cp mluví za vše). Ale chápu, že to děláte s ohledem na stav vašeho OS (D1), který má zjevně nějaký výkonnostní problém a nedokáže vyhovět požadavkům rsync při práci s IO.

Pokud by se ovšem podařilo najít ten výkonnostní problém, tedy opravit D1, budete samozřejmě rychlejší s rsync, který během kopírování žádnou jalovou práci nedělá a nezaměstnává procesor zbytečnostmi, které ovšem na rozbitém systému umožní jakž takž kopírovat. Ten výkonnostní problém jsem také dlouho míval, ale s novým jádrem a aktualizacemi díky bohu nějak vymizel, byl to opravdu osten v p...

bash$ time $(find source_dir -type d -exec mkdir -p '{}' dest_dir/'{}' \; ; find source_dir -type f -cmin -1440 -exec cp '{}' dest_dir/'{}' \;)

real    8m11.393s
user    0m4.963s
sys     2m21.717s

bash$ time rsync -a source_dir dest_dir/

real    0m11.774s
user    0m1.600s
sys     0m11.933s

Je docela zoufalé, že na rozbitém systému se musí při kopírování většího množství dat vkládat různé cykly typu "find" a "verbose", ale je jasné že dokud systém nebude opraven, je to způsob, jak to alespoň jakž takž pomalu ale jistě překopírovat, aniž by se to cestou rozbilo.

Jinak samozřejmě optimální by bylo odstranit problém a použít rsync.

[Ash]

Omlouvám se za tu analogii, ale celkem bych se přimlouval za to, že když někdo argumentuje že 10000000 x find je rychlejší než 1 x rsync, že vlastně tvrdí, že tank je rychlejší než formule. V praxi to samozřejmě může být pravda, ale používalo by se spíš slov jako "efektivnější" nebo "výhodnější", protože slovo "rychlejší" v tom kontextu zní prostě hloupě, a to se týká jak tanku tak findu. Takže bych se přimlouval za zdůraznění okolností, jako "daný systém má problém s efektivním kopírováním" či "dálnice je rozbitá" a podobně, aby to "rychlejší" tak hloupě neznělo :)

[linuxik]

Hezky, ale zcela nerealny vysledek. Za 11 vterin neprojde milion souboru ani ls. Nebylo by mozne dat sem take statistiku z rsync(--stats), kde by bylo videt kolik souboru bylo kopirovano a jak moc se uplatnil diff. Typuji ze jde o par tisic souboru, ktere jsou relativne velke, tady se samozrejme projevy vyhoda diferencialniho kopirovani.

ps. pokud mam system na kterem bez problemu spustim 10000000 procesu cp a porad je rychly, svedci to spise o perfektnim vyladeni nez o vykonostnim problemu

[Ash]

Výsledek je reálný pro 100000 malých souborů, pro milion násobte deseti, není tam žádný výkonnostní "skok" či zub.

Pokud máte i systém, kde bez problémů spustíte 10000000 procesů cp a pořád je rychlý, tak to je dobré, ale to je asi zcela jiný případ, než jste tu uvedl :) Ten váš problém s rsync opravdu světdčí o výkonnostním problému.

[linuxik]

Tem vykonostni skok tam prave je, nebo alespon jeste pred pul rokem byl. Jakmile se dostanete pres nejakou magickou hranici zacne byt rsync nesnesitelne pomaly. Navic nevim co porad mate s tim 10M procesu. Na serveru mam kolem 7M souboru a z nich se denne zmeni kolem 3-5%, to znamena kopirovat asi 300000 souboru. Kdyz si vezmu ze kopirovani bezi 3.5 hodiny je to neco kolem 23 kopirovanych souboru za vterinu. Pro system s diskovym polem pripojenym pres SAN zadny problem. Rsync to nestihne za 6 hodin.

[Ash]

To vy jste si začal s 10M procesy :D

Ten váš příkaz find ... -exec cp dělá to, že pro každý nalezený soubor, spustí extra proces cp. Nemusí jich být 10M, ale bude prostě pro každý soubor jeden, a vytváření procesů je v linuxu prostě drahé a v tomto případě hlavně zbytečné. Chápte? Každý jeden modifikovaný soubor vezmete, vytvoříte pro něj proces cp, který ho zkopíruje, a zase zanikne. Neskutečné plýtvání. Pokud vám 2,5h stačí a zátěž stroje a účty za elektriku vás netrápí, budiž, ale musí to jít i efektivněji, pomocí rsync (ok, tam říkáte že je probl.), nebo tar, nebo lépe použít cp (ten také umí kopírovat víc než jeden soubor na jedno spuštění.

[Heron]

vytváření procesů je v linuxu prostě drahé

Od kdy?

[Ash]

Odjakživa.

[pavlix]

Vytváření procesů je v linuxu prostě levné.

[Josef Kufner]

Je to levné ve srovnání s ostatními operačními systémy, ale v absolutních číslech to až tak levné není. Proč bysme jinak měli FastCGI a xargs?

[lertimir]

vytvoření procesu je drahé pouze v kontextu operací procesoru. V kontextu operací s diskem, kdy seek time mám někde něco málo pod 10ms jsou nějaké mikrosekundy ztracené pro vytvoření procesu nepodstatné. Podstatné bude, co dělá fyzicky s diskem find / cp a co dělá rsync. Víte jistě, jak rsync interně pracuje. Pokud rsync sáhne na všech 7M souborů i když by nemusel, tak je to čas asi 10 hodin v seek time (tak špatně to asi nebude). Pokud na těch 300 000 sáhne o jednou více než cp (třeba proto, že tam může být nějaký sync pro cache, aby měl skutečně data, co jsou na disku) tak je to cca 50 minut jen na ten seek. V podstatě na žádném rotačním disku se nedá dostat moc výš než 100-150 IOPS. To jsou základní operace, tedy i čtení inode.

Možná že by se tazateli dalo najít úzké místo pomocí atop, iotop nebo pomocí technik Extreme Linux Performance Monitoring

[JiriHorky]

Vytvoreni 1 milionu procesu, ktere hned skonci, v ramci jednoducheho c programu mi trvalo na X5650 @ 2.67GHz cca 45vterin tj. 45 microsekund na proces. Tj. rezie jen samotneho zalozeni/ukonceni 10mil. procesu je neco jako 8min.

To, co presne dela rsync se soubory jsem popsal nize, jde to videt v strace. Dela tech operaci vice, ale taky dava daleko vice zaruk nez jednoduchy cp. Zadne sync() rsync nevola. Find zase pochopitelne na kazdy soubor musi zavolat stat() [realne vola newfstatat()].

Jinak se to tady uz objevilo vicekrat, reaguji zde - inody na disku nejsou rozesety nahodne, ale jsou vzdy zdruzovane po skupinach, ktere nejsou zrovna male. Muj ext4 rika "8192" Inodes per group. Takze ty vypocety ohledne seeku je nutne brat s rezervou, zvlast kdyz se jedna o cteni pristupy, kde prvni cteni pravdepodobne natahne do pameti vsechny inody z dane skupiny.

[Ash]

Nepodstatné jsou možná tak pro vás :) Ale chápu, máte rychlý procesor, takže spustit zbytečně desetimilionkrát nějaký program, proč ne, alespoň se procesor nefláká a uživatel si počká, může si přece udělat kávu a protáhnout se, takže ve výsledku je to vlastně zdraví prospěšné. Argumentovat se dá opravdu všeliak.

[JiriHorky]

Jen dalsi cisla: na serveru s dvema procesory X5650 (celkem 12 coru) 10milionkrat spusteni "cp --version" pres execve() volani neco jako 10.5 minuty a system na 50% vytizen na CPU. Na mem ntb s i5 to same trva 39.5 minuty (extrapolace). Takze levne to opravdu neni.

[lertimir]

Díky za čísla. Já ale neříkal, že vytvoření procesu nestojí nic. Napsal jsem že v kontextu procesorových operací je vytvoření procesu drahé. Podle vašich čísel je tedy na i5 procesoru cca 4 min na 1 milion procesů tedy 240 micro sec na vytvoření procesu, pokud dělím dobře. Ta vaše i5 má tak 2-3GHz procesor což tedy dává cca 500 000 hodinových cyklů na vytvoření procesu. To je tedy drahé hodně (čekal jsem tak náročnost 10-50 000 cyklů), ale pořád vzhledem k cca 10ms seeku na hledání pro jeden soubor je to hodnota o 2 řády méně. Takže podstatné je, co ten jeden nebo druhý způsob dělá z disky.

[Josef Kufner]

Těch seeků tam bude víc, kvůli linkování dynamických knihoven. Ale to se týká jen prvního spuštění, pak už by to mělo jít z cache. Pořád to ale je něco počítání a hromada přepínání kontextu (jádro/userspace) a tam už se to trošku nasčítá.

[JiriHorky]

Vetsina knihoven uz je davno mmapnuta, navic jich je tak malo, ze bych to vubec neresil.

[AraxoN]

Je to tak ako píše linuxik - teoreticky by rsync mal robiť to isté, ale prakticky je find rádovo rýchlejší. Ja som tiež používal rsync, ale ako narastalo množstvo dát, doba jedného behu rsync sa stále predlžovala, až sa stal nepoužiteľným. Vtedy som to prepísal na find (+tar +ssh, ako spomínam v inom príspevku tu v diskusii) a opäť som vysmiaty.

[JiriHorky]

Tak jsem si s tim inotify trochu pohral. Primarne mi slo o to, zda inotify lze/nelze pouzit pro miliony souboru. Vzal jsem zdrojak "inotify-tools", konkretne inotifywatch. Upravil jsem ho, aby pri volbe "-r" navesil sondy i na soubory a aby nevolal zbytecne stat() na kazdy soubor, coz predtim delal.

Pri cold cachi trvala inicializace na 1002524 souborech 55 vterin na SSD disku s ext4 a i5 procesoru. S hot cachi trvala inicializace 7.5 vteriny. Spotreba pameti pak byla na urovni ~280MiB.

Spotreba pameti by se dala navic hodne snizit vhodnym ukladanim jmen souboru - tato verze uklada cele jmeno bez vyuziti komprese stejnych prefixu apod.

Takze bych system inotify uplne nezatracoval, ale je potreba jej pouzivat "spravne". Vsechny inotify sw, ktery umi rekurzivne poslouchat, ktere jsem videl, maji z pohledu vykonu co dohanet.

[OgeeN]

Mohl byste poslat seznam změn, které jste ve zdrojácích provedl?

[JiriHorky]

Hodil jsem diff -ru na pastebin: http://pastebin.com/FXvCEA56 . Neni to zrovna neco, co by se takto dalo poslat vyvojarum, ale pro inspiraci by mohlo stacit. Cela myslenka je v tom, ze neni nutne volat fstat() na filesystemech, kde je typ souboru jiz v informacich v adresari. Plus teda volani add_watch i na regularni soubory.

[Šangala]

Nebude to zlobit na starších jádrech? nějak mí zvoní v hlavě vzpomínka, že byl změněno „něco“, co dříve limitovalo to takto použít.
Jinak je možná důležité co říká:
cat /proc/sys/fs/inotify/max_user_watches
Je nebo není?

[JiriHorky]

S temi starsimi jadry neumim rict. Tipoval bych, ze tam nejake zmeny od prvniho zacleneni byly. Moje vysledky jsou na 3.4.9-gentoo, takze to asi nebude uplne reprezentativni priklad jadra na serveru. Jinak zvyseni limitu v /proc/sys/fs/inotify/ je samozrejme nutnost, defaultne u me bylo maximalne 8192.

[Šangala]

Nemůžu najít, není to tak dávno co jsem to četl, nějaký „release notes“ (třeba ½ roku zpět), ale bylo to něco ve smyslu, že byl potřeba desccriptor pro každé „něco“ a fčul už je jeden na celé „něco“.
A protože si to pamatuji takto „přesně“, tak to nemůžu najít…

[JiriHorky]

Hm, file descriptor je potreba jen jeden per inotify watch instance, pro kazdy soubor ma pak clovek "watch item". Toto vypada, ze je design choice uz od zacatku. No, jestli to najdete, tak dejte vedet :)

[chochi]

Tohle plati pro inotfy alternativu (kqueue) na FreeBSD, kde je potreba jeden FD na kazdou sledovanou polozku (pokus si dobre pamatuju).

[Šangala]

Že by jsem to až tak doplantal dohromady se mi moc nezdá…, nicméně taky nemůžu nic najít, takže jsem jen zbytečně vnesl nejistotu.

[masomlejn]

Možná blbost ale co zkusit přidat --size-only bude to porovnavat podle velikosti, což by mohlo být rychlejší. Samozřejmě změna souboru se nemusí projevit na jeho velikosti a tim pádem můžeš prošvihnout nejaké aktualizace.

[rADOn]

Můžeš zachytávat změny souborů pomocí inotify, ale existuje limit kolik sond můžeš mít nastavených a nejspíš se do něj nevejdeš.

Spíš hledej filesystém, afaik existuje několikero replikujících filesystémů nad FUSE. Takové fs řeší jen replikaci, fyzické ukládání nechávají na jiném fs nad který jsou přimountovány takže by s OCFS neměl být problém. V našich končinách to dělá třeba SeznamFS (ale nejdřív bych hledal něco co se aktivně vyvíjí.)

[Skřivy]

A jak to funguje? My jsme to rok pouzivali a v poctu serveru kolem 50 jsme z toho rodili.

Vecne se to rozpadavalo, melo to problemy se symlinky a obcas se to samo dostalo do nekonzistentniho stavu.

[rADOn]

Jestli myslis primo SeznamFS tak ten byl vymyslenej prave jako nahrada rsyncu, takze ma zvladat hromady souboru, ne hromady replik. Matne si pamatuju ze to Edois zkousel na ctyrech nebo osmi master-master replikach v kruhu nebo tak neco, urcite ne padesat. Anyway to byl jen priklad co me prvni napadl, na webu fuse je hromada podobnych projektu.

[Skřivy]

My jsme to pouzivali v konfiguraci 1 master - 50 readonly slavu a to v produkcnim prostredi. Pouzivali jsme to cca na 100 souboru s frekvenci aktualizace ob den.

Uz z principu fungovani je pocet slavu celkem jedno. Pokud to nejsou stovky az tisice vysoce aktivnich klientu, tak by s tim rozumne napsana aplikace nemela mit vetsi problem.

Dalsi problem, co jsme resili byla vysoka narocnost na sit a cpu. Bez jakychkoliv zmen to trvale generovalo 50Mbit trafficu a bylo celkem bezne, ze to plne vytizilo 1 jadro procesoru (bez jakehokoliv cteni, jenom kdyz jsme to meli primouteny).

[Drašar]

Mozna by sel pouzit fam (File Alteration Monitor). Nikdy jsem jej ale nepouzival, takze mozna je to uplne mimo misu :)

[AraxoN]

Ja som v podobnej situácii použil find:

#!/bin/sh

DATE=`date +%Y%m%d`
TOUCH_OLD=/home/backuper/bin/touch.old
TOUCH_NEW=/home/backuper/bin/touch.new
FILELIST_FILE=/tmp/filelist-${DATE}.txt
SRC_PATH=/var/nfs/

# 1. vytvorime novy docasny touch
touch $TOUCH_NEW

# 2. vytvorime zoznam suborov od predosleho touch
find $SRC_PATH -newer $TOUCH_OLD ! -type d > $FILELIST_FILE

# 3. vytvorime archiv podla zoznamu
/bin/tar -czf - --files-from=$FILELIST_FILE --transform 's|^var/nfs/||'

# 4. posunieme novy touch na stary
mv $TOUCH_NEW $TOUCH_OLD

To vytvorí na pôvodnom serveri zoznam nových súborov a zbalí ho. Výstupný archív ide na STDOUT. To preto, že to potom volám z toho druhého servera:

secondary-server ~ # ssh backuper@primary-server ~/bin/tar-new-files.sh | tar -xz -C /var/zaloha

To vezme zmenené súbory od poslednej synchronizácie, zbalí ich, prenesie cez SSH a rozbalí ich potom na druhom serveri. Počiatočný stav je potrebné samozrejme vytvoriť pomocou plného rsyncu, alebo podobne. Taktiež to nerieši situáciu, keď sa súbory na pôvodnom serveri neskôr vymažú (sekundárny sa to nedozvie a ostanú tam).

[Josef Kufner]

rsync dělá něco velmi podobného, jen je o dost vyspělejší a lépe optimalizovaný. Dokonce se dá spouštět skoro stejně jako tvoje řešení.

[AraxoN]

To je možné, ale ako píše tazateľ, s rsyncom to trvá 8 hodín. Ja som tiež predtým používal rsync, ale keď nebol schopný dokončiť úlohu za jednu noc, tak som musel nájsť iné riešenie. Find to má nájdené behom chvíľky a keď nie je veľa zmien tak sa prenesú za pár minút.

[l4m4]

Tak, a co tedy dělal rsync pomaleji než toto ruční řešení? Jak dlouho trval dru run?

Můj tip je nějaká chyba v použití rsync, která působila přenášení i souborů, které se nezměnily.

[JiriHorky]

Zdravim,

co kdyz dojde k vytvoreni noveho adresare? :)

Jiri Horky

[AraxoN]

Prázdne adresáre sa neprenesú.

Ak tam ale je nový adresár a v ňom nový súbor, objaví sa vo fileliste. Podľa filelistu sa súbor normálne zabalí a na cieľovom stroji rozbalí. Pri tom sa vytvorí aj ten adresár.

[Josef Kufner]

Hele a co udělat distibuované úložiště? Prostě to rozhodit na více řadičů a více disků, kde klíčem k rozdělení by byl třeba první byte MD5 hashe cesty (nebo jakákoliv jiná rovnoměrně rozprostřená hodnota)?

Když bys to rozdělil třeba jen na čtvrtiny, tak máš místo 200GB jen 50GB disky a to už v pohodě vleze na levné SSD. Když to dáš na 16 dílů, vejdeš se do RAM (ale nebude to levné). Obrovskou výhodou by bylo paralelní zpracování, kdy by to místo osmi hodin běželo jen jednu hodinu a bylo to snadno rozšiřitelné.

Pak stačí mezi servery synchronizovat routovací (hashovací) tabulku, kde máš uloženo, jaké rozsahy klíče jsou na kterém disku. To aby jsi mohl kompenzovat nerovnoměrnosti rozložení, případně dávat současně používaná data blízko k sobě.

Sice to bude stát nějaké to železo, ale myslím, že na ušetřeném času a šedinách admina se to vrátí.

[chsajarsa]

Takhle funguje gfs v geografickem rezimu. Dela si hashe a podle toho je rozhazuje na nody, takze tohle reseni uz existuje.

[dustin]

Při používání backuppc jsme bojovali úplně s tím samým problémem. Rsync si drží informace o prošlých souborech v paměti a často sežral všechnu paměť i swap a konec. Používáme místo toho tar s parametrem --newer a ten je řádově rychlejší. Samozřejmě to nezdetekuje hrátky s časy.

Jinak offline kopie děláme přes synchronizaci raidu1, nic rychlejšího jsme zatím nenašli.

[l4m4]

Není to pouze problém toho, jak backuppc používá rsync? Při pár milionech nezměněných souborů není spotřeba RAM prakticky měřitelná (tj. něco málo rsync samozřejmě naalokuje, ale neškáluje to s počtem souborů a zůstává to v promilích).

rsync není ideální nástroj na obyčejný přenos souborů, tj. pokud na druhé straně není nic, co by připomínalo adresářovou strukturu na zdroji. Ale při synchronizaci může být tar těžko citelně efektivnější.

[dustin]

Jo, rozdíl samozřejmě je, protože rsync komunikuje a hlavně čte na obou stranách (přičemž serverová strana implementuje rsync v perlu, ale mluvím o straně zálohované, kde běží binárka rsyncu), zatímco tar --newer žádnou druhou stranu neřeší a prostě hrne jen --newer soubory rourou po síti.

[l4m4]

Někde je nějaká zrada. Například, že cílový systém nerepresentuje věrně vlastnosti souborů zdrojového, takže je rsync nucen kontrolovat obsah souborů, což je sice poměrně rychlé přes kontrolní součty, ale řádově pomalejší než nečíst je a nepřenášet nic.

Uvedené parametry totiž docela dobře popisují můj home, který je akorát asi poloviční. Nezmění-li se žádné soubory, trvá kopletní rsync-over-ssh deset sekund. Když se přenášejí data, tak se samozřejmě čas prodlužuje úměrně množství dat (a nepřímo úměrně rychlosti sítě, což je standardní stomegabit). Dostat se na čas delší než několik minut za normálních okolností, tedy když jsou změny ve stovkách MB až pár GB, nejde (což odpovídá teoretickému odhadu).

Zato tvých 8 hodin odpovídá tomu, že by se četlo a přenášelo praticky všechno, nejen nějaká malá, změněná část.

Je běžné, že se ti mezi rsyncy změní velká část těch souborů, třeba 80%?

Máš na zdroji (případně v cíli) souborový systém, který nějak blbě pracuje s malými soubory?

Nezpůsobuje to --delete-during?

Co já vím. Ale někde je zrada.

[Josef Kufner]

Ty malé soubory jsou svinstvo. Kdysi jsem měl na disku tile storage od stahování map z googlu (do trekbuddy), pár gigabajtů, ale backup rsyncem trval nechutně dlouho, i když se nic neměnilo.

Souborový systém by v tom prsty mohl mít. Co třeba takový atime? není zapnutý?

[l4m4]

Jo, strictatime by tohle dělat mohl.

[l4m4]

Další možnost je I/O bound load na serveru. Pokud se rsync neustále bije o I/O se zbytkem vesmíru, tak samozřejmě jde rychlost do kytek. Z popisu problému těžko říci.

[OgeeN]

Co bych měl ještě dodat?

[Šangala]

Tak to jsem zvědavý co se z toho vyvrbí, mně něco podobného udělá rsync doma tak 1× měsíčně, ručně spouštím skript, kde je rsync (jen naznačuji, že vždy stejně a není to pravidelné) z Debianu na OpenSuse, fčul přes NFS a jednou za čas mi to místo několika sec až několika málo min běží neúměrně dlouho a to několikanásobně déle než by proběhlo pouhé kopírování té složky a oba stroje jsou nevytížené - je pravdou, že server má přiděleno jen 500MiB RAM, je to jen jedno-jádro a je to na XEN-u, ale normálně mu to stačí a stane se to jen jak píšu. V průběhu toho, můžu normálně ze serverem komunikovat a to i na to NFS (jiný share) a rychlost je jen v řádech procent nižší (tedy téměř neměřitelně) než bez toho běžícího rsycn-u.
Už jsem to vzdal, protože mi to nestojí za to (je to jen rsync domovské složky a doma), a hlavně proto, že to udělá třeba 1× za měsíc nebo dva, já v průběhu prolezu vše co mě napadne, nic nezjistím a opakovaně to už funguje „mtk-mrk“ (takové věci jako -x, -c, jsem tam zkoušel ale stejně se to zas stalo).

[Ash]

Jde mi o to, jak se zbavit času, který rsync stráví tím, že musí zkontrolovat u deseti milionů souborů zkontrolovat, zda se změnily.

Kolik času z těch 8 hodin vlastně zabere ta kontrola (parametr --dry-run)? 10M souborů mi nepřipadá tak moc.

[Jupi]

10M suborov sa nezda byt vela, ale treba si to preratat na IOPs. Ak sa puzivaju klasicke 10k otackove disky, tak budme optimisti, ze urobia 1k IOPs pre jeden zvazok v RAID1, treba zaratat aj seekovanie hlaviciek, tak tych 8 hodin je vpohode. Jedno z rieseni by bolo pouzit SSD disky. IOPs by islo o niekolko radov hore a cas rsync pod 1 hodinu s prehladom.

[Jendа]

Ale rsync podle mě nehrabe na každý soubor, ale jde stromečkem adresářů.

[Jupi]

Myslel som to tak, ze ziskanie potrebnych udajov o kazdom subore je potrebna jedna IOP. Nie na nacitanie obsahu suboru. To by bolo urcite viac.
To je len na zjednodusenie. V jednej IOP sa moze nacitat info aj o viac suboroch, ale napr. 1 z 1000 suborov musi byt aj preneseny, co su dalsie IOPs na disk + sietovy prenos, ...

[l4m4]

No, tak to na rozumném souborovém systému snad není. Doporučuji si to zkusit prakticky změřit.

IOPs na přenos teď nepočítáme, to je sekvenční čtení a samozřejmě škáluje s velikostí přenesených dat, nikoli s počtem souborů. Jde-li o synchronizaci, předpokládáme, že objem přesnených dat je relativně malý. Takže potíž je v tom, když dosahuješ časů, které opovídají přenášení všeho.

[Josef Kufner]

Záleží na jeho konfiguraci. Nejsem si jist, co dělá defaultně, ale může i kontrolovat obsah souborů a to pak znamená počítání hashů. A pokud mu filesystémy neposkytnou vše potřebné, asi to bude jako fallback.

[l4m4]

Tak prosím prerátat. Kolik IOPs je v průměru zapotřebí na přečtení jedné inode? Jak by mohl být find, tar nebo cokoli, jak zde různí lidé tvrdí, být rychlejší, když tyto IOPs musí provést naprosto stejně?

Praktické testy na naprosto cold systému se starým SATA II 7200RPM diskem, ext3, dávají přečtení 3000+ inodů za sekundu. I v tom nejpesimističtějším případě by dry-run s nezměněnými daty trval pod hodinu. Druhý běh by pak samozřejmě trval už jen několik sekund díky cache...

Zrada prostě musí být někde jinde.

[Jupi]

Uz tu niekto pisal DRBD. Podla mna je to idealne. Ak to nepoznas, moze to byt v podstate mirror, ktory funguje medzi zariadeniami cez LAN. Pracuje na urovni device a nad tym moze bezat lubovolny FS. Pri kapacite 200GB je to uplne pohoda.

[Heron]

DRBD pracuje na úrovni blokového zařízení a nikoliv souborů. To mu příliš nepomůže, když potřebuje oboustraně synchronizovat soubory.

Musel by mít drbd v režimu active-active a nad tím FS, který s tím umí pracovat.

[OgeeN]

Bohužel DRBD mi nepomůže. Potřebuju synchronizovat data mezi dvěma svazky na jednom diskovém poli.

[Jendа]

Přidej k rsyncu -vh --progress a podívej se, kde to nejdéle čeká.

[OgeeN]

Spustil jsem rsync s parametry uvedenými v prvním příspěvku a přidal k nim parametry -vh --progress. Po spuštění běžel výpis adresářů velmi rychle. Po několika minutách se tak zpomalil, že nyní jej v podstatě stíhám číst. Procesor se fláká, systém má ještě 6 GB volné RAM. Load je na 3,75.

[OgeeN]

Jo a svazky jsem přemountoval s parametrem noatime.

[Ash]

Předpokládám, že to zkoušíte s --dry-run? Jinak by se zrychlení díky přemountování s noatime projevilo až po úspěšné synchronizaci atimes na druhý stroj :)

[Ash]

Jakého času jste dosáhl s tím --dry-run, pokud to není tajné?

[OgeeN]

Utilizace zdrojového svazku je na 100%.

[linuxik]

Ahoj, rsync se pro tohle proste nehodi. Resil jsem podobny problem asi 3 roky zpatky a nakonec jsem skoncil s jednoduchym skriptem s find a cp. Mel jsme neco kolem 7M souboru do 1MB, kolem 5000 zmen denne a kopirovani trvalo kolem 1 hodiny.

[l4m4]

Nevím sice, kde je problém, možná narážíte na nějakou chybu rsyncu, ale těžko lze tvrdit že rsync se pro toto prostě nehodí, když jde o primární účel rsyncu. K čemu by se hodit měl, když ne k tomuhle?

[linuxik]

K efektivni synchronizaci velkych souboru u kterych se nejvice uplatni schopnost prenaset poze zmenene casti. Pro kilobytove soubory bude vzdy find + cp radove rychlejsi.

[Josef Kufner]

rsync má volbu na přenosy celých souborů a neřešení změn.

       -W, --whole-file
              With this option rsync’s delta-transfer algorithm  is  not  used
              and  the  whole file is sent as-is instead.  The transfer may be
              faster if this option is used when  the  bandwidth  between  the
              source  and destination machines is higher than the bandwidth to
              disk  (especially  when  the  "disk"  is  actually  a  networked
              filesystem).   This is the default when both the source and des‐
              tination  are  specified  as  local  paths,  but  only   if   no
              batch-writing option is in effect.

[alkoholik]

A z jakeho adresare ten rsync spoustis?
Me delal psi kusy, kdyz jsem byl v adresari, ktery mel synchronizovat.
Jeste se muzes podivat pres strace -p, co v tu chvili dela..

[Heron]

Jak velkou paměť mají ty stroje? Na jednom hodně slabém železe máme cca 7M souborů na 1.5GB RAM a je to opravdu problém. Linux si nemůže cachovat dentry a tak každý adresář musí nutně číst z disku. Přidání paměti obvykle dost pomůže. Rsync by po nějaké první synchronizaci neměl potřebovat nic jiného, než porovnání adresářového záznamu na zdroji a cíli, takže ani na záznamy v inode nebude seekovat. Pokud se vše potřebné vleze do RAM, tak rsync (porovnání) i nad 10M soubory je na pár sekund.

[OgeeN]

Servery jsou nové a mají 16GB RAM.

[x]

Neco jako Real time backup server , detaily i v mail archivech. Pripadne primo pouziti snapshotu na Hammer nebo ZFS

[pavel]

rsync je spouštěný přes ssh?

[Josef Kufner]

Áno, rsync--ssh--rsync. I to umí.

[JiriHorky]

Zdravim,

toto tema me zajima. Problemu muze byt vice a to i na strane serveru a ne na strane klienta. Rsync totiz per soubor dela pomerne dost metadata operaci na strane serveru (vypisy jsou z verzi 3.0.9 na klientu a 3.0.4 na serveru):

Toto jsou operace pro jeden novy soubor na strane serveru:

3090  1350825670.190272 lstat("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/board-zoom-debugboard.c", 0x7fff95b06940) = -1 ENOENT (No such file or directory) <0.001303>

3091  1350825691.894455 select(5, NULL, [4], [4], {30, 0}) = 1 (out [4], left {29, 999997}) <0.000012>
3091  1350825691.894515 write(4, ""..., 8) = 8 <0.000019>
3091  1350825691.894582 open("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/board-zoom-debugboard.c", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000547>
3091  1350825691.895178 open("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/.board-zoom-debugboard.c.BVJsNA", O_RDWR|O_CREAT|O_EXCL, 0600) = 1 <0.002558>
3091  1350825691.897779 fchmod(1, 0600) = 0 <0.002224>
3091  1350825691.900058 write(1, ""..., 3350) = 3350 <0.003614>
3091  1350825691.903712 close(1) = 0 <0.000015>
3091  1350825691.903759 lstat("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/.board-zoom-debugboard.c.BVJsNA", {st_mode=S_IFREG|0600, st_size=3350, ...}) = 0 <0.000025>
3091  1350825691.903837 utimes("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/.board-zoom-debugboard.c.BVJsNA", {{1350825691, 0}, {1350820690, 0}}) = 0 <0.000461>
3091  1350825691.904343 chmod("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/.board-zoom-debugboard.c.BVJsNA", 0644) = 0 <0.004003>
3091  1350825691.908391 rename("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/.board-zoom-debugboard.c.BVJsNA", "linux-3.4.9-gentoo.10/arch/arm/mach-omap2/board-zoom-debugboard.c") = 0 <0.003544>

Na strane klienta pak:

32459 1350825662.709026 lstat("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/board-zoom-debugboard.c", {st_mode=S_IFREG|0644, st_size=3350, ...}) = 0 <0.000008>
....
32459 1350825681.527884 open("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/board-zoom-debugboard.c", O_RDONLY) = 3 <0.000007>
32459 1350825681.527911 fstat(3, {st_mode=S_IFREG|0644, st_size=3350, ...}) = 0 <0.000005>
32459 1350825681.527942 read(3, ""..., 3350) = 3350 <0.000313>
32459 1350825681.528286 close(3) = 0 <0.000005>

V pripade, ze soubor jiz existuje, je to jednodussi, ale z nejakeho duvoud dojde ke dvoum statum na strane serveru:

25558 1350830502.774044 lstat("linux-3.4.9-gentoo/arch/arm/mach-tegra/board-seaboard.c", {st_mode=S_IFREG|0644, st_size=7902, ...}) = 0 <0.002337>
.....
25558 1350830502.868738 lstat("linux-3.4.9-gentoo/arch/arm/mach-tegra/board-seaboard.c", {st_mode=S_IFREG|0644, st_size=7902, ...}) = 0 <0.000014>

Na strane klienta:

32643 1350830500.817663 lstat("linux-3.4.9-gentoo/arch/arm/mach-tegra/board-seaboard.c", {st_mode=S_IFREG|0644, st_size=7902, ...}) = 0 <0.000006>

Tj. na serveru se pro novy soubor dela paradoxne daleko vic metadata operaci. Na filesystemech, kde jsou metadata operace pomale, coz jsou typicky distribuovane FS , to pak jede velmi pomalu. Jestli jsem to pochopil spravne, tak je to prave Vas priklad? Jestli ano, jak dlouho trva projit tech 10M souboru findem pri COLD cachi (sync; echo 3 > /proc/sys/vm/drop_caches) na strane klientu a serveru?

Navic rsync ve verzi < 3.0.0. nejdrive udela incremental list a pak az prochazi soubory, od verze 3.0.0 to uz dela naraz. Jakou mate verzi, jake mate OS, verzi jadra? A jaka je latence mezi klientem a serverem?

[OgeeN]

Nepoužívám distribuovaný FS, nýbrž clusterový OCFS2. Filesystém je vytvořný nad sdíleným diskovým polem připojeným přes iscsi.

Projití 10M souborů trvá několik hodin. Resp. dnes ráno jsem pustil find a ještě nedoběhl.

Klient i server jsou na jednom stroji. Potřebuji synchronizovat data mezi dvěma svazky na stejném diskovém poli. Tyto svazky jsou na serveru připojeny do dvou různých složek.

rsync --version
rsync  version 3.0.9  protocol version 30
Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes

Linux w12 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Latence mezi serverem a klientem by měla být minimální, protože se oba nacházejí na stejném serveru.

[Šangala]

OT:

Projití 10M souborů trvá několik hodin. Resp. dnes ráno jsem pustil find a ještě nedoběhl.

s tím bych tedy pracovat nechtěl, když to srovnám s jednojádrem LE-1640 a 5400ot disky v mirror-u na LVM s ext3.

time find / | wc -l
1124504

real    2m55.660s
user    0m0.576s
sys     0m1.908s

Opakovaně:

real    0m9.881s
user    0m1.064s
sys     0m1.724s

Tak mi to přijde jako moc velký rozdíl.

[JiriHorky]

Diky za info. Kdyz jsem psal distribuovany FS, mel jsem na mysli i clusterovy FS - v tomto pripade je to celkem jedno, protoze v obou pripadech musite hlidat konzistenci dat a resit distribuovane zamky. OCFS2 skoro neznam, ale jelikoz pouziva DLM, metadata operace budou o rad drazsi.

Jestlize Vam samotny find jede takto dlouho, rsync na vine neni, ale taky tady neni moc co optimalizovat. Nenapada me moc, jak to pri stavajicim FS delat nejak vyrazne rychleji. Je otazka, jestli ma OCFS2 nejakou feature, ktera by se dala vyuzit (treba GPFS umi ten seznam zmenenych souboru generovat samo). Pokud ne, je treba hledat asi uplne jiny postup. Co takhle snapshoty? Nad LVM nebo mozna primo na urovni pole?

Je to asi rok, co jsem si hral s lsyncd, tj. na bazi inotify, ale taky jsem narazil na to, ze to neni uplne delane na takove mnozstvi souboru. Mozna bych inotify mechanismus ale uplne nezatracoval, treba jen v lsyncd delaji neco spatne.

[OgeeN]

Ještě sem hodím výsledky findu:

root@web:~# time find /iscsi/home/  -type f |wc -l
10696002

real    619m58.719s
user    1m26.397s
sys     108m56.076s

root@web:~# time find /iscsi/home/ |wc -l
12047276

real    42m20.375s
user    0m27.078s
sys     6m35.977s

Pokud nechám find běžet bez jakýchkoliv parametrů, tak mu projití cca 12M souborů trvá cca 42 minut.

[OgeeN]

A ještě jednou, tentokrát s vyčištěním keše:

root@web:~# sync; echo 3 > /proc/sys/vm/drop_caches
root@web:~# time find /iscsi/home/ |wc -l
12052096

real    50m38.067s
user    0m27.738s
sys     7m14.467s
root@web:~# time find /iscsi/home/ |wc -l
12052327

real    0m29.497s
user    0m8.017s
sys     0m22.129s
root@web:~# time find /iscsi/home/ |wc -l
12052383

real    0m28.665s
user    0m7.816s
sys     0m21.513s

[JiriHorky]

Zrovna jsem se na to chovani findu vcera dival. Kdyz se mu rekne -type f, zacne find stat()ovat vsechny soubory, na ktere saha. Je to trochu skoda, protoze typ souboru se da od nejake verze 2.6.4 kernelu (a pravdepodobne i v zavislosti na filesystemu) se drzi primo v dentry, tj. pro zjisteni typu souboru neni potreba delat volalni stat(). Kdyz se mu "-type f" nerekne, tak stat() na soubory nedela.

To ale prilis neresi problem s rsyncem, ktery stat() proste volat musi. Tj. OCFS2 je na stat() proste pomale, takze bud jiny FS, nebo uplne jiny pristup.

[OgeeN]

Bohužel jediný další kandidát, kterého jsem testoval byl GFS2. Bohužel už si teď nevzpomenu, proč jsem ho na konec opustil. Ale byly v tom nějaké zásadní problémy. :)

Existuje ještě nějaká alternativa k těmto dvou clusterovým filesystémům? Já jsem žádnou nenašel. Ostatní filesystémy které jsem zkoumal (coda, lustre, GlusterFS a další) dělají něco jiného než potřebuji anebo se jedná o pověstný kanón na vrabce.

Abych shrnul moje požadavky, tak potřebuji aby deset a více serverů přistupovalo na jednou pomocí iscsi k datům na sdíleném úložišti. Data musí být připojena jako rw. Filesystém proto musí řešit konkurenční zápis do souborů.

[kyytaM]

NFS alebo SMB? :)

[JiriHorky]

SMB snad radeji ani ne :) NFS by na chvili pomoct mohlo, ale je potreba si ujasnit, jestli zaruky o konzistenci cachi, ktere NFS dava, staci pro toto pouziti ci nikoliv. Pak by se dal rsync poustet na serveru, kde uz bude vhodny lokalni FS, na kterem to projiti bude daleko rychlejsi. Ocekaval bych zrychleni kolem 5-10x (viz cisla z diskuse), coz by problem na chvili odsunulo.

[Ivan]

afs, cfs, gpfs, advfs

popr. nejaky sitovy filesystem(napr. NetApp+NFS)

nemyslim si, ze pri objemu milionu souboru a deseti nodech v clusteru by bylo nejake reseni kanon na vrabce.

[Šangala]

To je asi tak trošku i na mě i když stále OT, když jsem tedy dával toto, takže mě to dá na velmi slabém HW toto:

> time find / -type f | wc -l
913191

real    2m32.735s
user    0m0.596s
sys     0m1.640s

[lertimir]

Pravděpodobně na to má hlavní vliv síťová komunikace a filesystemy. zkusil jsem podobné testy u sebe a výsledek je:

lokální disk 2 TB/5400ot filesystem XFS

time find /mnt/zaloha_1 -type f | wc -l
181213

real    0m9.366s
user    0m0.126s
sys     0m0.760s

lokální disk 2TB/5400ot filesystem NTFS (společná data pro pracovní win instalaci)

time find /windows/zaloha_2 -type f | wc -l
368354

real    1m52.077s
user    0m0.748s
sys     0m3.349s

síťový disk 2,7TB na domácím serveru/NAS, připojení NFS4 fyzická realizace soft RAID5 4x1,5TB, procesor serveru úsporné dvoujádro Zacate s 4GB paměti.

time find /mnt/basic -type f | wc -l
762845

real    5m57.818s
user    0m1.448s
sys     0m11.628s

Je zajímavé, že v průběhu find žádná komponenta nebyla na limitu, přesto hledání nebylo rychlejší. (zátěž sítě cca 1,5MB/s - 15%, CPU serveru cca 40% jednoho jádra, zátěž disků na serveru cca 10%, CPU klienta cca 5%)

[kyytaM]

Hmm...ze by pri tom spojeni cez NFS mala na vykon v tomto pripade taky velky vplyv latencia, ktora je pri komunkacii cez x vrstiev a siet o niekolko radov vyssia ako pri lokalnom FS? Mozno by bol este zaujimavy experiment namiesto NFS4 skusit iSCSI, ze ci to nejako citelne klesne. :)

[MiK]

ve zkratce: OCFS2, cluster filesystem, ZAMKY -> to ti "zpomali" veskere diskove operace, viditelne pri velkem mnozstvi malych souboru.

precti si o principu zamykani v dokumentaci k OCFS2

Tudiz, jak tu nekdo zminil, to, ze to dlouuuho trva bych odhadoval opravdu na problem (funkcnost :) ) zvoleneho filesystemu...

zkus si, jen pro porovnani a jestli mas moznost, presunout cely obsah jen na klasicky ext a provest ten rsync mezi.

[VSi]

Taky přidám zkušenost - rsync nad cca 1 M souborů a 250 GB, zdroj XFS nad 8×SAS10K disky v RAID50 / cíl EXT4, 4×1TB SATA sw RAID10.

Potřeboval jsem synchronizovat i xattr - protože Samba DOS atributy, které na XFS řešené klasickým způsobem (exec bity) dělaly různé záhadné problémy - zřejmě kombinace s default ACLs, které se chovají k exec bitům jinak než na EXT4, ale to už je jiný problém.

I když se změnilo jen pár stovek malých souborů, rsync trval třeba 8 hodin. Bez synchronizace xattr pak méně než 45 minut. Přitom dump xattr všech souborů na zdrojovém fs trvá jednotky minut... nechápu. Už aby tu bylo něco jako ZFS snapshoty a send/receive.

[d]

xattr byvaji ulozene v dalsim bloku, pokud pro ne neni nejake misto rezervovano v samotne inode, takze jejich synchronizace vyzaduje dalsi seeky.

dump xattr muze tezit z toho, ze je do jiste miry sekvencni, tzn. pokud se cteni xattr neproklada ctenim dalsich dat souboru.

[JiriHorky]

Zdravim,

podarilo se to nejak vyresit, ma pohadka stastny konec? :)

Jiri Horky

[l4m4]

To by mě taky docela zajímalo. Ačkoli podobné problémy s rsyncem nepozoruji, zjevně při ‚šťastných‘ okolnostech nastat mohou, takže by bylo užitečné vědět, kde je vlastně zakopaný pes.