Почему падает VDS: 7 неочевидных причин сбоя

Вы переехали на VDS, настроили быструю связку Nginx + PHP-FPM и оптимизировали базу данных. Сайт работает со скоростью мысли, но внезапно в самый разгар рабочего дня сервер падает. Реальные пользователи бьются об ошибку 500 Internal Server Error, а хостинг-панель не подает признаков жизни. Вы перезагружаете сервер через биллинг, всё восстанавливается, но через пару дней история повторяется.

Когда падает обычный хостинг, проблему решает техподдержка. На VDS вы остаетесь один на один с сервером. Самое опасное — это скрытые, неочевидные проблемы, которые не видны при обычном осмотре. Давайте разберем 7 скрытых причин, почему ваш сервер может уйти в глухой нокаут, и конкретные решения для каждого сбоя.

1. Трагедия OOM Killer: почему Linux сам убивает вашу базу данных

Самая частая причина внезапного падения MySQL или MariaDB — это системный механизм защиты ядра Linux, который называется OOM Killer (Out of Memory Killer). Когда на сервере физически заканчивается свободная оперативная память (RAM), операционная система, чтобы не зависнуть намертво и защитить ядро от коллапса, включает аварийный протокол. Она сканирует все запущенные приложения, высчитывает по специальной формуле количество набранных штрафных очков (oom_score) и принудительно, без предупреждения убивает самый тяжелый процесс. Естественно, этим процессом почти всегда оказывается база данных вашего сайта.

Чаще всего это происходит из-за скрытой перегрузки пула процессов PHP-FPM. Если на сайт одновременно набегают агрессивные ИИ-боты или парсеры конкурентов, а лимит pm.max_children настроен некорректно или оставлен дефолтным, каждый новый визитер порождает отдельный поток PHP, который отъедает по 40–80 Мб RAM. Память улетает в ноль за секунды. В системном журнале /var/log/syslog или dmesg в этот момент появляется характерная запись: «Out of memory: Kill process (mysqld)».

2. Смерть при свободном месте: исчерпание лимита Inodes

Вы заходите на сервер через SSH-консоль, вводите классическую команду проверки диска df -h и видите прекрасную картину: на NVMe-накопителе свободно еще 30–40 гигабайт пространства. Но при этом CMS вашего сайта сыплет фатальными техническими ошибками, сессии пользователей не сохраняются, корзина товаров сбрасывается, а MySQL наотрез отказывается записывать новые заказы, выдавая лог «No space left on device».

Причина кроется в исчерпании лимита inodes (индексных дескрипторов). В файловых системах Linux под каждый отдельный файл, папку или даже символическую ссылку выделяется одна inode. Количество этих дескрипторов жестко фиксируется в момент форматирования диска провайдером. Если ваш интернет-магазин генерирует миллионы мелких картинок товаров, или на сайте криво настроен плагин кэширования, создающий под каждую страницу отдельный микро-файл HTML, лимит inodes закончится гораздо раньше физических гигабайт. Введите в консоли df -i: если в колонке использования красуется 100%, сервер заблокирован.

find / -xdev -type d -exec sh -c 'echo "$(find "$1" -type f | wc -l) $1"' _ {} \; | sort -nr | head -n 10

3. Отсутствие Swap-файла (Аварийная подушка безопасности)

Многие хостинг-провайдеры продают VDS с полностью отключенным файлом подкачки (Swap). Логика дата-центров понятна: они хотят сберечь ресурс своих дорогостоящих корпоративных NVMe-дисков от постоянного износа при перезаписи системного кэша. Однако для стабильности вашего коммерческого проекта отсутствие Swap-пространства — это бомба замедленного действия.

Swap выполняет роль буфера безопасности. Когда оперативная память сервера заполняется под завязку в моменты пикового трафика, Linux не включает OOM Killer сразу. Вместо этого ядро берет «спящие» процессы, которые в данный момент не выполняют активных вычислений (например, фоновые службы мониторинга или неактивные потоки панели управления), и временно сбрасывает их данные из RAM на жесткий диск. Если Swap-файла на VDS нет, то при любом краткосрочном скачке посещаемости сервер мгновенно словит ошибку критической нехватки RAM и уронит базу данных.

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

4. Атака «зомби»: зависшие и залипшие процессы PHP

Когда реальный пользователь закрывает вкладку вашего интернет-магазина, не дождавшись загрузки тяжелого отчета, или поисковый бот обрывает сетевое соединение посередине долгой операции, Nginx мгновенно прекращает трансляцию. Но запущенный на сервере PHP-скрипт об этом обрыве связи ничего не знает. Он продолжает методично выполнять тяжелые вычисления или делать запросы к внешним API.

Если в глобальных настройках php.ini не заданы жесткие таймауты выполнения скриптов, такой процесс превращается в «зомби». Он продолжает мертвым грузом занимать место в оперативной памяти сервера и грузить процессор бесконечными циклами. Ситуация усугубляется, если скрипт пытается достучаться до стороннего сервера (например, забрать остатки поставщика или курс валют), который завис. Когда за сутки таких залипших процессов накапливается несколько десятков, они полностью парализуют процессор (CPU улетает в перманентные 100%), и сайт уходит в офлайн.

5. Переполнение диска логами (Эффект лог-бомбы)

Журналы сервера (access.log и error.log), архитектуру которых мы детально препарировали в первой статье, жизненно необходимы для SEO-аналитики и аудита безопасности. Однако при сильной хакерской атаке, бесконтрольном парсинге или циклической ошибке в коде какого-нибудь плагина эти текстовые файлы превращаются в оружие массового поражения для вашей операционной системы.

Если ваш сайт подвергся жесткому брутфорсу (подбору паролей) со стороны сотен ботов, Nginx начинает записывать каждую попытку входа. Текстовый файл лога начинает раздуваться со скоростью геометрической професси, прибавляя по несколько гигабайт в час. Как только логи занимают все 100% доступного дискового пространства накопителя, операционная система блокирует работу СУБД, так как MySQL не может записать временные таблицы. Сайт моментально закрывается с критической ошибкой, а вы теряете возможность зайти даже в панель управления хостингом.

6. Лимиты открытых файлов: скрытый потолок операционной системы

В архитектуре Linux действует фундаментальное правило: абсолютно всё является файлом. Обычная картинка товара, PHP-скрипт, кэш-директория, база данных и даже каждое открытое сетевое TCP-соединение с браузером пользователя обрабатываются системой как открытый файл. В целях безопасности у каждого пользователя в системе (включая системную учетную запись www-data, под которой работает веб-сервер) есть жесткий внутренний лимит на количество одновременно открытых дескрипторов файлов, называемый nofile.

По умолчанию во многих популярных дистрибутивах этот лимит составляет всего 1024 единицы. Если на ваш сайт одновременно зашло 200 пользователей и пара поисковых краулеров, браузер каждого посетителя отправляет десятки запросов на скачивание контента. Веб-сервер Nginx мгновенно упирается в системный потолок Linux, в логе ошибок появляется страшная запись «Too many open files», сервер наотрез отказывается принимать новые подключения, а клиенты видят бесконечную, пустую загрузку вкладки.

www-data soft nofile 65535
www-data hard nofile 65535

7. Медленный DDoS уязвимостей: атака без мусорного трафика

Классический DDoS — это примитивная грубая сила, когда сетевой канал вашего сервера забивают гигабитами бессмысленного мусорного трафика. Такую атаку легко обнаружить по графикам сетевой активности хостинга и заблокировать на уровне Cloudflare. Однако современные злоумышленники действуют гораздо изощреннее, используя так называемый «медленный» или прикладной DDoS (Application Layer Attack), нацеленный на уязвимости в логике работы вашей CMS.

Автоматический бот предварительно сканирует сайт и находит самую ресурсоемкую, тяжелую страницу. Чаще всего это внутренний поиск по каталогу товаров с использованием сложных многоуровневых AJAX-фильтров, скрипт генерации больших PDF-отчетов или страница корзины. Вместо миллионов запросов хакер запускает интеллектуальный скрипт, который шлет всего 5–10 запросов в секунду, но бьет прицельно по этим тяжелым адресам. Внешне сетевой трафик выглядит абсолютно нормально. Однако процессор вашего VDS мгновенно улетает в 100% перегрузку, пытаясь обработать сложнейшие математические сортировки баз данных.

limit_req_zone $binary_remote_addr zone=search_limit:10m rate=1r/s;