Помощь

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

Чаще всего проблема встречается, когда диск уже переполнен.

Поэтому, вероятнее всего, в этом случае на VPS могут отключаться важные службы, возникать проблемы с загрузкой файлов и авторизацией через панель управления, тогда необходимо будет заходить на сервер по SSH или по VNC.

Просмотр занятого пространства
Очистка диска
Частые случаи быстрого накопления данных
Просмотр количества свободных айнод в системе
Освобождение файловых дескрипторов
Частые случаи заполнения файловых дескрипторов (айнод)
 

Просмотр занятого пространства

В первую очередь, авторизовавшись на VPS, убедитесь, что диск переполнен, с помощью команды: 

df -h

Сразу обратим внимание, что помимо этой команды логично еще запустить команду df -i,  для проверки переполнения файловых дескрипторов (inode). Сначала рассмотрим случай, если переполнен конкретно диск (по команде df -h). О df -i расскажем позже.

Пример результата команды, когда диск переполнен:

Filesystem      Size  Used  Avail Use% Mounted on
devtmpfs        909M     0  909M   0%  /dev
tmpfs           919M     0  919M   0%  /dev/shm
tmpfs           919M  8.5M  911M   1%  /run
tmpfs           919M     0  919M   0%  /sys/fs/cgroup
/dev/vda4        59G   59G  228M 100%  /
/dev/vda2      1020M  434M  587M  43%  /boot
tmpfs           184M     0  184M   0%  /run/user/0
 

В этом примере и в аналогичной ситуации у вас важна строка /dev/vda4, это устройство, которое хранит в системе файлы вашего сервера. Название может быть другим, просмотрите все устройства, начинающиеся на /dev/ и столбец объёма (Size) в них, размер должен быть близок объёму вашего диска, согласно тарифу. Найдя нужную строку с файловой системой, обратите внимание на столбец Use% – если там 100, значит диск переполнен. Стоит внимательно отнестись и в случаях, когда процент использования близок к 100, например 98%.
 

Очистка диска

Дальнейшие действия по очистке.

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

Если же ситуация иная, т.е. вы не знаете, что и где заняло такой объем диска, то можно выполнить поиск наиболее «толстых» директорий. Пример команды, которая поможет осуществить задуманное:

du -ah /  --max-depth=12 --exclude=/proc | grep G | grep -v [0-9]M | grep -v [0-9]K | grep -vw 0
 

Команда выведет все основные и вложенные папки до заданной глубины (параметр –-max-depth), в объеме которых будет встречаться буква G (гигабайт).

Будет выведен примерно такой список:

1.8G    /usr
5.3G    /root/backups
5.4G    /root
1.0G    /var/lib
1.0G    /var/www/httpd-logs
1.8G    /var/www/user1/data/www/site1.ispvds.com
2.0G    /var/www/user1/data/www/site1.ispvds.com_bak
4.9G    /var/www/user1/data/www
4.9G    /var/www/user1/data
4.9G    /var/www/user1
1.2G    /var/www/user2/data/www/site2.ru/upload/iblock
1.2G    /var/www/user2/data/www/site2.ru/upload/resize_cache/iblock
1.2G    /var/www/user2/data/www/site2.ru/upload/resize_cache
2.9G    /var/www/user2/data/www/site2.ru/upload
1.6G    /var/www/user2/data/www/site2.ru/bitrix/cache/s1/bitrix
1.7G    /var/www/user2/data/www/site2.ru/bitrix/cache/s1
1.8G    /var/www/user2/data/www/site2.ru/bitrix/cache
2.3G    /var/www/user2/data/www/site2.ru/bitrix
5.2G    /var/www/user2/data/www/site2.ru
5.2G    /var/www/user2/data/www
5.2G    /var/www/user2/data
5.2G    /var/www/user2
11G     /var/www
12G     /var
39G    /home/bitrix/www/bitrix/testfile
39G    /home/bitrix/www/bitrix
39G    /home/bitrix/www
39G    /home/bitrix
39G    /home
20G     /
 

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

В Centos/AlmaLinux установить можно командой:

yum install ncdu

В Debian/Ubuntu можно установить командой:

apt install ncdu

После чего просто запустить выполнение анализа командой:

ncdu /

Какое-то время займет подсчет файлов, затем будет отображен управляемый список директорий:

Можно клавишами навигации выбрать самую объемную, нажать Enter и провалиться в поддиректорию глубже и глубже (если требуется), чтобы в конце концов увидеть источник такого большого объема директории:

Также можно поискать не директории, а просто большие файлы, командой:

find / -xdev -type f -size +500M -exec du -sh {} ';' | sort -rh

/ — в данном случае означает, что мы ищем от корня файловой системы;
-type f — означает, что мы ищем только файлы;
+500M — означает размер файла (500 Мб) как стартовый для поиска. Все файлы со значением выше указанного попадут в выводимый список.

В целом, в данной методике возможен только ручной анализ получившихся выводов команд. Вам следует решить, логичен ли такой большой объём и можно ли его очистить. В примере выше (речь о команде du -ah /  --max-depth=12) есть несколько вариантов, от которых можно «избавиться» для освобождения пространства сервера.
 

Частые случаи быстрого накопления данных

Можно посчитать довольно сомнительной папку с бэкапами /root/backups, как правило в эту директорию складывают временные копии, которые делаются на время работ с сервером и не расцениваются как централизованные бэкапы. Но этот момент следует дополнительно проверить, так как у каждого могут быть свои настройки. Главное, если вы знаете, что в другом месте (лучше всего — на внешнем хранилище) у вас есть актуальные резервные копии, тогда очевидно, что текущие бэкапы — дублирующие или неактуальны, поэтому их можно удалить.

Также рассмотреть на удаление можно и копию директории сайта /var/www/user1/data/www/site1.ispvds.com_bak. Вероятно, на сайт загружались какие-то изменения, и эта копия была для случая «вернуть все назад». Если сайт в порядке и работает из основной директории, то смысл в этой копии наверняка отсутствует, поэтому можно удалить и ее.

Также часто встречается, что приличный объем может занимать кэш сайта, в примере — сайт на Битриксе. Его директория /var/www/user2/data/www/site2.ru/bitrix/cache весит хоть и немного, но все же занимает определенное пространство, в случае когда по месту все «впритык», то кэш можно очистить командой:

find /var/www/user2/data/www/site2.ru/bitrix/cache/* -delete

Обратите внимание, символ “*” тут обязателен. Эту же команду можно применять (указав вместо папки кэша нужную директорию) и для удаления копий, о которых говорили выше.

Другая популярная причина — объемные логи. Когда службы сервера безостановочно пишут в лог, это может привести к резкому уменьшению свободного места на диске, порой даже быстрее, чем происходит системная ротация логов. В нашем случае некоторое место занимает директория с логами веб-сервера /var/www/httpd-logs

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

Чтобы выявить, какой лог какой объем занимает, воспользуемся командой:

du -sh /var/www/httpd-logs/*

Здесь также не забудьте про знак “*”.

Результат в нашем примере оказался такой:

2.0M    /var/www/httpd-logs/site1.ispvds.com.access.log
128K    /var/www/httpd-logs/site1.ispvds.com.error.log
223M    /var/www/httpd-logs/site2.ru.access.log
765M    /var/www/httpd-logs/site2.ru.error.log
24K     /var/www/httpd-logs/site3.ispvds.com.access.log
4.0K    /var/www/httpd-logs/site3.ispvds.com.error.log
 

Можно заметить, что больше всего весят логи:  /var/www/httpd-logs/site2.ru.error.log и /var/www/httpd-logs/site2.ru.access.log

Удалять их нельзя, как мы отмечали ранее, поэтому только очистим содержимое с помощью команды:

cat /dev/null > /var/www/httpd-logs/site2.ru.access.log

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

Если окажется, что таких логов много, и каждый занимает весомый объем, можно «обнулить» их командой:

find /var/www/httpd-logs/ -type f -size +100M -exec truncate -s 0 {} \;

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

Другой частый случай переполнения диска — забитые почтовые ящики, особенно если они были взломаны или на них отправилась куча спама. Очистить почтовые ящики можно в панели управления ISPmanager в разделе Почта - выбрать нужный почтовый ящик и нажать справа значок •••, где выбрать Перейти в почтовый клиент, чтобы выборочно удалить письма, или Очистить, если письма в этом ящике в целом не нужны.

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

Просмотр количества свободных айнод в системе

Количество inode (индексных/файловых дескрипторов) в файловой системе задается при установке ОС —  обычно 1 inode на каждые 2 Кбайт пространства диска по умолчанию. Для большинства систем этого количества достаточно, но бывают и исключения.

Если индексные дескрипторы исчерпались, создание любого нового файла в системе, даже служебного, становится невозможным. Из-за этого вся система или любая её служба могут работать некорректно. В начале статьи мы упоминали, что исчерпание файловых дескрипторов можно посмотреть с помощью команды:

df -i

Вывод команды будет примерно таким:

Filesystem     Inodes  IUsed  IFree IUse% Mounted on
devtmpfs       232644    346 232298    1% /dev
tmpfs          235248      1 235247    1% /dev/shm
tmpfs          235248    442 234806    1% /run
tmpfs          235248     16 235232    1% /sys/fs/cgroup
/dev/vda4      523304 523087    217  100% /
/dev/vda2      523776    351 523425    1% /boot
tmpfs          235248      1 235247    1% /run/user/0
 

Как и в случае с df -h, здесь нужна строка с dev-устройством файловой системы. В примере выше — это /dev/vda4 и процент использования inode 100%. Несмотря на то, что в столбце IFree (кол-во свободных айнод) значение 159, для корректной работы ОС этого уже мало и создать новые она не даст.
 

Освобождение файловых дескрипторов

Что привело к этой проблеме? Где-то на VPS было создано или размещено большое количество файлов, суммарно приведшее к пределу возможных файлов в системе, т.е. перефразируя, у ОС есть максимальное значение количества файлов, и этот значение было почти достигнуто.

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

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. Для удаления этих файлов у 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

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

find /var/www/user2/data/www/site2.ru/bitrix/cache -type f -delete

(хотя в нашем примере файлов выявлено немного, можно и не удалять).

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