«No space left on device» ніколи не приходить вчасно. База перестає приймати записи, apt не може завершити оновлення, а Docker відмовляється завантажити образ, який потрібен саме зараз. Добра новина: на маленькому VPS винуватець майже завжди один із п'яти, і знайти його можна за пару хвилин.
1. Наскільки все погано?
df -h /
df -i /
Перша команда показує зайняте місце, друга — іноди. Якщо іноди на 100%, а місця ніби вистачає, у вас мільйони дрібних файлів: сесії, поштова черга, каталог кешу. Проблема інша, симптом той самий.
2. Шукаємо, що займає місце
Проходимо від кореня й сортуємо за розміром:
du -xh / --max-depth=1 2>/dev/null | sort -h | tail -15
Прапорець -x не дає зайти на інші файлові системи на кшталт /proc. Далі спускайтеся в найбільший каталог. Для інтерактивного перегляду зручніший ncdu:
apt install -y ncdu
ncdu -x /
Навігація стрілками, d — видалити. З останнім обережніше.
3. Швидкі перемоги
Це безпечно на будь-якому сервері з Ubuntu чи Debian:
apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M
apt autoremove заодно прибирає старі ядра. Журнал systemd дивує найчастіше: без обмежень він розростається до кількох гігабайтів. Щоб обмежити його назавжди, пропишіть SystemMaxUse=200M у /etc/systemd/journald.conf і виконайте systemctl restart systemd-journald.
4. Залишки Docker
Якщо у вас Docker, дивіться сюди насамперед. Старі образи й кеш збірки накопичуються з кожним деплоєм:
docker system df
docker image prune -a
docker builder prune
docker image prune -a видаляє образи, які не використовує жоден запущений контейнер. Зазвичай саме це й треба, просто під час наступного деплою їх доведеться завантажити знову.
Небезпечна команда — docker system prune -a --volumes. У томах лежать ваші дані, а том зупиненого контейнера вважається невикористаним. Саме так втрачають бази даних. Не копіюйте її з відповіді на форумі.
Другий прихований пожирач місця — логи контейнерів. Обмежте їх у /etc/docker/daemon.json:
{
"log-driver": "json-file",
"log-opts": { "max-size": "10m", "max-file": "3" }
}
Після цього перезапустіть Docker. Ліміт діє лише на контейнери, створені після зміни, тож перестворіть найбалакучіші через docker compose up -d --force-recreate.
5. Логи та забуті файли
Шукаємо великі файли по всьому диску:
find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null
find /var/log -type f -size +100M -exec ls -lh {} + 2>/dev/null
Типові знахідки: backup.tar.gz піврічної давності в /root, дамп бази, який хтось збирався завантажити, лог застосунку без ротації.
Лог, у який сервіс досі пише, не видаляйте через rm — обнуліть його:
truncate -s 0 /var/log/myapp/app.log
Якщо файл уже видалено, а місце не повернулося, його тримає відкритим якийсь процес:
lsof +L1
Перезапустіть сервіс зі списку, і місце звільниться.
Коли чистки замало
Іноді дані просто справжні: база, що росте, завантаження користувачів, файл моделі. Тоді чесне рішення — більше диска. Зміна тарифу збільшує диск на місці й зберігає все: у Nano 15 ГБ, у Micro 25 ГБ, у Small 35 ГБ, у Medium 45 ГБ. Сервер перезавантажиться один раз. Подробиці — в документації з тарифів.
Ще одна річ тихо займає місце — swap-файл. Якщо ви робили все за нашою інструкцією зі swap, ці 1–2 ГБ зайняті свідомо. А якщо головний споживач — Docker, то встановлення Docker і розгортання Compose-стека показують, як тримати образи під контролем.
Звичка, яка позбавляє всього цього: обмежте журнал і логи Docker у перший же день. Два рядки конфігурації — і «диск переповнений» майже перестає траплятися.
Коментарі
Поки немає коментарів. Будьте першим.