Нередки случаи, когда причиной проблем на сервере становится переполнение файловых дескрипторов (inode). Симптомы точно такие же, как при переполнившемся диске, только вот диск при этом может оказаться свободным.
Количество inode каждой файловой системы определяется при разворачивании ОС. И для большинства серверов этого хватает с головой. Чаще всего во время установки ОС создаётся 1 inode на каждые 2 Кбайт пространства по умолчанию. Это много, но для некоторых — все равно недостаточно.
Если у вас закончились inode, вы не сможете создать новый файл. Ваша система или любая её служба также не сможет это сделать.
Первый шаг, который требуется в этом случае, проверить наличие свободных inode командой:
df -i
Отметим, что эта команда обычно применяется в паре с df -h, которую используют для проверки места на диске. Иначе говоря, проверяя место на диске, не забудьте проверить и файловые дескрипторы.
Вывод команды будет примерно таким:
Filesystem Inodes IUsed IFree IUse% Mounted on udev 382747 312 382435 1% /dev tmpfs 385546 773 384773 1% /run /dev/vda5 3932160 3932001 159 100% / tmpfs 385546 2 385544 1% /dev/shm tmpfs 385546 5 385541 1% /run/lock tmpfs 385546 15 385531 1% /sys/fs/cgroup /dev/vda1 24096 341 23755 2% /boot tmpfs 385546 11 385535 1% /run/user/0
Как и в случае с дисковым пространством, нас интересует строчка с dev-устройством, в которое файловая система помещает наши файлы. В примере это /dev/vda5 и процент использования inode 100%. Хотя мы видим, что 159 дескрипторов еще свободно, для корректной работы системы этого может быть мало уже сейчас или хватит совсем ненадолго.
Как возникла эта проблема? В какой-то директории создано большое количество файлов, т.е. условно говоря, у системы есть ограничение на создаваемые файлы, и это ограничение было превышено. Задача — найти эту директорию или директории. Нам поможет следующая команда:
find / -type d -size +4096 -exec sh -c " ls -d {} && ls {} | wc -l" \;
Вывод будет примерно таким:
/var/www/user1/data/mod-tmp 481034 /var/spool/exim/input 99792 /var/www/user2/data/www/site2.ru/bitrix/cache 5485
Здесь указывается директория и ниже — количество файлов в ней.
Наиболее распространенный случай, когда множество файлов создается в папке хранения сессий. В нашем примере это директория /var/www/user1/data/mod-tmp.Очистить ее можно командой:
find /var/www/user1/data/mod-tmp -type f -delete
Учтите, что процесс может быть долгим, так как удаление большого количества мелких файлов требует времени.
Для удаления этих файлов у PHP есть встроенный механизм сборщика мусора, который так и называется — garbage collector. И для сессий он отрабатывает по довольно простой схеме, работа которой задается переменными в настройках PHP.
Для всех файлов сессий, которые были созданы больше, чем «
session.gc_maxlifetime» секунд назад (обычно это — 1440 секунд, 24 минуты) есть вероятность, что файл будет удален. Вероятность равна «session.gc_probability», разделенная на «session.gc_divisor».Делитель обычно задается стандартный, равный 1000, а вот параметр
session.gc_probability— и есть ключевая переменная в вероятности срабатывания. И у вас она может быть выставлена в0, что будет означать, что PHP никогда не очищает старые сессии. Из-за чего у вас и может накопиться их несколько миллионов. Выставите параметр в1, сессии будут очищаться.
Далее видим, что и в почтовой очереди скопилось много файлов. Если проблему с переполнившимися айнодами уже решили, то лучше не очищать почтовую очередь и проанализировать ее с помощью нашей статьи. Если вопрос срочный, очищаем ее также как сессии PHP:
find /var/spool/exim/input -type f -delete
По тому же принципу поступаем и с кэшем /var/www/user2/data/www/site2.ru/bitrix/cache (хотя там файлов не так много, можно и не удалять, если есть более «объёмные» кандидаты).
Мы рассмотрели наиболее встречаемые случаи и пути их решения. В отличие от дискового пространства, с айнодами частных случаев гораздо больше, но в одной статье обо всех рассказать невозможно. Если ваш случай не попал в статью, вы всегда можете обратиться в поддержку за помощью.
