Сервер падает по ночам — как найти причину

MAATRIX GAMES

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

Соберите факты, прежде чем лезть в конфиги

Первая ошибка — сразу нырять в конфиги игры или логи мода, толком не зафиксировав картину падений. Прежде чем что-то чинить, заведите простую таблицу (хватит текстового файла) и запишите по каждому падению за последние 5-7 дней:

• точное время краша (не «примерно ночью», а до минуты — источник ниже);
• сколько игроков было онлайн в этот момент;
• сколько времени сервер проработал без перезапуска до падения (аптайм);
• было ли падение мгновенным (процесс исчез) или сервер завис и не отвечал, но процесс жил.

Уже на этом этапе видна разница между двумя классами проблем. Если время падений плавает (то 3:40, то 5:15, то вообще днём) — вероятнее нагрузка, конкретное действие игрока или случайный баг, и это тема для отдельного разбора через логи и краш-репорты. Если время стабильно повторяется с разбросом в несколько минут — почти наверняка совпадение с расписанием: либо ваша собственная cron-задача, либо задача на стороне хостинга. Именно этот второй случай разбираем дальше.

Cron на хосте: бэкапы и автообновления, которые совпадают по времени

Самая частая причина ночных падений — банальное совпадение с плановой задачей, которую сами же и настроили (или настроил хостинг по умолчанию) и забыли. Проверьте все источники расписания на сервере:

crontab -l
crontab -l -u <имя_пользователя>
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/
systemctl list-timers --all

Последняя команда важна отдельно — на современных Linux-дистрибутивах плановые задачи всё чаще живут не в classic cron, а в systemd-таймерах, и crontab -l их просто не покажет.

Типичные виновники:

• Автобэкап — архивация мира/сохранений через tar или rsync на большой объём данных упирается в диск и CPU на десятки секунд-минуты, во время которых игровой процесс не успевает отвечать на тики и вылетает по таймауту сторожевого скрипта. Если у вас настроено расписание бэкапов — сверьте его точное время с временем падений в вашей таблице.
• Автообновление сервера — скрипты через SteamCMD (steamcmd +login anonymous +app_update <appid> +quit), которые перезапускают процесс для применения патча, часто ставят по крону на ночь, чтобы не мешать игрокам — но если скрипт не проверяет, что новый процесс реально поднялся, вы получите «падение» без последующего рестарта.
• Ротация логов (logrotate) — редко валит сам сервер, но если он в этот момент активно писал в лог-файл, который logrotate переименовывает «на живую» без сигнала процессу на переоткрытие дескриптора, вывод может теряться, а в некоторых конфигурациях — вызывать зависание записи.
• Плановая перезагрузка ОС — проверьте systemctl list-timers | grep reboot и настройки автообновлений безопасности (unattended-upgrades на Debian/Ubuntu), которые по умолчанию могут стоять на реалистичное «ночное» время и в конце процесса дёргать reboot.

Практический тест: временно отключите (не удаляйте, просто закомментируйте) все ночные задачи на 2-3 суток и понаблюдайте. Если падения прекратились — виновник среди них, дальше включайте по одной.

Плановое обслуживание хостинга и автоматический рестарт

Если вы арендуете VPS или выделенный сервер, часть «расписания» вам не видна вообще — она живёт на стороне провайдера. Сюда относится:

• Плановые окна обслуживания — миграция виртуальной машины на другой физический хост (live migration), которая у некоторых гипервизоров сопровождается кратковременной заморозкой процессов на несколько секунд — для чувствительного к задержкам игрового тикрейта этого достаточно, чтобы процесс решил, что завис, и упал по внутреннему watchdog.
• Снапшоты на уровне хостинга — если провайдер снимает бэкап всей виртуалки целиком (а не вы сами бэкапите игру), это создаёт пиковую нагрузку на дисковую подсистему именно в момент снятия снапшота, обычно ночью по местному времени дата-центра — которое может не совпадать с вашим часовым поясом.
• Ограничения по ресурсам (throttling) — на тарифах с burstable CPU кратковременный лимит по нагрузке может совпадать с фоновой активностью хоста именно в непиковые (для хостинга) ночные часы.

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

Memory leak: когда причина копится весь день, а падает ночью

Отдельный и коварный класс проблем — постепенная утечка памяти, которая сама по себе не связана с ночным временем, но проявляется именно ночью, потому что к этому моменту память успевает выесться до предела за долгий день с игроками. Отличить это от cron-совпадения просто: аптайм до падения примерно одинаковый (например, стабильно 14-16 часов после утреннего рестарта), а не привязан к конкретной минуте.

Чтобы подтвердить утечку, нужен график потребления памяти во времени, а не разовый снимок. Минимальный вариант без внешних систем мониторинга — простой cron-скрипт раз в 10 минут:

*/10 * * * * echo "$(date +\%s) $(ps -o rss= -p $(pgrep -f your_server_process))" >> /var/log/mem_track.log

Если на графике (даже построенном вручную в таблице по этим цифрам) видна ровная лестница вверх без плато — это утечка, а не нормальная работа GC/аллокатора. Частые источники на игровых серверах:

• Java-серверы (Minecraft) — плагины/моды, которые копят ссылки на объекты игроков, чанки или entity без очистки; проявляется через -Xmx предел и OutOfMemoryError в логе ближе к ночи. Стоит свериться с оптимизацией TPS и настроек модов — часть утечек лечится именно настройками, а не увеличением RAM.
• Плагинные фреймворки (Oxide/uMod для Rust, ESX/QBCore для FiveM) — часто виноват конкретный плагин с багом в обработчике событий, который подписывается на хук повторно при каждом ретрайве без отписки от старого.
• Кэши без ограничения размера — самая частая причина в самописных или редко обновляемых модах: кэш растёт весь день пропорционально активности игроков и никогда не чистится.

Утечка — не всегда повод бить тревогу немедленно: как временную меру можно поставить плановый перезапуск сервиса ДО пика потребления (например, в 3:00 при падениях в 4:30), пока не найдёте и не почините конкретный источник. Это не решение, а пластырь, но он останавливает жалобы игроков, пока идёт настоящее расследование.

journalctl и systemd: как найти точное время и причину краша

Если игровой сервер запущен как systemd-юнит (а для стабильности так и должно быть — без этого нет автоперезапуска и внятных логов запуска/останова), у вас есть точный источник истины по времени падения, гораздо надёжнее, чем «вроде бы под утро»:

journalctl -u your-server.service --since "2026-08-29 00:00" --until "2026-08-30 12:00"

Ищите не только строки самого сервера, но и системные события вокруг момента падения:

journalctl -u your-server.service -o short-iso | grep -iE "start|stop|fail|kill"

Отдельно и обязательно — проверьте ядро на предмет OOM-killer'а, который молча убивает процесс при нехватке физической памяти, не оставляя ничего в логе самой игры:

journalctl -k --since "2026-08-29 00:00" | grep -i "out of memory"
dmesg -T | grep -i oom

Если видите Out of memory: Killed process <pid> (your_server) — это подтверждает гипотезу про memory leak или недостаточный объём RAM под сборку, а не баг игры. Если процесс завершился с конкретным exit-кодом (смотрите systemctl status your-server.service сразу после падения, пока запись не перезаписалась), код 137 почти всегда означает SIGKILL (тот самый OOM-killer или ручной kill -9), а 139 — сегфолт внутри самого процесса.

Если сервис перезапускается автоматически через Restart=on-failure в юните — это маскирует проблему от игроков (они просто увидят короткий disconnect), но не решает её: разница между «упал и сам поднялся за 10 секунд» и «упал и лежит до утра» огромная для восприятия, но причина в обоих случаях одна и та же и требует диагностики. Подробнее о правильной настройке автозапуска через systemd — в статье про systemd, screen и tmux для игровых процессов.

Как проверить каждую гипотезу по очереди

Когда собраны факты, самое время не гадать, а последовательно исключать причины — обычно это занимает 2-4 ночи, а не одну, потому что часть гипотез можно подтвердить только по накопленной статистике:

1. Сопоставьте таймлайн. Наложите время падений на список cron-задач/таймеров и на ответ поддержки хостинга про окна обслуживания. Совпадение с точностью до 5-10 минут — почти всегда не совпадение.
2. Отключите подозреваемую задачу на 2-3 суток. Если падения синхронно прекращаются — виновник найден, дальше чините саму задачу (переносите бэкап на менее нагруженное время, добавляете nice/ionice для снижения приоритета IO, чините скрипт автообновления).
3. Постройте график памяти параллельно, даже если уверены, что дело в cron — иногда работают сразу две причины, и устранение только одной снижает частоту падений, но не убирает их полностью.
4. Держите включённым мониторинг аптайма и доступности, чтобы не полагаться на жалобы игроков как на единственный сигнал — простой внешний пинг-чекер даёт куда более точные метки времени, чем сообщения в дискорде постфактум. Это же пригодится, чтобы объективно подтвердить хостингу факт падения при обращении в поддержку — подробнее в статье про инструменты аптайм-мониторинга игрового сервера.
5. Проверьте свежий бэкап на всякий случай, пока идёт расследование — если в процессе экспериментов (отключение задач, перезапуски) что-то пойдёт не так с миром/сохранением, вы не хотите разбираться ещё и с этим. Как правильно откатываться, если всё-таки понадобится — в материале про восстановление сервера из бэкапа.

Частые вопросы