Как да проверя използването на inode в HestiaCP? Какво причинява невъзможността за запис на файлове, дори когато има достатъчно дисково пространство?

Преди няколко дни, един приятел ми писа късно през нощта, че сървърът му се е сринал.

Конкретните симптоми бяха особено странни: уебсайтът внезапно започна да хвърля грешки, не можеха да се записват лог файлове, а създаването на нови файлове веднага показваше, че дискът е пълен.

Но когато провери с `df -h`, беше шокиран да открие, че дискът очевидно има десетки гигабайта свободно пространство. Как е възможно да е пълен?

Казах му веднага: „Братко, не само че си пълен с място за съхранение, но и твоят индексен нос е претоварен.“

Той отговори с въпросителен знак: Какво точно е Inode?

Всъщност много хора реагират по абсолютно същия начин, както той, когато за първи път са попаднали в този капан, защото никой в ​​училище никога не ги е учил на тези неща.

Нека първо изясним какво е Inode.

Мислете за това като за библиотечна карта и ще бъде лесно за разбиране.

Дисковото пространство е като лавица за книги; колко книги можете да поставите на нея зависи от капацитета ѝ, което е лесно за разбиране от всеки.

Индексният дескриптор е като индексна карта за всяка книга, записваща нейното име, местоположение и кой я е преместил.

В Linux всеки файл и всяка директория трябва да заема inode, независимо колко малък е файлът.

Дори и да е празен файл, системата пак ще използва индексна карта за него.

Системата има ограничение за общия брой файлове, които може да създаде; това ограничение е общият брой на вътрешните възли.

След като inode-ът се използва, дори ако на диска ви все още има стотици гигабайта свободно пространство, операционната система ще откаже да създава нови файлове.

Не могат да се записват лог файлове, не може да се създава кеш памет и уебсайтът се срива напълно - това е странната сцена, на която сте свидетели.

Честно казано, това е наистина трудна ситуация, защото съобщението за грешка се изпраща от място, което не гледате.

Първият трик е да използвате `df -i`, за да получите пълен преглед.

В средата на HestiaCP можете просто да влезете в терминала чрез SSH и да въведете този ред.

df -i

Ще се изброят общият брой на вътрешните възли, използваният брой и оставащият брой за всеки монтиран дял.

В резултата има колона, наречена IUse%, която е ключовият показател, който трябва да следите.

Ако IUse% на даден дял достигне 100%, дори ако този дял все още има достатъчно дисково пространство, той вече няма да може да създава нови файлове или лог файлове.

Предложих на приятеля ми първо да изпълни това, за да може да се определи дали проблемът е в Inode-а за секунда , което ще бъде много по-бързо от гадаене.

Вторият метод е да използвате `find`, за да преброите точно конкретен потребител.

След като потвърдите, че проблемът е във вътрешния възел, следващата стъпка е да разберете кой прекомерно използва индексната карта.

HestiaCP има отделна домашна директория за всеки потребител. Можете просто да преброите общия брой файлове и директории в конкретна директория на уебсайта.

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

Заменете „потребителско име“ и „вашето име на домейн“ с действителния път. Чистото число, върнато от терминала, е сумата от всички файлове и папки в тази директория.

Всеки файл или директория съответства на един inode, така че това число представлява използването на inode.

Ако сте твърде мързеливи да проверявате всеки поотделно и искате да видите разпределението на потреблението на всички потребители в целия сайт наведнъж, има и команда с един цикъл.

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

Този ред ще изведе общия брой файлове във всяка потребителска директория под /home, което улеснява откриването коя потребителска директория има необичайно висок брой файлове.

Третата стратегия е да се идентифицират поддиректориите, които консумират най-много йод.

Понякога знаете, че даден уебсайт има абсурдно високи стойности на Inode, но все още не можете да разберете какво не е наред с екрана, пълен с файлове.

В такива случаи е необходимо да се спуснете едно ниво надолу, за да намерите подпапки, които съдържат голям брой малки файлове, като например директории на кеша, директории на сесии и директории на лог файлове – това са най-проблемните области.

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

Тази команда ще изброи първите 10 подпапки, които консумират най-много файлове.

Пътят в самия връх на списъка е мястото, където са групирани голям брой малки файлове.

Казах на приятеля си, че вероятно е някакъв кеширащ плъгин, който тайно генерира малки файлове, и изпълнението на този ред би го потвърдило.

Четвъртият съвет е да проверите ограничението на квотата, използвайки repquota.

Ако вашият сървър има активирани квоти за файлова система на Linux, можете да погледнете на проблема от различна гледна точка.

repquota -a

Тази команда ще извлече информация за ограничението на файловете и действителното използване на файловете за всички потребители.

Обърнете специално внимание на секцията „Ограничения на файловете“ в изхода; колоната „използвани“ показва колко файла са използвани.

Колоните „soft“ и „hard“ представляват праговете за меки и твърди ограничения. След като „used“ достигне „hard“, системата директно ще откаже да създава нови файлове.

Това е съвсем различна история от това колко място ви е останало на диска.

За да завършим, нека свържем точките на разследването.

Да се ​​върнем към приятеля, който срина сървъра посред нощ в началото.

Той следваше четирите стъпки, които описах, започвайки с `df -i`, за да потвърди, че inode-ът наистина е пълен.

След това, използвайки метода find, беше открито, че кеш директория на изоставен стар уебсайт генерира малки файлове като луди.

Накрая, проверката на `repquota` потвърди, че наистина е достигнал твърдия лимит.

След като изчисти купчината боклуци в кеша, уебсайтът веднага се върна към живот.

Така че следващия път, когато се сблъскате с тази странна ситуация, в която „дискът очевидно има място, но не можете да записвате файлове“, не бързайте да добавяте твърд диск.

Първо, използвайте `df -i`, за да разгледате inode-а; истината може би е скрита в онази индексна карта, която никога преди не сте забелязали.

Искрено вярвам, че тези малки частици здрав разум, скрити в ядрото на системата, са по-полезни от запомнянето на стотина списъка за оптимизация.