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

Несколько дней назад поздно вечером друг написал мне, что у него сломался сервер.

Признаки проблемы были особенно странными: веб-сайт внезапно начал выдавать ошибки, запись логов стала невозможной, а создание новых файлов немедленно приводило к сообщению о заполнении диска.

Но когда он проверил с помощью команды `df -h`, он с ужасом обнаружил, что на диске явно было несколько десятков гигабайт свободного места. Как же он мог быть заполнен?

Я тут же ему сказал: «Брат, у тебя не просто много места для хранения данных, твой Inode перегружен».

Он ответил вопросительным знаком: Что же такое инод?

На самом деле, многие реагируют точно так же, как и он, когда впервые попали в эту ловушку, потому что в школе их этому никогда не учили.

Давайте сначала уточним, что такое Inode.

Представьте это как библиотечную карточку, и все станет легко понять.

Дисковое пространство подобно книжной полке; количество книг, которые вы можете на ней разместить, зависит от ее емкости, что легко понять каждому.

Инод — это своего рода карточка для каждой книги, на которой записаны её название, местонахождение и кто её переместил.

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

Даже если это пустой файл, система все равно использует для него карточку с данными.

Система имеет ограничение на общее количество создаваемых файлов; это ограничение определяется общим количеством узлов.

Как только inode будет исчерпан, даже если на вашем диске еще останутся сотни гигабайт свободного места, операционная система откажется создавать новые файлы.

Запись логов невозможна, создание кэша невозможно, и веб-сайт полностью зависает — вот та странная картина, которую вы наблюдаете.

Честно говоря, это очень сложная ситуация, потому что сообщение об ошибке отправляется из места, на которое вы не смотрите.

Первый прием — использовать команду `df -i` для получения полного обзора.

В среде HestiaCP вы можете просто подключиться к терминалу по SSH и ввести эту строку.

df -i

В выводе будет указано общее количество узлов, количество использованных узлов и количество оставшихся узлов для каждого смонтированного раздела.

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

Если процент использования раздела достигнет 100%, даже если в этом разделе еще достаточно свободного места, он больше не сможет создавать новые файлы или журналы.

Я предложил своему другу сначала запустить это, чтобы за секунду определить, связана ли проблема с Inode , что было бы гораздо быстрее, чем гадать.

Второй метод заключается в использовании функции `find` для точного подсчета количества конкретных пользователей.

После подтверждения того, что проблема связана с узлом, следующим шагом является выяснение того, кто чрезмерно использует данные с карточки.

В HestiaCP для каждого пользователя существует отдельная домашняя директория. Вы можете просто подсчитать общее количество файлов и каталогов в конкретной директории веб-сайта.

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

Замените "username" и "your domain name" на ваш фактический путь. Число, возвращаемое терминалом, представляет собой сумму всех файлов и папок в этом каталоге.

Каждому файлу или каталогу соответствует один 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

Эта команда покажет лимит файлов и фактическое использование файлов для всех пользователей.

Обратите особое внимание на раздел «Ограничения на количество файлов» в выходных данных; столбец «Использовано» показывает, сколько файлов было использовано.

Столбцы «мягкий» и «жесткий» обозначают мягкие и жесткие пороговые значения. Как только значение в столбце «используется» достигнет значения в столбце «жесткий», система немедленно откажется создавать новые файлы.

Это совершенно другая история, нежели вопрос о том, сколько места у вас осталось на диске.

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

Вернемся к тому другу, который в начале игры посреди ночи обрушил сервер.

Он выполнил четыре описанных мной шага, начиная с команды `df -i`, чтобы убедиться, что inode действительно заполнен.

Затем, используя метод find, было обнаружено, что в кэш-каталоге заброшенного старого веб-сайта генерировалось огромное количество мелких файлов.

Наконец, проверка параметра `repquota` подтвердила, что он действительно достиг установленного лимита.

После очистки этой кучи ненужного кэша сайт мгновенно ожил.

Поэтому в следующий раз, когда вы столкнетесь со странной ситуацией, когда «на диске явно есть место, но вы не можете записывать файлы», не спешите добавлять жесткий диск.

Для начала воспользуйтесь командой `df -i`, чтобы посмотреть на inode; истина вполне может быть скрыта на той карточке, которую вы раньше никогда не замечали.

Я искренне верю, что эти крупицы здравого смысла, скрытые в ядре системы, полезнее, чем заучивание сотни списков оптимизации.