Wykonanie komendy rm -rf w ogromnym drzewie katalogów zajmuje wiele godzin

20

Używamy rsnapshot do tworzenia kopii zapasowych. Przechowuje wiele migawek kopii zapasowej pliku, ale usuwa stare. To jest dobre. Jednak rm -rfwykonanie ogromnego drzewa katalogów zajmuje około 7 godzin . System plików to XFS. Nie jestem pewien, ile jest plików, ale prawdopodobnie jest to milion.

Czy w ogóle można to przyspieszyć? Czy jest jakieś polecenie, które działa tak samo rm -rfi nie zajmuje godzin?

— Rory
źródło

1

Użyłem find . -delete -name directoryi jest znacznie szybszy niż rm -rf.

— Paolo,

38

Nie.

rm -rfwykonuje rekurencyjną, pierwszą analizę głębokości systemu plików, wzywając unlink()każdy plik. Dwie operacje powodujące powolny przebieg procesu to opendir()/ readdir()i unlink(). opendir()i readdir()zależą od liczby plików w katalogu. unlink()zależy od wielkości usuwanego pliku. Jedynym sposobem, aby przyspieszyć to, jest albo zmniejszenie rozmiaru i liczby plików (co, jak podejrzewam, nie jest prawdopodobne), albo zmiana systemu plików na jeden z lepszymi właściwościami dla tych operacji. Uważam, że XFS jest dobry dla unlink () dla dużych plików, ale nie jest tak dobry dla dużych struktur katalogów. Może się okazać, że ext3 + dirindex lub reiserfs jest szybszy. Nie jestem pewien, jak dobrze radzi sobie JFS, ale jestem pewien, że istnieje wiele testów wydajności różnych systemów plików.

Edycja: Wygląda na to, że XFS jest okropny w usuwaniu drzew , więc zdecydowanie zmień swój system plików.

— David Pashley
źródło

1

Kilka lat temu zauważyłem straszną wydajność przy użyciu reiserfs w podobnym przypadku użycia.

— knweiss,

1

Cudowny post!

— wzzrd

2

Prawie tylko powiedział „nie” :)

— David Pashley,

2

Zgadzam się ze wszystkim tutaj oprócz twojego stwierdzenia, że szybkość rozłączania zależy od wielkości pliku. unlink po prostu usuwa link do pliku i nie robi nic z rzeczywistą zawartością. Nie powinno być zauważalnej różnicy między plikami o różnych rozmiarach (możesz to przetestować sam).

— Kamil Kisiel

@KamilKisiel Masz rację mówiąc, unlinkże nie robi nic z rzeczywistą zawartością, ale aby wykonać unlinkwywołanie systemowe, kod systemu plików ma jednak jeszcze więcej pracy, jeśli usunięty link jest ostatnim plikiem i jeśli nie jest on aktualnie otwarty. Jest to oczywiście zależne od systemu plików, ale wtedy może być bardzo zauważalna różnica, gdy usunięty plik jest ogromny.

— jlliagre

22

Alternatywnie przenieś katalog na bok, utwórz go ponownie z tą samą nazwą, uprawnieniami i własnością, a następnie uruchom ponownie wszystkie aplikacje / usługi, które dbają o ten katalog.

Możesz wtedy „nice rm” oryginalny katalog w tle, nie martwiąc się o przedłużoną awarię.

— Greg Work
źródło

To może zadziałać, ponieważ mv jest bardzo szybki.

— Rory

Tak - działa dobrze. Użyłem tej techniki wiele razy, aby „naprawić” skrzynki pocztowe oparte na katalogu maildir, w których klient poczty stracił mózg i zostawił bałagan na dysku. Największy (pojedynczy) katalog, który tak naprawiłem, zawierał około 1,5 lub 2 miliony plików IIRC. Całkowity czas przestoju dla użytkownika końcowego wynosił ~ 3 minuty, z których większość czekała na śmierć klienta poczty i procesów imap.

— Greg Work

7

Upewnij się, że masz ustawione odpowiednie opcje montowania dla XFS.

Użycie -ologbufs = 8, logbsize = 256k dla XFS prawdopodobnie potroi wydajność usuwania.

— James
źródło

2

+1 za tę wskazówkę ... Należy również włączyć leniwe liczniki, aby uzyskać kolejny wzrost wydajności.

— hurikhan77

1

Wyjaśnienie tych ustawień byłoby pomocne dla przyszłych czytelników.

— Aron Rotteveel

5

Jeśli rm wykonuje się efektywnie na poziomie pliku, zajmie to dużo czasu. Dlatego migawki blokowe są tak dobre :).

Możesz spróbować podzielić RM na osobne obszary i spróbować zrobić to równolegle, ale nie mogę oczekiwać, że poprawi to. Wiadomo, że XFS ma problemy z usuwaniem plików, a jeśli jest to duża część tego, co robisz, być może inny system plików to byłby pomysł.

— James
źródło

Migawki oparte na blokach nie są w tym przypadku wyjątkowo dobre. Wiele systemów plików --- WAFL i ZFS przychodzą od razu do głowy --- zapewniają również dobrą wydajność usuwania migawek. Migawki traktują jak obiekty systemu plików pierwszej klasy. Zamiast więc iterować (powoli) miliony plików w celu ustalenia, które bloki mają zostać zwolnione, wystarczy spojrzeć na listę bloków powiązaną z migawką.

— Keith Smith

Hmm Prawdopodobnie wyszedłem jako zbyt przeciwny powyżej. Oryginalny plakat musi używać Linuksa, a tak naprawdę nie ma sprawdzonego systemu plików Linux, który robi migawki --- chociaż btrfs i nilfs wyglądają interesująco na przyszłość. W związku z tym zgadzam się --- lepiej używać migawek blokowych.

— Keith Smith

+1 za wskazówkę dotyczącą podziału i równoległego obciążenia: xfs gra swoją siłę na równoległych obciążeniach.

— hurikhan77

5

Dobrze jest używać ionice do operacji intensywnie korzystających z IO, niezależnie od używanego systemu plików.
Proponuję to polecenie:

ionice -n7 nice rm -fr nazwa_katalogu

Będzie dobrze grał w przypadku operacji w tle na serwerze z dużym obciążeniem IO.

— ash108
źródło

2

Wiem, że to stare, ale pomyślałem, że podrzuciłem sugestię. Usuwasz te pliki sekwencyjnie, wykonywanie równoległych operacji rm może przyspieszyć.

http://savannah.nongnu.org/projects/parallel/ parallel można powszechnie stosować zamiast xargs

więc jeśli usuwasz wszystkie pliki w deltedir

find -t f deletedir | parallel -j 10 rm

Pozostawiłoby to tylko puste struktury katalogów do usunięcia.

Uwaga: prawdopodobnie nadal będziesz napotykać ograniczenia systemu plików, jak wspomniano powyżej.

— Nick Anderson
źródło

Jaka jest zaleta korzystania z równoległości nad xargs?

— Rory

1

Czy alternatywną opcją byłoby rozdzielenie danych w taki sposób, aby można było śmieci i odbudować rzeczywisty system plików zamiast rm?

— Muczeć
źródło

3

Myślę, że rsnapshot używa twardych dowiązań w ramach funkcji utrzymywania wielu migawek wydajnie. Więc jeśli pytający używa tej funkcji przy użyciu osobnych systemów plików, nie będzie działać (ponieważ nie można na

— stałe

0

Co powiesz na zmniejszenie uprzejmości polecenia? Lubić:

nice -20 rm -rf /path/to/dir/

— RainyRat
źródło

5

Wąskim gardłem nie jest program planujący, to system plików, powiedziałbym.

— Manuel Faux

W mało prawdopodobnym przypadku, gdy harmonogram jest wąskim gardłem, w końcu tylko uderzasz w podsystem we / wy, czyniąc serwer jeszcze mniej użytecznym podczas rm.

— David Mackintosh