Administrace komentářů

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.