Chciałbym usunąć katalog pamięci podręcznej nginx, który szybko wyczyściłem:
mv cache cache.bak
mkdir cache
service nginx restart
Teraz mam cache.bak
folder zawierający 2 miliony plików. Chciałbym go usunąć bez zakłócania pracy serwera.
Prosty rm -rf cache.bak
wysyła serwer, nawet najprostsza odpowiedź HTTP zajmuje 16 sekund podczas działania rm, więc nie mogę tego zrobić.
Próbowałem ionice -c3 rm -rf cache.bak
, ale to nie pomogło. Serwer ma dysk twardy, a nie dysk SSD, prawdopodobnie na dysku SSD może to nie stanowić problemu.
Uważam, że najlepszym rozwiązaniem byłoby ograniczenie przepustowości, tak jak działa wbudowany menedżer pamięci podręcznej nginx.
Jak byś to rozwiązał? Czy jest jakieś narzędzie, które może to dokładnie zrobić?
ext4 na Ubuntu 16.04
linux
ubuntu
filesystems
ext4
hyperknot
źródło
źródło
rm
używając nicea ?Odpowiedzi:
Utwórz skrypt bash w następujący sposób:
Zapisz
deleter.sh
na przykład z nazwą . Uruchom,chmod u+x deleter.sh
aby był wykonywalny.Ten skrypt usuwa wszystkie pliki przekazane mu jako argumenty, a następnie śpi 0,5 sekundy.
Następnie możesz biegać
To polecenie pobiera listę wszystkich plików w pliku cache.bak i przekazuje pięć nazw plików jednocześnie do skryptu usuwania.
Możesz więc dostosować, ile plików jest usuwanych jednocześnie i jak długo występuje opóźnienie między każdą operacją usuwania.
źródło
xargs
rozumie maksymalny rozmiar wiersza poleceń i domyślnie próbuje go nie przekraczać. Ten ma dodatkowe limity nie więcej niż 5 ścieżek na raz.Powinieneś rozważyć zapisanie pamięci podręcznej w osobnym systemie plików, w którym możesz zamontować / odmontować, jak podano w komentarzach. Dopóki tego nie zrobisz, możesz użyć tej jednej linijki,
/usr/bin/find /path/to/files/ -type f -print0 -exec sleep 0.2 \; -exec echo \; -delete
zakładając, że Twój plik binarny znajduje się w / usr / bin i chcesz zobaczyć postęp na ekranie. Dostosuj odpowiednio sen, aby nie nadmiernie obciążać dysku twardego.źródło
-print0
tutaj, ponieważfind
nigdzie nie przesyłamy danych wyjściowych .Możesz wypróbować ionice na skrypcie pobierającym dane wyjściowe polecenia find. Coś w stylu:
W zależności od systemu plików każde usunięcie pliku może spowodować przepisanie całego katalogu. W przypadku dużych katalogów może to być hit. Wymagane są dodatkowe aktualizacje tabeli i-węzłów i ewentualnie lista wolnego miejsca.
Jeśli system plików ma kronikę, zmiany są zapisywane w kronice; stosowany; i usunięty z dziennika. Zwiększa to wymagania We / Wy dla intensywnej aktywności zapisu.
Możesz użyć systemu plików bez dziennika dla pamięci podręcznej.
Zamiast jonice możesz użyć komendy uśpienia, aby ograniczyć akcję. Działa to nawet wtedy, gdy nie działa jonice, ale usunięcie wszystkich plików zajmie dużo czasu.
źródło
Otrzymałem tutaj wiele przydatnych odpowiedzi / komentarzy, które chciałbym podsumować, a także pokazać moje rozwiązanie.
Tak, najlepszym sposobem, aby temu zapobiec , jest utrzymanie katalogu pamięci podręcznej w osobnym systemie plików. Nukowanie / szybkie formatowanie systemu plików zawsze zajmuje najwyżej kilka sekund (może minut), niezwiązanych z liczbą plików / katalogów w nim obecnych.
Rozwiązania
ionice
/nice
nic nie zrobiły, ponieważ proces usuwania faktycznie spowodował prawie brak operacji we / wy. To, co spowodowało We / Wy, było moim zdaniem zapełnianiem się kolejek / buforów na poziomie jądra / systemu plików, gdy pliki były usuwane zbyt szybko przez proces usuwania.Sposób, w jaki go rozwiązałem, jest podobny do rozwiązania Tero Kilkanena, ale nie wymagał wywoływania skryptu powłoki. Użyłem wbudowanego
--bwlimit
przełącznika rsync, aby ograniczyć szybkość usuwania.Pełne polecenie było:
Teraz bwlimit określa przepustowość w kilobajach, która w tym przypadku dotyczyła nazwy pliku lub ścieżki plików. Ustawiając go na 1 KBps, usuwało około 100 000 plików na godzinę, czyli 27 plików na sekundę. Pliki miały względne ścieżki, takie jak
cache.bak/e/c1/db98339573acc5c76bdac4a601f9ec1e
, które mają 47 znaków, więc dawałoby to 1000/47 ~ = 21 plików na sekundę, więc trochę tak, jak przypuszczam 100 000 plików na godzinę.Teraz dlaczego
--bwlimit=1
? Próbowałem różnych wartości:Podoba mi się prostota wbudowanej metody rsync, ale to rozwiązanie zależy od względnej długości ścieżki. Nie jest to duży problem, ponieważ większość osób znalazłaby odpowiednią wartość metodą prób i błędów.
źródło