← Все статьиСерверы, безопасность и данные
· ~2 мин чтения · Пантюхов Роман Владимирович
Сервер завис из-за нехватки памяти: как найти причину и не допустить повторения
Поздно вечером одна из моих рабочих машин перестала отвечать: сайт не открывался, SSH подключался с большой задержкой, а Docker-демон не реагировал на команды. Сервер был небольшой — 2 ГБ оперативной памяти и ни одного гигабайта swap. На нём одновременно жили несколько Telegram-ботов, сайт и вспомогательные сервисы.
Как это выглядело снаружи
Первый признак — средняя нагрузка (load average) около 76 при двух ядрах процессора. Такое значение не означает, что процессор перегружен вычислениями: система десятки секунд ждёт, пока освободится память, и все процессы встают в очередь. В журнале ядра нашлась повторяющаяся запись об убитом процессе: один из фоновых воркеров задач получал сигнал от OOM-killer, Docker по политике перезапуска поднимал его снова, и всё повторялось по кругу.
Почему это не утечка памяти
Соблазн — обвинить воркер: «он ест всю память». Замер показал другое: сам процесс занимал около 170 МБ. Проблема была в общей тесноте — когда на 2 ГБ без запаса работает десяток контейнеров, любой кратковременный пик (сборка образа, всплеск трафика, перезапуск) выбивает систему из равновесия. Без swap ядру некуда «выдохнуть», поэтому оно начинает убивать процессы, а перезапуск убитого процесса создаёт новый пик.
Что я сделал сразу
Создал swap-файл на 2 ГБ, закрепил его в /etc/fstab, чтобы он подключался после перезагрузки, и ограничил его права. Через минуту нагрузка упала с 76 до 2, Docker снова начал отвечать, сайт вернулся. Это не лечение, а страховочная подушка: swap медленнее памяти, но превращает «система легла» в «система на секунду замедлилась».
Что стоит сделать до того, как это случится
Во-первых, у каждого контейнера в Compose задайте лимит памяти и разумную политику перезапуска: тогда один прожорливый сервис упрётся в собственный потолок, а не заберёт память у соседей. Во-вторых, настройте оповещение по свободной памяти и по росту load average — оба показателя предупреждают о беде за десятки минут. В-третьих, смотрите журнал ядра (dmesg с поиском по словам «Killed process»): он честно говорит, кого и когда убила система. Это входит в чек-лист подготовки сервера.
Когда пора увеличивать сервер
Swap — временная мера. Если на машине постоянно используется swap, а лимиты уже выставлены, честный ответ один: нужен тариф побольше. Разница в цене между 2 и 4 ГБ обычно меньше, чем стоимость часа простоя. Если вы не уверены, хватает ли вашему серверу запаса, это можно проверить в рамках настройки и защиты серверной инфраструктуры.