Dotaz: python 2.7 : tar pomocí subprocess

[Milan Uhrák]

Zdravím všechny .. píšu takový skriptík, který cosi vyhodnotí u haldy souborů, soubory, které projdou sítem si zaznamená do pomocného souboru-seznamu a tento seznam poté podstrčím taru ( a mimo jiné mně zajímá, jak dlouho se s tím tar bude trápit ).

pack_start = time.time()
pack = Popen(['tar', '-cJf', account_archive,'-T'+account_filelist ])
pack.wait()
pack_end = time.time()

řešení to není špatné (rozumějte - funguje ) , ale tar asi používá maximální kompresi. Pokoušel jsem se do volání Popen propašovat XZ_OPT=3, ale tudy asi cesta nevede ( nebo nevím jak na to ).

je nějaká jiná možnost jak vyladit kompresi a mít možnost získat čas potřebný k zabalení ?

prý přes shell to není bezpečné, psali někde na SOwerflow, ale zas takový kabrňák nejsem, abych to posoudil.

Jinak komprese trvá skoro 19 hodin a když to stáhnu na 10 bude to stačit ( 140GB pošty )

Nevadilo by mi ani volání taru v nějaké funkci, která by ten čas komprese hlídala, ale zároveň umožnila skriptu pokračovat v přípravě dalšího seznamu, ( komprimuju poštu po účtech( 1 účet = 1 složka = 1 archiv + csv s obsahem ( kdy predmet, kdo ) ne vše najednou ) případně spuštění dalšího vlákna s tarem ( čtyřjádro - asi bych to hlídal na max 3 tar-vlákna ( jak ?? ) )

Mám nástín, ale zatím nevyzkoušeno - pakování do funkce a tu volat subprocess.popen, ve funkci zase subprocess.popen tar a čekat na něj. jak ohlídat jen 3 spuštěné tary zatím nevím. Snad nějaký counter (globální proměnná ), který by to hlídal ... funguje to ale ve vláknech ? aby se nepoprali o tu proměnnou ?

Předem děkuji i za částečné nakopnutí správným směrem.

1, vyladit kompresi taru / použít jiný postup pro kompresi

2. popsat nějaké schéma, jak komprimovat ve více vláknech ( jasně, čas komprese budou mít jednotlivá vlákna asi pěkně natažený, ale snad to celkový čas zmenší )

Milan

---

---

Odpovědi

[NN]

Je nutne ten tar volat externe, modul tarfile nestaci?

[Milan Uhrák]

ahoj, tarfile 2.7 neumí xz jen (b|g)zip .. i když .. napadá mne, proč prostě nepoužít zip .. původním cílem bylo udělat archiv co nejmenší, ale zase ta cena ( čas ) .. takže jdu na kmpromis .. a to už xz asi netreba. Nebo je o tolik lepší ?

Tar volám proto, že si !!!myslím!!! že spustit tu kompresi v binárce bude efektivnější než to tlačit přes interpreter. Možná nevím, jak knihovně podstrčit seznam 10k souborů. Kdysi jsem něco podobného řešil přes pylzma nebo jak to bylo .. dopad byl ten že se dal progress komprese i efektivita sledovat průběžně, nevýhodou bylo, že ta py-knihovna měla jakýsi bug, a nešla nastavit komprese nebo něco, už si to nepamatuju. časy jsem tehdy neporovnával, šlo jen o jeden soubor ( obraz disku vytvářený pythonem ( namísto dd | tar ), ale pak jsem našel lepší řešení a toto jsem zapudil )

[Jendа]

prý přes shell to není bezpečné, psali někde na SOwerflow

Pokud tam nebudeš předávat argumenty, které ti dal uživatel, tak je to v pohodě.

Nevadilo by mi ani volání taru v nějaké funkci, která by ten čas komprese hlídala, ale zároveň umožnila skriptu pokračovat v přípravě dalšího seznamu

Já na tohle vždycky pouštěl thread… Řekne se prostě threading.Thread(target=funkce, args=(a,b,c)); t.start()

je nějaká jiná možnost jak vyladit kompresi

tar c | xz -3 > foo ?

[Milan Uhrák]

Pokud tam nebudeš předávat argumenty, které ti dal uživatel, tak je to v pohodě

ne, skript běží pod rootem

tar c | xz -3 > foo

tak ono to jde i ( v shellu ) XZ_OPT=3 tar -cJf "$bkfile" -T$usersez

čili podobně subprocess.popen( "cely prikaz" shell=true ) ...

ale ten shell .. jak jsem psal - na SO jednomu tazateli rozmlouvali.

každopádně díky za navedení. Dá se u threadu sledovat, zda ještě "žije" ?

[Jendа]

ne, skript běží pod rootem

A?

Ten problém se shellem je prostě v tom, že když tam dáváš argumenty od uživatele, je složité to korektně escapovat tak, aby když ti uživatel zadá ";rm -rf /*;, tak to shell nevyhodnotil jako další příkaz. Ty tam ale argumenty od uživatele, jestli to chápu dobře, nemáš (předáváš tam jen jméno souboru, které si sám generuješ).

[Milan Uhrák]

Ahoj, daty uživatelů jsem myslel nějaké loginy a tak .. ne, z pohledu skriptu se jedná o prostou kompresi souborů, zdrojová cesta je zadrátovaná, cílová taky, skriptu předávám jen hloubku archivace ( počet dní, během kterých došlo ke změně / vytvoření souboru ).

[Milan Uhrák]

Pre nastavenie premennej prostredia stačí pred tým Popen použiť os.putenv("XZ_OPTS", "3")

Ak používaš Python3, môžeš pri tej funkcii wait použiť aj argument timeout a ak sa program v tom čase neskončí, vyhodí tá funkcia výnimku subprocess.TimeoutExpired. Takže nie je problém pospúšťať viac programov pomocou Popen a potom si na počkať volaním wait v nejakom cykle.

Prípadne môže byť vhodnejšie použiť funkciu poll (a sleep). Wait sa potom použije len ak poll nevráti None (a teda program sa ukončil).

[Milan Uhrák]

Tohle zní dobře, děkuji

[Milan Uhrák]

Ještě - je to trochu off topic - když jsem viděl, jak se ten xz blob chová ... listing souborů až po dekompresi xGB .. brr ..

Tohle ne ... přemýšlím nad úplně jiným kompresním programem .. což je tedy problém .. Ale : technicky vzato - všechny soubory patří jednomu uživateli (mail:mail) , čili by šel pustit i 7z, žádné specifické metadata tam nejsou.. koukal jsem teď na man a diskuze o 7z a vypadá to schůdně. Navíc umí multithread (snad) .. tak odpadá hlídání procesů. Zkusím to a dám vědět.

Je to trochu prasárna, ale ÚSP :)

Děkuji všem za brainstorming, nápady a rady ..

Milan

[Milan Uhrák]

Výsledkem použití 7z je to, že archivy maji dohromady o skoro polovinu méně ( 39 proti 68 ) a komprese trvala nikoliv 19, ale 6 hodin ( stav z dnešního nočního -stale-ještě-testovacího-spuštění )

Takový výsledek je ale nefér srovnávat. Dost pomohlo asi to, že :

- před započetím komprese se prováděl rsync pošty na jiný mezisklad.

- mimo jiné jsem přišel na to, že v meziskladu je balast, který tam nemá co dělat ( rsync jede postupně po složkách, nesyncuje tu nadřazenou ), tedy válelo se tam pár GB složek již neaktivních účtů )

i přesto

- 69GB původní velikosti je očesané o neaktivní účty - velikost neaktivních byla tak max 1/10 celkové velikosti ( největší nápor na diskový prostor má 7-8 účtů z 60 - asi 70% ze všech, a ty jsou stále aktivní )

takže udělám porovnání nejmohutnějšího účtu :

souborů	    celkem	lidsky	  čas komprese	lidsky		   archív	kompr. poměr
29676	   20569932136	20.0GB     10,797.59	02:59:57.592  13261289712	0,64
17021	   17133312262	17.0GB	   4900,4	01:21:40.3    9398976354	0,55

čili i na tomto vzorku je vidět, že 7z zabodoval.

[aaa]

Také řeším spouštění více podprocesů současně a zajímal by mě doporučený způsob. Používám něco takového.

from concurrent.futures import ThreadPoolExecutor as Executor                                                                          
import subprocess                                                                                                                      
                                                                                                                                       
                                                                                                                                       
def run_command(cmd):                                                                                                                  
    p = subprocess.Popen(cmd)                                                                                                          
    p.wait()                                                                                                                           
    return p.pid                                                                                                                       
                                                                                                                                       
def execute(commands):                                                                                                                 
    with Executor(max_workers=3) as executor:                                                                                          
        for pid in executor.map(run_command, commands):                                                                                
            print(pid)                                                                                                                 
                         

Jsou lepší vlákna nebo event loop?