Dotaz: skript pro praci s davkou mnoha malych souboru

[Tomáš Skočdopole]

Ahoj,

tvořím skritp pro zpracování mnoha (500 000) malých souborů, které jsou uloženy v různých sub-adresářích na disku. Celkem zabírají cca 30MB. Skript provádí operace cat, sed, tail, mv, rm, grep... Trvá celkem dlouho, než skript přechroustá všechny soubory.

Napadlo mě vytvořit RAM disk, do kterého by se zkopírovaly vstupní soubory a pak by se všechny operace prováděly nad těmi soubory z RAM disku. Výsledné soubory by se pak pouze nakopírovaly na HDD a RAM disk by se zrušil.

Chci se poradit jestli to tak je možné udělat, případně jakým způsobem se toto řeší.

Děkuji za rady!

Odpovědi

[Zdeněk Burda]

Vyprdni se na cat, sed, tail, mv, rm, grep... a naprogramuj to například v perlu nebo pythonu, pak se ti nebude spouštět tolik programů (předpokládám že na zpracování jednoho souboru si spustíš i několik programů najednou) a tím se to velmi znatelně zrychlí.

[Tomáš Skočdopole]

Ja jsem ten skript potreboval udelat behem kratke doby. Ted mam sice vice casu,tak ho chci vylepsit, doladit drobnosti a tak... Bohuzel nemam tolik casu na to, abych se ucil perl nebo python...

[cronin]

Vyprdni se na cat, sed, tail, mv, rm, grep... a naprogramuj to například v perlu nebo pythonu,

No ono sa to celkom lahko povie, ked ten perl/python/whatever ovladas. Sam robim s unixovskymi os uz dost dlho, ale nikdy som sa ziadny skriptovaci jazyk okrem shell-u nenaucil, pretoze som to jednoducho nepotreboval. Zaklady perlu, ktore mam, su tak male, ze by som sa ani jednoduchu ulohu nepustil riesit v perle. Naproti tomu, v shelli som uz naskriptoval toho vela, vcetne netrivialneho continuous integration systemu, samorozbalovacich instalatorov a pod.

Ako sa vravi: ked mas len kladivo, vsetko vyzera ako klinec.

[cronin]

Ahoj,

riesit performance problemy vzdy vyzaduje specificky pristup. Presne podmienky poznas len Ty a asi jedine Ty si schopny najst riesenie.

Najprv odpoved na Tvoju otazku: ano, je to mozne, a ak je problemom pomaly pristup k suborom na disku pocas vykonavania skriptu a ak zrychlenie, ktore prinesie umiestnenie suborov na ramdisk, vyvazi potrebu ich kopirovania tam a nazad. Niekto by mohol argumentovat, ze aj bez pouzitia ramdisku sa pouziva diskova cache, ale ultimativnu odpoved ziskas, len ak to skusis. Ja som nieco podobne robil pre kompilovanie jedneho projektu. Namiesto pouzitia normalneho perzistentneho adresara sa urobil adresar v adresari /tmp a pouzil sa symlink na tento adresar. Bolo to pod Solarisom, kde /tmp je swap-backed fs, takze subory sa drzia v pamati, kym nejaka je, inak idu do swapu (no a kedze tam bolo 16GB RAM, tak pamate zvycajne bolo dost). Trochu to komplikovalo buildovacie skripty, ale zrychlenie bolo tak vyznamne, ze za to jednoznacne stalo. Rozdiel oproti Tvojmu pripadu je ten, ze v mojom pripade sa ziadne subory na disk nikdy nedostali (ibazeby sa pouzil swap backend toho /tmp); jednoducho sa checkoutli z VCS do RAM, tam sa zbuildovali, maximalne sa niekde perzistente umiestnil vysledok.

Akokolvek, najprv by bolo dobre zistit, co sposobuje tak pomaly beh Tvojho skriptu. Mozno je to - ako predpokladas - pristup na disk, mozno je to spustanie velkeho mnozstva procesov (v skripte celkom bezne). Aj tu mozem ponuknut priklad: raz davno som potreboval zistit, ci sa v priblizne 200-300 riadkovom subore nejaky riadok neopakuje. Vtedy som nepoznal prikaz uniq(1) ani -u prepinac pre sort(1), tak som si urobil skript, ktory bral riadok po riadku zo suboru (a urcite to nerobil pomocou read, ale asi pomocou tail a head), a pre kazdy riadok presiel vsetky riadky za nim nasledujuce a zistoval, ci sa nerovnaju aktualnemu riadku. Tych 200-300 riadkov skontroloval za cca 30 sekund. S pouzitim sort -u je to samozrejme za "nemeratelne" kratky cas. Skus prepisat skript tak, aby sa spustalo menej procesov. Napr. namiesto pouzitia -exec v prikaze find sa da casto pouzit xargs, spracovavaj subory/zaznamy davkovo, kde je to mozne. Prestuduj si manualy pouzivanych nastrojov ako napr. grep, mozno objavis nieco uzitocne.

Kazdopadne, akykolvek performance problem treba riesit identifikovanim najpomalsieho miesta.

[Ash]

... sloučit víc procesů které (možná) jsou za sebou v pipeline, to je asi nejčastější "prohřešek", cat je potřeba velmi velmi zřídka, grep před sedem asi nikdy, uniq za sort jen ojediněle a pod. Co nejvíc využívat možnosti bashe foo=$(<file) foo=${boo%% *} atd.

[Ash]

A dosti podstatné -- pokud se hodně zpracovává text v ne-multibyte kódování, tak používat globálně nebo před příkazy LANG=C, ony ty mb_* rutiny mají takový háček takže je to s nimi často řádově pomalejší.

[Tomáš Skočdopole]

dekuji za odpoved, zase jsem o neco chytrejsi :)

Tak ja to zkusim zatim s tim RAM diskem a uvidim...

[Baba Jaga]

Hmmm, Linux Ramdisk mini-HOWTO je na http://www.vanemery.com/Linux/Ramdisk/ramdisk.html .

Na openSUSE 10.2 /dev/ram* mam:

> uname -r
2.6.18.8-0.9-xen
> dmesg | grep RAMDISK
RAMDISK driver initialized: 16 RAM disks of 128000K size 1024 blocksize

ale na openSUSE 10.3 s jadrem 2.6.22.17-0.1-default uz ne. Vi nekdo, jak se tam pracuje s ramdiskem?

[happy barney]

použi /dev/shm

[Baba Jaga]

Jak? V /dev/shm je na openSUSE spousta veci:

> ls -laR /dev/shm
/dev/shm:
total 0
drwxrwxrwt  3 root root   60 2008-02-13 09:05 .
drwxr-xr-x 11 root root 7200 2008-02-13 09:05 ..
drwxr-xr-x  3 root root  360 2008-02-13 09:05 sysconfig

/dev/shm/sysconfig:
total 48
drwxr-xr-x 3 root root 360 2008-02-13 09:05 .
drwxrwxrwt 3 root root  60 2008-02-13 09:05 ..
-rw-r--r-- 1 root root   5 2008-02-13 09:05 config-eth0
-rw-r--r-- 1 root root   5 2008-02-13 09:05 config-eth1
-rw-r--r-- 1 root root   3 2008-02-13 09:05 config-lo
-rw-r--r-- 1 root root  29 2008-02-13 09:05 if-eth0
-rw-r--r-- 1 root root  29 2008-02-13 09:05 if-eth1
-rw-r--r-- 1 root root  27 2008-02-13 09:05 if-lo
-rw-r--r-- 1 root root   7 2008-02-13 09:05 ifup-eth0
-rw-r--r-- 1 root root   7 2008-02-13 09:05 ifup-eth1
-rw-r--r-- 1 root root   7 2008-02-13 09:05 ifup-lo
-rw-r--r-- 1 root root  11 2008-02-13 09:05 network
-rw-r--r-- 1 root root   8 2008-02-13 09:05 new-stamp-2
-rw-r--r-- 1 root root   8 2008-02-13 09:05 new-stamp-3
-rw-r--r-- 1 root root   0 2008-02-13 09:05 ready-eth0
-rw-r--r-- 1 root root   0 2008-02-13 09:05 ready-eth1
-rw-r--r-- 1 root root   0 2008-02-13 09:05 ready-lo
drwxr-xr-x 2 root root  60 2008-02-13 09:05 tmp

/dev/shm/sysconfig/tmp:
total 0
drwxr-xr-x 2 root root  60 2008-02-13 09:05 .
drwxr-xr-x 3 root root 360 2008-02-13 09:05 ..
-rw-r--r-- 1 root root   0 2008-02-13 09:05 test

[happy barney]

napr: mkdir /dev/shm/cache$$

viac info: google

[Tomáš Skočdopole]

No tak jsem to zkousel to mini-HOWTO... Na mém ubuntu se vytvoří ramdisk o velikosti cca 60 MB. Což pro mých 30MB souborů stačí.

Chtěl jsem se zeptat, jakým způsobem lze specifikovat vlastní velikost ramdisku. Pokud bych někdy potřeboval větší prostor... Tam to bylo řešené pomocí parametru jádra v grubu + restart systému.

Jiná možnost není?

[jazz]

Ja treba po vzoru Solarisu pozivam prostor /tmp jako souborovy system tmpfs (viz /dev/shm).

V /etc/fstab mam:

# fs   mountpoint  type   opts                     dump/pass
tmpfs  /tmp        tmpfs  defaults,size=1G,noatime     0 0

Samozrejme zmenou mountpointu muzete vytvorit jiny svazek. Vyhoda reseni je, ze pristup je rychly (v mem pripade /tmp je pouzivan pouze scripty pro zpracovani vetsiho mnozstvi dat - ulozeni opravdu docasnych souboru, ulozeni socketu), nepouziva se diskova cache a definovana velikost neni rezervace (v pameti zabira tolik mista, kolik je ulozeno dat). Jak jiz bylo napsano, pokud nemate dost pameti, bude se swapovat.