Кончившееся место — самая частая причина, по которой сервер перестаёт работать без всякого злого умысла. Сайт отдаёт 500, база не пишет, почта не уходит, а df -h при этом показывает, что несколько гигабайт свободно. Разберём все три случая, при которых так бывает, и заодно то, что стоит знать про SMART.

Случай первый: кончились inode

Файловая система хранит два ограниченных ресурса: место под содержимое и записи о файлах. Второй кончается независимо от первого:

df -h
df -i

Если во второй команде IUse% равен 100 — дело в inode. Место при этом есть, но создать файл нельзя ни один, даже пустой.

Виновники всегда одни и те же: миллионы крошечных файлов. Сессии PHP в /var/lib/php/sessions, у которых сломалась сборка мусора. Кэш приложения без очистки. Застрявшая почтовая очередь. Каталог с превьюшками. Найти можно так:

sudo find / -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20

Команда выдаёт каталоги с наибольшим числом файлов. На большой системе она работает минуты — это нормально.

Случай второй: файл удалён, место не вернулось

Ещё более коварная ситуация. Кто-то удалил разросшийся лог командой rm, но процесс, который в этот лог писал, продолжает держать его открытым. Файла в каталоге больше нет, место занято, и так будет до перезапуска процесса.

sudo lsof +L1

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

Отсюда правило: разросшийся лог не удаляют, а обнуляют — тогда открытый дескриптор остаётся рабочим:

sudo truncate -s 0 /var/log/huge.log

И сразу после этого настраивают ротацию, иначе через неделю всё повторится.

Случай третий: съели логи

Куда именно ушло место, показывает обход по уровням:

sudo du -x -h --max-depth=1 / | sort -h
sudo du -x -h --max-depth=1 /var | sort -h

Ключ -x не даёт уйти на другие файловые системы — без него счёт уползает в /proc и сетевые монтирования. Удобнее всё это делать в ncdu, если он есть.

Обычные пожиратели:

  • journald. Проверяется одной командой: journalctl --disk-usage. Ограничивается строкой SystemMaxUse=500M в /etc/systemd/journald.conf, разово чистится journalctl --vacuum-size=200M;
  • логи инструментов безопасности. Suricata со стандартным конфигом пишет три десятка типов событий и ротацию за собой не настраивает — на реальном сервере это дало 15 ГБ за двое суток. То же бывает с audit.log и с отладочными логами nginx;
  • бэкапы, которые складываются на тот же диск и никогда не удаляются;
  • кэш apt — apt clean возвращает иногда пару гигабайт.

Отдельно про /boot

Маленький раздел, забиваемый старыми ядрами. Сам по себе он сайт не роняет, зато намертво останавливает обновления: новое ядро не ставится, а вместе с ним встаёт и вся очередь пакетов. Лечится apt autoremove --purge, а профилактически — включением автоудаления неиспользуемых ядер в настройках автообновлений.

SMART: какие атрибуты имеют значение

Сразу оговорка: на виртуальном сервере SMART обычно недоступен — диск виртуальный, физического под ним вы не видите. Это не поломка, просто данных нет. Всё дальнейшее относится к выделенным серверам и своему железу.

sudo smartctl -a /dev/sda

Строка SMART overall-health self-assessment test result: PASSED — не повод расслабиться: она остаётся зелёной практически до самого отказа. Смотреть надо конкретные счётчики:

  • 5, Reallocated_Sector_Ct — переназначенные сектора. Не ноль — диск уже сыпется; растёт со временем — меняйте не откладывая;
  • 197, Current_Pending_Sector — сектора, которые не читаются и ждут решения. Самый тревожный из всех: обычно означает, что часть данных уже не восстановить;
  • 198, Offline_Uncorrectable — то же, подтверждённое проверкой;
  • SSD: Percentage Used / Media_Wearout_Indicator — израсходованный ресурс записи. Величина предсказуемая, по ней планируют замену заранее.

А вот температура и наработка в часах сами по себе ни о чём не говорят: диск с пятью годами наработки и нулевыми счётчиками ошибок надёжнее нового с единицей в 197-м атрибуте.

Смысл наблюдения

Всё перечисленное — реакция на уже случившееся. Между тем и заполнение диска, и деградация SSD — процессы медленные и прекрасно предсказуемые: график занятости за две недели показывает дату, когда место кончится, задолго до того, как это произойдёт. Разница между «сайт лежит с трёх ночи» и «в четверг надо почистить логи» — это всего лишь наличие цифры перед глазами. Как это выглядит собранным — на странице демо ниже.