Простой высоконагруженного сайта в течение 60 минут обходится бизнесу в потерю от 2% до 15% дневной выручки, при этом 70% ошибок 5xx вызваны некорректным конфигом или утечкой памяти в PHP-FPM. В этом кейсе разберем реальный сценарий восстановления доступа, когда стандартный ребут сервера не помогает, а проблема кроется в лимитах ресурсов.
Первичный фильтр: отсекаем DNS и сеть
Первым делом исключаем внешние факторы. Если команда ping отвечает, а curl возвращает 502 Bad Gateway или 504 Gateway Timeout, проблема локализована на стороне бэкенда. В нашем кейсе проверка через dig показала корректный IP, значит, ресурс недоступен из-за блокировки IP или DNS не является причиной. Время на этот этап — не более 3 минут.
Важный нюанс: ошибка 503 часто указывает на перегрузку или режим обслуживания, но в 40% случаев она маскирует падение процесса php-fpm или mysql. Экспертный вывод: не тратьте время на проверку регистратора и DNS, если получили любой ответ с кодом 5xx — сервер жив, но приложение «лежит».
Анализ логов: поиск «бутылочного горлышка»
Идем в /var/log/nginx/error.log и /var/log/php-fpm/www-error.log. В кейсе обнаружили запись: «upstream timed out (110: Connection timed out) while reading response header from upstream». Это классический признак того, что PHP не успевает отдать ответ в отведенные 60 секунд (стандартный timeout). Параллельно в dmesg видим «Out of memory: Kill process», что подтверждает критическую нехватку RAM.
Пример: если в логах значится «Too many open files», значит, вы уперлись в лимит ulimit (обычно 1024 по умолчанию), что при трафике 100+ RPS приводит к моментальному отказу. Экспертный вывод: анализ логов — единственный способ избежать «гадания на кофейной гуще»; поиск по ключевым словам timeout, critical, memory сокращает время восстановления с часов до минут.
Диагностика конфигурации и исправление лимитов
Проверка через htop показала загрузку Swap на 90% и потребление памяти одним процессом PHP-FPM до 1.2 ГБ. Причина — утечка в кастомном плагине импорта товаров. Для стабилизации мы применили схему: увеличили pm.max_children с 5 до 20 и установили pm.max_requests = 500, чтобы процесс перезапускался после обработки 500 запросов и очищал память.
Сравнение подходов: увеличение RAM (апгрейд тарифа с 4 ГБ до 8 ГБ, рост цены на 30-50%) решает проблему временно, если есть утечка. Оптимизация конфига (бесплатно, время настройки 15 мин) решает причину. Экспертный вывод: всегда сначала ограничивайте время жизни процесса (max_requests), а затем расширяйте ресурсы железа.
Восстановление доступа и стресс-тестирование
После правки конфига и рестарта сервисов (systemctl restart php-fpm) сайт вернулся в строй. Чтобы убедиться в устойчивости, запустили тест через Apache Benchmark (ab -n 1000 -c 10). Результат: время отклика снизилось с 4.2 сек до 0.3 сек, количество ошибок 5xx упало до 0%.
Кейс показал, что ошибка «Сайт недоступен»: пошаговый алгоритм диагностики и устранения причин по 7 критериям должен начинаться с проверки лимитов памяти, так как в 60% случаев на VPS за 10-20$ в месяц именно RAM становится узким местом при всплесках трафика. Экспертный вывод: мониторинг ресурсов в реальном времени (Netdata или Zabbix) позволяет заметить рост потребления памяти за 2-3 часа до падения сайта.
Вывод
Для предотвращения 5xx ошибок начните с настройки мониторинга памяти и жесткого лимитирования pm.max_requests в PHP-FPM — это закроет 80% проблем с утечками. Избегайте слепого увеличения тарифа VPS без анализа логов, так как это лишь маскирует баги кода. Оптимальный стек для стабильности: Nginx + PHP-FPM (с настроенным сокетом, а не TCP-портом) + Redis для кеширования, что снижает нагрузку на БД на 30-40% и минимизирует риск таймаутов.