Helló
Olyan problémába futottam bele, hogy van egy könytár nagyon sok fileval. Nem tudom mennyi, mert akármilyen parancsot is adok ki mindegyik előbb be akarja parse-lni és előbb utóbb elfogy a memória (16G). Mv, rm, find semmi se segít. Milyen módszerrel lehetne törölni ezt a könyvtárat. Csak filek vannak benne alkönyvtárak nincsenek.
- 2838 megtekintés
Hozzászólások
find elvileg nem parsol előre, hogy próbáltad?
find /ez/a/dir -type f -exec rm -f {} \;- A hozzászóláshoz be kell jelentkezni
Ha olyan sok fájl van, hogy az ls kiakad, akkor új rm-et indítani minden egyes fájlhoz nem túl jó ötlet, sosem fog véget érni.
find /ez/a/dir -type f -print0 | xargs -0 rm -f
- A hozzászóláshoz be kell jelentkezni
Nem nyert ez is elkezdi tölteni a memóriát. :(
- A hozzászóláshoz be kell jelentkezni
Hülye ötlet, de nem lenne jobb "részekre bontani" a törlést?
for i in {a..z}; do for j in {a..z}; do rm -f $i$j*; done; done;
for i in {A..Z}; do for j in {a..z}; do rm -f $i$j*; done; done;
for i in {a..z}; do for j in {A..Z}; do rm -f $i$j*; done; done;
for i in {A..Z}; do for j in {A..Z}; do rm -f $i$j*; done; done;
Plusz ezek számos variációi. Egyébként nem tudok elképzelni annyi állományt hogy azoktól a rendszer megegyen 16 Gb RAM-ot. Meg tudod mondani, melyik processz eszi meg a memóriát? Lehet állományrendszer hiba és/vagy kernel bug? Milyen fs?
- A hozzászóláshoz be kell jelentkezni
find . -type f -delete
- A hozzászóláshoz be kell jelentkezni
Ez is ugyan azt hozza, elkezd nőni a memória használtság drasztikusan. Adalék még, hogy nfs-n van a könyvtár.
- A hozzászóláshoz be kell jelentkezni
Ha ez nem segít, akkor semmi se.
Oda kell menni az nfs szerverhez, és azon kiadni a parancsot.
Ja, és az nem baj, ha elkezd nőni a memóriafogyasztás, és előbb-utóbb elhal a kliens - ha mire idáig eljut, egy csomó fájlt le tudott törölni, márpedig ennek így kéne lennie. Mert így a reboot után lehet folytatni tovább.
Amúgy én is arra tippelek, hogy a swap hiánya és/vagy egyéb vfs/inode cache paraméterek okozzák, hogy a memóriafogyasztás végén meghal a gép.
- A hozzászóláshoz be kell jelentkezni
"nfs-n van a könyvtár"
Kár, hogy ezt elfelejtetted említeni. Ott kell törölni, ahol a fájlok vannak.
--
HUPbeszolas FF extension
- A hozzászóláshoz be kell jelentkezni
Pontosan. Saccra milliós nagyságrendben kiadni szinkron (= 1 round-trip / 1 file) műveletet ekkora távolság felett nem menő. ssh.
- A hozzászóláshoz be kell jelentkezni
Igen csak ez egy NAS amihez nincs ssh.
- A hozzászóláshoz be kell jelentkezni
-delete: jé, mindig tanul az ember valami újat :)
- A hozzászóláshoz be kell jelentkezni
+1 :)
- A hozzászóláshoz be kell jelentkezni
butaság, törölve
- A hozzászóláshoz be kell jelentkezni
Még jó, hogy nem kezdtem el hosszabban gondolkodni a dolgon :-)
- A hozzászóláshoz be kell jelentkezni
Ja. Az nem esett le elsőre, hogy az rm csak olyat tud törölni, amin a find már átment. X bejegyzés törlése pedig nem lehet hatással az Y bejegyzés láthatóságára (vagyis nem tudja átverni a find-ot, hogy az Y-t ne vegye észre). Legalábbis a readdir() speckó nem tűnik ezt megengedni.
- A hozzászóláshoz be kell jelentkezni
Ha ki tudod számolni, hány fájlnál telik meg a ram, akkor alkothatsz regexpet, ami legfeljebb annyit töröl egyszerre. Vagy a regexp alapján történő parse-olás is az összes fájlra vonatkozik?
Eszembe jutott egy valószínűleg működő, de nagyon ronda megoldás. Adj neki sok-sok-sok giga swapet!
- A hozzászóláshoz be kell jelentkezni
Ha nem fut le az ls, akkor a regexp matching sem fog lefutni, mert ugyanúgy végig akarja olvasni előbb az egész könyvtárat...
- A hozzászóláshoz be kell jelentkezni
esetleg, ha n fájlnál akad le, akkor az első n-1-et inode-onként törölni?
- A hozzászóláshoz be kell jelentkezni
Ezt csinálja a find . -type f -delete, egyesével, inode-onként.
Ha ez sem jó, akkor semmi se...
- A hozzászóláshoz be kell jelentkezni
lehet, hogy orbitális hülyeség, de mi történik, ha csak a tartalmazó könyvtár inode-ját töröljük?
- A hozzászóláshoz be kell jelentkezni
Próbáld ki.
mkdir a
touch a/a
rmdir a
- A hozzászóláshoz be kell jelentkezni
nem így értem. ha fs szinten eltávolítjuk a node-ot, anak katasztrofális következményei lehetnek?
- A hozzászóláshoz be kell jelentkezni
Én meg nem értem, hogy miről beszélsz.
A fs úgy működik, hogy bizonyos műveleteket lehet rajta végrehajtani (mkdir, rmdir, create, ln, mv, rm meg haverjaik). Azt gondoljuk elvárásnak a fs felé, hogy minden művelet akkor "kész", amikor a feladatát elvégezte, módosította a fs-t úgy, hogy az a változtatás után ismét konzisztens állapotban van. Az általad említett művelethez a konzisztencia jegyében hozzátartozik, hogy a directory-ban levő neveket el kell előbb távolítani, az azok által hivatkozott inode-ok usecount-ját eggyel csökkenteni, ha így valamelyik 0 lett, akkor a hozzátartozó diszkterületet felszabadítani (ha nem fogja még futó processz).
El lehet hagyni ezeket, de akkor a művelet végrehajtása után reboot és fsck fog kelleni...
- A hozzászóláshoz be kell jelentkezni
igen, itt van a kutya elásva. ha az fsck rendbeteszi, akkor többé a fájlok sem láthatók, nem?
(az megoldható, hogy bele dd-zünk egy rakás nullát a könyvtárba? már ha meggyőződtünk róla, hogy a fájlok által takart terület összefüggő)
- A hozzászóláshoz be kell jelentkezni
Az fsck rendbe teszi. Apró probléma, hogy NFS-en van az egész, ergó a szerveren lehet/kell rebootolni/fsck-zni.
A directory-ba nem tudsz dd-zni, mert a fs nem enged ilyet. Ott csak a fs műveletekkel lehet matatni.
- A hozzászóláshoz be kell jelentkezni
így már minden világos, köszönöm!
- A hozzászóláshoz be kell jelentkezni
find /bla/* | xargs rm
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Ez duplán nem jó. A find /bla/* kapásból végig akarja olvasni a könyvtárat, plusz a fájlnevek listáját abc-rendbe rakni, majd command line paraméterként a find-nak átadni (ez mire jó?), majd utána ugyanezt a find mégegyszer eljátssza, amikor az xargsnak próbálja átadni a paraméterlistát...
- A hozzászóláshoz be kell jelentkezni
find /dirname | xargs rm
-et akartam irni, termeszetesen. NFS-en nem probaltam, de helyben mukodnie kell akarmennyi fajlra.
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Igen, ez csak egyszer követi el az említett hibát ;-)
Szóval az rm egy fájlt sem töröl addig, amíg a teljes listát meg nem kapja a find-tól (mert be sem indul addig), ahhoz pedig végig kell olvasni a könyvtárat, plusz a teljes listát át kell tudni adni command line paraméterként.
...
Lehet annyi fájlt egy könyvtárba berakni, hogy őket ne tudjad felsorolni egy command line listába (mondjuk ha a teljes RAM + swap terület byte-ban kevesebb, mint ahány karakter kell a neveiket leírni, az triviális megoldása ennek). Akkor az lokális fs-en sem fog menni...
- A hozzászóláshoz be kell jelentkezni
Add a xargs argumentumlistájához az -L1000 (vagy tetszőleges szám) opciót, akkor amint összejött annyi elem, kiadja az rm parancsot azokkal.
- A hozzászóláshoz be kell jelentkezni
Az xargs alapbol darabolja a parameterlistat, ez az egyik lenyege. Tehat tobbszor meg fogja hivni az rm-et, a maximalis megengedett szamu parameterrel.
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Olvasva a hozzászólásokat, felmerült bennem a kérdés, hogy miből látszik, hogy elfogy a memória? A free/top szerint, vagy elkezd dögleni a gép és az oom killer elkezd lövöldözni a processekre?
Nem csak arról van szó, hogy elhasználja cache-nek a memóriát, ami teljesen normális, jó, stb. stb.?
Illetve ha nagyon sok fálj van, akkor az rm * a paranccsor hosszába fog belefutni, szóval én szeretnék egy pontos hibaüzenetet, mert lehet hogy tévúton járunk.
- A hozzászóláshoz be kell jelentkezni
Nos a jelenseg. htop-ban látom hogy elkezd nőni a memória használtság, 6G-ról szépen felkúszik 14G-ra (16G van a szerverben), majd X perc után elkezd nőni a load akár 60-ra is és az oom killer kilövi a proceszt.
- A hozzászóláshoz be kell jelentkezni
rendes rendszerekben az ls -nek van (asszem) -f opciója, aminek lényege, hogy nem rendezi a listát, hanem a könyvtárbeli sorrendnek megfelelően listáz. Ebben az esetben nem kell neki semmit kesselni, lévén a kapott neveketz simán lehet kiírni. Így kb:
while true: ; do
rm `ls -1f | head -50`
done
De ha nem megy, akkor lehet perl szkriptet írni, amely az opendir/readdir/closedir használatát megfűszerezi egynéhány (szintén értelemszerűen 50-100) nevenként meghívott unlink-kel. (Ha rosszul emlékszem, és a perl-féle unlink csak egy nevet fogad el, akkor egyesével.) Speciel a *dir C-library rutinok nem rendeznek, tehát nem szabad memóriát zabálniuk.
- A hozzászóláshoz be kell jelentkezni
a ls -f nekem is eszembe jutott, de meggyőződésem volt, hogy az is beolvassa az egész kócerájt. ha nem, akkor remek tanulság.
- A hozzászóláshoz be kell jelentkezni
Nos ez működik. köszönöm. Pedig ezt én is néztem, de aztán valami másik kapcsolot próbáltam ls mivel az is cachelt ezért nem probáltam tovább az ls-t.
- A hozzászóláshoz be kell jelentkezni
késő bánat, de jó lett volna tudni, hány file-ról van szó :)
- A hozzászóláshoz be kell jelentkezni
Jah én is kiváncsi lettem volna de szerintem millió felett volt.
- A hozzászóláshoz be kell jelentkezni
Hát vagy mégtőbb :) 16 GB RAM elfogyott, tehát ettől szerintem több
- A hozzászóláshoz be kell jelentkezni
tudod a lefedett fs-területet és a fájlok átlagos méretét?
- A hozzászóláshoz be kell jelentkezni
A perl-es megoldáson gondolkodtam én is, csak mennem kellett a gyerkőcért :-)
- A hozzászóláshoz be kell jelentkezni
chdir('/bla');
opendir(DIR, '.') || die 'opendir';
while (readdir(DIR)) {
next if -d $_;
unlink $_;
}
closedir(DIR);
- A hozzászóláshoz be kell jelentkezni
ls | xargs rm
vagy
ls | head -n 1024 | xargs rm
nem segít?
- A hozzászóláshoz be kell jelentkezni
ls -1 | xargs rm
Tutira működik...
- A hozzászóláshoz be kell jelentkezni
Mintha explicit leírta volna, hogy - mivel az ls ABC-rendbe akarja rendezni a fájlneveket, ehhez össze kell gyűjteni az összeset - szépen elfogy a memória. Ezen nem változtat az a tény, hogy kierőszakolod tőle, hogy soronként csak 1 db nevet írjon, hiszen attól még rendezni akarja. De föntebb akad már két működő megoldás is :-)
- A hozzászóláshoz be kell jelentkezni
Jólvanna.. :) kissé fáradt/figyelmetlen voltam amikor írtam. Viszont én is futottam már ilyenbe és nekem ez segített. Igaz nem milliós nagyságrendben, de volt vagy 100K+ file. Egy kb. 512M/1G memóriás gépnél. És nem vettem észre, h felemésztette volna a memóriát (igaz nem is figyeltem, mert láttam, h lassan de biztosan törli).
- A hozzászóláshoz be kell jelentkezni