Jak sprawdzić użycie inodów w HestiaCP? Co jest przyczyną braku możliwości zapisu plików, nawet gdy na dysku jest dużo miejsca?

Kilka dni temu, późnym wieczorem, napisał do mnie znajomy, że jego serwer się zepsuł.

Objawy były szczególnie dziwne: strona internetowa nagle zaczęła zgłaszać błędy, nie można było zapisywać logów, a tworzenie nowych plików natychmiast powodowało zapełnienie dysku.

Ale kiedy sprawdził poleceniem `df -h`, ze zdumieniem odkrył, że dysk ma ewidentnie dziesiątki gigabajtów wolnego miejsca. Jak to możliwe, że jest pełny?

Powiedziałem mu od razu: „Bracie, nie tylko masz za dużo miejsca na dane, twój inod jest przeciążony”.

Odpowiedział znakiem zapytania: Czym właściwie jest inod?

W rzeczywistości wiele osób zareagowało dokładnie w ten sam sposób, gdy po raz pierwszy wpadły w tę pułapkę, ponieważ nikt w szkole nie uczył ich takich rzeczy.

Najpierw wyjaśnijmy, czym jest inod.

Można to porównać do karty bibliotecznej, a będzie to łatwe do zrozumienia.

Przestrzeń dyskowa jest jak półka na książki: liczba książek, które można na niej umieścić, zależy od jej pojemności, co jest oczywiste dla każdego.

Inod to swego rodzaju karta indeksowa dla każdej książki, w której odnotowywane są jej nazwa, lokalizacja i osoba, która ją przeniosła.

W systemie Linux każdy plik i katalog musi zajmować inod, bez względu na wielkość pliku.

Nawet jeśli plik jest pusty, system i tak utworzy dla niego kartę indeksową.

W systemie istnieje limit całkowitej liczby plików, które można utworzyć; limit ten jest równy całkowitej liczbie węzłów.

Gdy inod zostanie wykorzystany, nawet jeśli na dysku pozostaną setki gigabajtów wolnego miejsca, system operacyjny odmówi utworzenia nowych plików.

Nie można zapisywać dzienników, nie można utworzyć pamięci podręcznej, a strona internetowa całkowicie się zawiesza — oto dziwna scena, której jesteś świadkiem.

Szczerze mówiąc, jest to naprawdę trudna sytuacja, ponieważ komunikat o błędzie jest wysyłany z lokalizacji, której nie widzisz.

Pierwszy sposób polega na użyciu `df -i` w celu uzyskania szybkiego przeglądu.

W środowisku HestiaCP wystarczy nawiązać połączenie SSH z terminalem i wpisać poniższy wiersz.

df -i

Wyświetli całkowitą liczbę in-węzłów, liczbę wykorzystanych i liczbę pozostałych węzłów dla każdej zamontowanej partycji.

Na wyjściu znajduje się kolumna o nazwie IUse%, która jest kluczowym wskaźnikiem, na który należy zwracać uwagę.

Jeśli wskaźnik IUse% partycji osiągnie 100%, nawet jeśli na partycji jest jeszcze dużo miejsca, nie będzie można tworzyć nowych plików ani dzienników.

Zasugerowałem mojemu przyjacielowi, żeby najpierw uruchomił to narzędzie, dzięki czemu w ciągu sekundy będzie można stwierdzić, czy problem leży w inodzie , co byłoby znacznie szybsze niż zgadywanie.

Drugą metodą jest użycie polecenia `find` w celu precyzyjnego policzenia konkretnego użytkownika.

Po potwierdzeniu, że problem dotyczy węzła, następnym krokiem jest ustalenie, kto nadmiernie korzysta z karty indeksu.

HestiaCP ma oddzielny katalog domowy dla każdego użytkownika. Możesz po prostu policzyć łączną liczbę plików i katalogów w konkretnym katalogu witryny.

find /home/用户名/web/你的域名/public_html | wc -l

Zastąp „nazwę użytkownika” i „nazwę domeny” swoją rzeczywistą ścieżką. Liczba zwrócona przez terminal to suma wszystkich plików i folderów w danym katalogu.

Każdy plik lub katalog odpowiada jednemu inodowi, więc liczba ta przedstawia wykorzystanie inodów.

Jeśli nie chce Ci się sprawdzać każdego z nich osobno i chcesz od razu zobaczyć rozkład wykorzystania dla wszystkich użytkowników na całej stronie, możesz skorzystać z polecenia loop.

for d in /home/*; do echo -n "$d: "; find "$d" 2>/dev/null | wc -l; done

Ten wiersz wyświetli całkowitą liczbę plików w każdym katalogu użytkownika w /home, dzięki czemu łatwo można zorientować się, w którym katalogu użytkownika znajduje się nietypowo duża liczba plików.

Trzecia strategia polega na zidentyfikowaniu podkatalogów zużywających najwięcej jodu.

Czasami wiesz, że strona internetowa ma absurdalnie wysokie wartości inodów, ale nadal nie możesz zrozumieć, co jest nie tak z ekranem pełnym plików.

W takich przypadkach należy przejść o jeden poziom niżej, aby znaleźć podfoldery zawierające dużą liczbę małych plików, takich jak katalogi pamięci podręcznej, katalogi sesji i katalogi dziennika — są to obszary najbardziej problematyczne.

find /home/用户名/web/你的域名/public_html -type d -exec sh -c 'echo -n "{}: "; find "{}" -maxdepth 1 | wc -l' \; | sort -n -r -k 2 | head -n 10

To polecenie wyświetli listę 10 podfolderów zawierających najwięcej plików.

Ścieżka na samej górze listy to miejsce, w którym gromadzona jest duża liczba małych plików.

Powiedziałem znajomemu, że to prawdopodobnie jakaś wtyczka buforująca, która potajemnie generuje małe pliki, a uruchomienie tej linijki zasadniczo to potwierdzi.

Czwarta wskazówka: sprawdź limit kwoty za pomocą repquota.

Jeśli na Twoim serwerze włączono limity plików systemu Linux, możesz spojrzeć na problem z innej perspektywy.

repquota -a

To polecenie wyświetli limit plików i faktyczne wykorzystanie plików dla wszystkich użytkowników.

Zwróć szczególną uwagę na sekcję Limity plików w wynikach; kolumna Użyte wskazuje, ile plików zostało użytych.

Kolumny „miękkie” i „twarde” reprezentują miękkie i twarde progi limitów. Gdy „używane” osiągnie poziom „twarde”, system od razu odmówi tworzenia nowych plików.

To zupełnie inna historia niż ilość wolnego miejsca na dysku.

Podsumowując, połączmy fakty z naszego śledztwa.

Wróćmy do znajomego, który na początku w środku nocy spowodował awarię serwera.

Wykonał cztery opisane przeze mnie kroki, zaczynając od `df -i`, aby potwierdzić, że inod jest rzeczywiście pełny.

Następnie za pomocą polecenia find zlokalizowaliśmy katalog pamięci podręcznej starej, opuszczonej strony internetowej, która generowała mnóstwo małych plików.

Na koniec sprawdzenie `repquota` potwierdziło, że faktycznie osiągnięto sztywny limit.

Po usunięciu sterty śmieci z pamięci podręcznej strona internetowa natychmiast ożyła.

Więc następnym razem, gdy spotkasz się z dziwną sytuacją, w której „dysk wyraźnie ma miejsce, ale nie można zapisać plików”, nie spiesz się z dodawaniem dysku twardego.

Najpierw użyj `df -i`, aby sprawdzić inod; prawda może kryć się na tej karcie indeksowej, której wcześniej nie zauważyłeś.

Szczerze wierzę, że te małe elementy zdrowego rozsądku ukryte w rdzeniu systemu są bardziej przydatne niż zapamiętywanie setek list optymalizacyjnych.