Что делать, когда на сервере кончаются файловые дескрипторы (inode)

Нередки случаи, когда причиной проблем на сервере становится переполнение файловых дескрипторов (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 (хотя там файлов не так много, можно и не удалять, если есть более «объёмные» кандидаты).

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