Skutecznie usuwaj pliki 10M + z ZFS

30

Napisałem błędny program, który przypadkowo utworzył około 30 milionów plików w / tmp. (Błąd został wprowadzony kilka tygodni temu i tworzył kilka podkatalogów na sekundę). Mogłem zmienić nazwę / tmp na / tmp2, a teraz muszę usunąć pliki. System to FreeBSD 10, główny system plików to ZFS.

W międzyczasie jeden z dysków w lustrze zepsuł się i wymieniłem go. Napęd ma dwa dyski SSD 120 GB.

Oto pytanie: wymiana dysku twardego i ponowne uruchomienie całego układu zajęło mniej niż godzinę. Usuwanie plików / tmp2 to inna historia. Napisałem inny program do usuwania plików, który może usunąć tylko 30-70 podkatalogów na sekundę. Usunięcie wszystkich plików zajmie 2-4 dni.

Jak to możliwe, że resilverowanie całej macierzy zajmuje godzinę, a usunięcie z dysku zajmuje 4 dni? Dlaczego mam tak słabą wydajność? 70 usunięć na sekundę wydaje się bardzo bardzo słabą wydajnością.

Mógłbym ręcznie usunąć i-węzeł dla / tmp2, ale to nie zwolni miejsca, prawda?

Czy może to być problem z ZFS, dyskami twardymi?

nagylzs
źródło
1
Nie jestem ekspertem od ZFS, więc nie mogę mówić o dostrajaniu wydajności ani o tym, co możesz zrobić, aby to poprawić (wymagałoby to również wielu informacji i prawdopodobnie najlepiej byłoby to zrobić bezpośrednio przez eksperta). Mogę jednak powiedzieć, że resilvering odbywa się na poziomie bloku, podczas gdy twoje usunięcia mają miejsce na poziomie systemu plików. System plików będzie miał głównie narzut podczas usuwania takich buforów i-węzłów.
Spooler
Proszę zamieścić swoje df -hi zpool listi zfs list.
ewwhite
5
Napisał inny program: rm -rf /tmp2nie wykona pracy?
Thorbjørn Ravn Andersen
2
Czy nie możesz po prostu zrestartować się? /tmppowinien być systemem tmpfsplików i jest przechowywany w pamięci.
Blender

Odpowiedzi:

31

Usunięcia w ZFS są drogie. Tym bardziej, jeśli masz włączoną deduplikację w systemie plików (ponieważ usuwanie deduplikacji plików jest kosztowne). Migawki również mogą skomplikować sprawy.

Lepiej jest usunąć /tmpkatalog zamiast zawartych w nim danych.

Jeśli /tmpjest to system plików ZFS, usuń go i utwórz ponownie.

ewwhite
źródło
1
@nagylzs W takim przypadku sugerowałbym utworzenie oddzielnego systemu plików ZFS. Następnie możesz przenieść bieżący / tmp z drogi, przenieść nowy / tmp na miejsce i usunąć pliki w wolnym czasie systemu. Rezultat: minimalne przestoje plus niewielkie pogorszenie wydajności (możliwe do złagodzenia ionice, zakładając, że FreeBSD je ma) podczas usuwania.
CVn
9
Myliłem się. To był osobny system plików. Oto, co zadziałało: reboot do trybu pojedynczego użytkownika, a następnie wykonaj "ZFS usuwać zroot / tmp; ZFS tworzyć zroot / tmp; chmod 41777 / tmp"
nagylzs
6
Całkowity czas przestoju wynosił 5 minut. Fantastyczny! :-)
nagylzs,
1
Cóż, to również świadczy o mojej trosce, że usuwanie podstępów nigdy nie zwalnia miejsca z powodu migawek. Ale tmp zostanie skonfigurowane tak, aby nie tworzyć automatycznych okresowych migawek, prawda ?
JDługosz
1
Właściwie było to: zfs create -o kompresja = on -o exec = on -o setuid = off zroot / tmp; chmod 1777 / zroot / tmp; zfs set mountpoint = / tmp zroot / tmp; Nie jestem jednak pewien, jak wyłączyć automatyczne migawki. Istnieje „zfs set com.sun: auto-snapshot = false”, ale myślę, że działa tylko na solaris.
nagylzs
27

Jak to możliwe, że resilverowanie całej macierzy zajmuje godzinę, a usunięcie z dysku zajmuje 4 dni?

Rozważ budynek biurowy.

Usunięcie wszystkich komputerów, mebli i elementów mocujących ze wszystkich biur na wszystkich piętrach zajmuje dużo czasu, ale pozostawia biura natychmiast nadające się do użytku przez innego klienta.

Wyburzenia całego budynku z RDX jest dużo szybsza, ale następny klient jest całkiem prawdopodobne, aby narzekać jak przewiewny jest to miejsce.

Phill W.
źródło
5
ZFS nie jest budynkiem biurowym :)
developerbmw
9
@developerbmw nie ma tam też pliku ani folderu, ale potrzebujemy metaforycznych pojęć, aby zrozumieć, co się dzieje.
JamesRyan
2
@JamesRyan tak, to właściwie fajna analogia ... Byłem po prostu głupi
developerbmw
5

Tutaj dzieje się wiele rzeczy.

Po pierwsze, wszystkie nowoczesne technologie dyskowe są zoptymalizowane pod kątem przesyłania zbiorczego. Jeśli musisz przenieść 100 MB danych, zrobią to znacznie szybciej, jeśli będą w jednym ciągłym bloku, a nie rozproszeni po całym miejscu. Dyski SSD bardzo tu pomagają, ale nawet wolą dane w sąsiadujących blokach.

Po drugie, resilvering jest dość optymalny, jeśli chodzi o operacje dyskowe. Odczytujesz ogromny ciągły fragment danych z jednego dysku, robisz na nim szybkie operacje procesora, a następnie przepisujesz go w innym dużym ciągłym kawałku na inny dysk. Jeśli dojdzie do awarii zasilania, nic wielkiego - po prostu zignorujesz dane ze złymi sumami kontrolnymi i będziesz postępował jak zwykle.

Po trzecie, usuwanie pliku jest bardzo wolne . ZFS jest szczególnie zły, ale praktycznie wszystkie systemy plików są wolno usuwane. Muszą modyfikować dużą liczbę różnych fragmentów danych na dysku i odpowiednio je mierzyć (tj. Czekać), aby system plików nie został uszkodzony w przypadku awarii zasilania.

Jak to możliwe, że resilverowanie całej macierzy zajmuje godzinę, a usunięcie z dysku zajmuje 4 dni?

Resilvering to coś, w czym dyski są naprawdę szybkie, a usuwanie to coś, w czym dyski są wolne. Na megabajt dysku wystarczy odrobina resilveringu. W tym miejscu może znajdować się tysiąc plików, które należy usunąć.

70 usunięć na sekundę wydaje się bardzo bardzo słabą wydajnością

To zależy. Nie byłbym tym zaskoczony. Nie wspominałeś, jakiego typu dysku SSD używasz. Nowoczesne dyski SSD Intel i Samsung są całkiem dobre w tego rodzaju operacjach (odczyt-modyfikacja-zapis) i będą działać lepiej. Tańsze / starsze dyski SSD (np. Corsair) będą wolne. Decydującym czynnikiem jest liczba operacji we / wy na sekundę (IOPS).

ZFS jest szczególnie powolny, aby usunąć rzeczy. Zwykle wykonuje usuwanie w tle, więc nie widzisz opóźnienia. Jeśli robisz ich ogromną liczbę, nie może tego ukryć i musi cię opóźnić.


Dodatek: dlaczego usuwanie jest powolne?

  • Usunięcie pliku wymaga kilku kroków. Metadane pliku muszą zostać oznaczone jako „usunięte”, a ostatecznie muszą zostać odzyskane, aby można było ponownie wykorzystać miejsce. ZFS to „system plików o strukturze dziennika”, który działa najlepiej, jeśli tylko tworzysz rzeczy, nigdy ich nie usuwasz. Struktura dziennika oznacza, że ​​jeśli coś usuniesz, w dzienniku będzie luka, więc inne dane muszą zostać ponownie uporządkowane (zdefragmentowane), aby wypełnić lukę. Jest to niewidoczne dla użytkownika, ale ogólnie powolne.
  • Zmiany należy wprowadzić w taki sposób, aby w razie awarii zasilania system plików pozostawał spójny. Często oznacza to czekanie, aż dysk potwierdzi, że dane naprawdę znajdują się na nośniku; dla dysku SSD może to zająć dużo czasu (setki milisekund). Efektem netto jest to, że jest o wiele więcej księgowości (tj. Operacje dyskowe I / O).
  • Wszystkie zmiany są niewielkie. Zamiast czytać, pisać i kasować całe bloki flash (lub cylindry na dysk magnetyczny), musisz zmodyfikować trochę jednego z nich. Aby to zrobić, sprzęt musi odczytać cały blok lub cylinder, zmodyfikować go w pamięci, a następnie ponownie zapisać na nośniku. To zajmuje dużo czasu.
Ian Howson
źródło
Nie wiem o ZFS, ale niektóre systemy plików pozwalają na rozłączenie katalogu z zawartością, ale te treści właśnie usuwa się później podczas fazy odśmiecania / defragmentacji / czyszczenia. Czy ZFS ma jakieś narzędzia do wykonania tak leniwego usuwania? W rzeczywistości nie przyspieszy to usuwania PO, ale prawdopodobnie sprawi, że będzie mniej problematyczne, jeśli zdarzy się to pośrednio podczas sprzątania.
Vality
2

Jak to możliwe, że resilverowanie całej macierzy zajmuje godzinę, a usunięcie z dysku zajmuje 4 dni?

Jest to możliwe, ponieważ dwie operacje działają na różnych warstwach stosu systemu plików. Resilvering może działać na niskim poziomie i tak naprawdę nie musi patrzeć na pojedyncze pliki, kopiując jednocześnie duże porcje danych.

Dlaczego mam tak słabą wydajność? 70 usunięć na sekundę wydaje się bardzo bardzo słabą wydajnością.

To musi robić dużo księgowości ...

Mógłbym ręcznie usunąć i-węzeł dla / tmp2, ale to nie zwolni miejsca, prawda?

Nie wiem dla ZFS, ale gdyby mógł się automatycznie z tego zregenerować, prawdopodobnie wykonałby te same operacje, które już robisz, w tle.

Czy może to być problem z ZFS, dyskami twardymi?

Czy zfs scrubcoś mówi

AnoE
źródło
2

Usuwanie dużej liczby plików nigdy nie jest naprawdę szybką operacją.

Aby usunąć plik w dowolnym systemie plików, musisz odczytać indeks pliku, usunąć (lub oznaczyć jako usunięty) wpis pliku w indeksie, usunąć wszelkie inne metadane powiązane z plikiem i oznaczyć miejsce przydzielone dla pliku jako nie używany. Należy to zrobić indywidualnie dla każdego pliku do usunięcia, co oznacza, że ​​usunięcie wielu plików wymaga dużej liczby małych operacji we / wy. Robienie tego w sposób zapewniający integralność danych w przypadku awarii zasilania powoduje jeszcze większe obciążenie.

Nawet bez osobliwości, którą wprowadza ZFS, usunięcie 30 milionów plików zwykle oznacza ponad sto milionów oddzielnych operacji we / wy. To będzie trwać długo, nawet przy szybkim SSD. Jak wspomnieli inni, konstrukcja ZFS dodatkowo pogłębia ten problem.

bwDraco
źródło
2

Ian Howson daje dobrą odpowiedź na pytanie, dlaczego jest wolny.

Jeśli usuniesz pliki równolegle, możesz zauważyć wzrost prędkości z powodu usunięcia, możesz użyć tych samych bloków, a tym samym zaoszczędzić przepisywania tego samego bloku wiele razy.

Więc spróbuj:

find /tmp -print0 | parallel -j100 -0 -n100 rm

i sprawdź, czy to działa lepiej niż twoje 70 operacji usuwania na sekundę.

Ole Tange
źródło
0

Bardzo proste, jeśli odwrócisz swoje myślenie.

  1. Zdobądź drugi dysk (wydaje się, że już to masz)

  2. Skopiuj wszystko z dysku A na dysk B za pomocą rsync, z wyjątkiem katalogu / tmp. Rsync będzie wolniejszy niż kopia blokowa.

  3. Uruchom ponownie, używając dysku B jako nowego woluminu rozruchowego

  4. Sformatuj dysk A.

Spowoduje to również defragmentację dysku i nowy katalog (dobrze, defragmentacja nie jest tak ważna z dyskiem SSD, ale linearyzacja plików nigdy niczego nie zaszkodzi)

Piotr
źródło
Przede wszystkim skopiuj wszystko oprócz / tmp? Więc włączając / dev i / proc? Po drugie, wydaje mi się trochę niechlujny, szczególnie na serwerze produkcyjnym.
Hennes,
Zakładam, że jest wystarczająco inteligentny, aby wykluczyć nie-pliki, zamontowane woluminy i folder pamięci wirtualnej, których większości nie można zgadnąć tutaj. Lub zrób to z rozruchu konserwacyjnego, gdzie żadna z tych rzeczy nie ma znaczenia.
Piotr
Myślę, że można również zfs send/recv(skopiować na poziomie bloku) wszystkie inne systemy plików oprócz głównego systemu plików (gdzie w tym przypadku znajduje się / tmp) i ręcznie skopiować pozostałe dane do głównego systemu plików (oczywiście z wyjątkiem / tmp).
user121391,
2
Spowoduje to utratę migawek i ominięcie niektórych funkcji niezawodności. Nie ma sensu używania ZFS.
JDługosz
2
@ JDługosz ważne punkty, ale istotne tylko, jeśli dba o to użytkownik. Coś w rodzaju „moje kopie zapasowe są uszkodzone, jak je naprawić?” -> „Czy potrzebujesz plików kopii zapasowej?” -> „Nie” -> „Reformat”.
Piotr
-1

Masz 30 milionów wpisów na nieposortowanej liście. Skanujesz listę w poszukiwaniu wpisu, który chcesz usunąć, i usuwasz go. Teraz masz tylko 29 999 999 wpisów na liście nieposortowanej. Jeśli wszystkie są w / tmp, dlaczego po prostu nie uruchomić ponownie?


Edytowane w celu odzwierciedlenia informacji w komentarzach: Opis problemu: Usunięcie większości, ale nie wszystkich , 30M + nieprawidłowo utworzonych plików w / tmp zajmuje dużo czasu.
Problem 1) Najlepszy sposób na usunięcie dużej liczby niechcianych plików z / tmp.
Problem 2) Zrozumienie, dlaczego tak wolno jest usuwać pliki.

Rozwiązanie 1) - / tmp jest resetowany do pustego podczas rozruchu przez większość dystrybucji * nix. FreeBSD nie jest jednak jednym z nich.
Krok 1 - skopiuj ciekawe pliki gdzie indziej.
Krok 2 - Jako root

 $ grep -i tmp /etc/rc.conf  
 clear_tmp_enable="YES" # Clear /tmp at startup.  

Krok 3 - uruchom ponownie.
Krok 4 - zmień opcję clear_tmp_enable z powrotem na „Nie”.
Niechciane pliki zniknęły, ponieważ ZFS na FreeBSD ma funkcję, że „Zniszczenie zbioru danych jest znacznie szybsze niż usunięcie wszystkich plików znajdujących się w zbiorze danych, ponieważ nie wymaga skanowania wszystkich plików i aktualizacji wszystkich odpowiednich metadanych. „ więc podczas uruchamiania wystarczy zresetować metadane dla zestawu danych / tmp. To jest bardzo szybkie.

Rozwiązanie 2) Dlaczego jest tak wolne? ZFS to wspaniały system plików, który zawiera takie funkcje, jak stały dostęp do katalogu w czasie. Działa to dobrze, jeśli wiesz, co robisz, ale dowody wskazują, że OP nie jest ekspertem ZFS. OP nie wskazał, w jaki sposób próbowali usunąć pliki, ale zgaduję, powiedziałbym, że zastosowali odmianę „find regex -exec rm {} \;”. Działa to dobrze z małymi liczbami, ale nie jest skalowane, ponieważ trwają trzy operacje szeregowe 1) pobierz listę dostępnych plików (zwraca 30 milionów plików w kolejności mieszania), 2) użyj wyrażenia regularnego, aby wybrać następny plik do usunięcia, 3 ) powiedz systemowi operacyjnemu, aby znalazł i usunął ten plik z listy 30 milionów. Nawet jeśli ZFS zwraca listę z pamięci i jeśli „find” buforuje go, regex nadal musi zidentyfikować następny plik do przetworzenia z listy, a następnie powiedzieć systemowi operacyjnemu, aby zaktualizował swoje metadane, aby odzwierciedlić tę zmianę, a następnie zaktualizować listę, aby nie była ponownie przetwarzana.

Paul Smith
źródło
1
Myślę, że źle zrozumiałeś pytanie. Musiałem usunąć większość plików. To znaczy, ponad 30 milionów plików.
nagylzs
@nagylzs / tmp jest czyszczony przy ponownym uruchomieniu. Jeśli chcesz usunąć większość , to chcesz zachować tylko część , tj. Mniej niż połowę, więc skopiuj te, które chcesz zachować, a następnie uruchom ponownie, aby pozbyć się reszty. Powodem, dla którego usuwanie jest tak powolne, jest to, że duża liczba plików w katalogu powoduje powstanie dużej nieposortowanej listy, która musi zostać przetworzona, aby znaleźć plik, który ma być obsługiwany, co zajmuje dużo czasu. Jedynym problemem tutaj jest PEBCAK.
Paul Smith
Katalogi Zfs są nieposortowane ? Myślałem, że ZFS dobrze poradził sobie z dużymi katalogami.
JDługosz
Cóż, / tmp nie jest czyszczony, tylko pliki związane z X. Przynajmniej na FreeBSD. I tak nie można go wyczyścić podczas rozruchu, ponieważ normalne usunięcie skryptu rc zajęłoby kilka dni.
nagylzs,
@JDlugosz - ZFS jest znacznie lepszy niż większość, ale listy i-węzłów (czyli wszystkie katalogi) są nieposortowane.
Paul Smith