В феврале 2026 года я столкнулся с серьезным техническим вызовом: мой сервер на хостинге, на котором размещено 80 сайтов на WordPress и Elementor Pro, начал работать нестабильно. Нагрузка на процессор (CPU) постоянно скакала до 100%, а работа в админке стала практически невозможной из-за постоянных 500-х ошибок.
Входные данные: Что было с сервером изначально
- Инфраструктура: VPS на хостинге, управление через FastPanel.
- Ресурсы: 4 ядра CPU, 16 ГБ оперативной памяти.
- Нагрузка: Около 80 активных сайтов, большинство на Elementor Pro.
- Симптомы: График CPU в панели напоминал «пилу» с постоянными пиками до 100%. Значение Load Average (LA) поднималось выше 6.0, что для 4-ядерного процессора означает критическую перегрузку.
- Проблемы пользователей: Клиенты жаловались на «белый экран» при сохранении страниц, Elementor выдавал ошибку «Server Error (500)», а сама FastPanel периодически зависала.
Диагностика: Поиск «бутылочного горлышка»
Через консоль (утилита htop) я обнаружил, что основную нагрузку создавали процессы PHP-FPM. Каждый из 80 сайтов держал запущенными несколько процессов, даже если на сайт никто не заходил. Память была занята на 80%, а процессор разрывался между обработкой этих «спящих», но активных процессов. Дополнительно на одном из сайтов (kirpichev44) произошел конфликт плагина Code Snippets, который окончательно «положил» интерпретатор PHP.
Что было сделано: Пошаговый план спасения
1. Прорыв через консоль спасения Когда FastPanel перестала отвечать, я зашел через аварийную консоль хостинга. Исправил ошибку доступа SSH («Host key verification failed») и получил прямой контроль над системой под пользователем root.
2. Интеллектуальное управление процессами (Режим Ondemand) Это стало ключевым решением. По умолчанию сайты работали в режиме dynamic или static, удерживая процессы в памяти. Я массово перевел все 80 сайтов на режим ondemand (запуск по требованию). Теперь процесс PHP запускается только тогда, когда на сайт заходит реальный человек, и мгновенно завершается после его ухода.
Команда для PHP 8.2: sed -i 's/pm = .*/pm = ondemand/' /etc/php/8.2/fpm/pool.d/*.conf && systemctl restart php8.2-fpm
3. Снятие лимитов для Elementor Для стабильной работы тяжелых конструкторов я принудительно выставил лимит памяти в 512 МБ для всех конфигов PHP. Это убрало ошибки 500 при сохранении сложных лендингов.
Команда: sed -i 's/memory_limit = .*/memory_limit = 512M/' /etc/php/8.2/fpm/php.ini && systemctl restart php8.2-fpm
4. Включение Opcache и оптимизация кэширования На уровне сервера был активирован и настроен модуль Opcache. Это позволило хранить скомпилированный код сайтов в оперативной памяти, избавляя сервер от необходимости перечитывать файлы с диска при каждом клике. Скорость отклика админок выросла в 2-3 раза.
5. Хирургическое отключение проблемных плагинов Через командную строку я переименовал папку конфликтного плагина на сайте, который создавал максимальную нагрузку, что позволило мгновенно вернуть сайт в строй без доступа к админке.
Результат проделанной работы
- Load Average: Снизился с 6.0+ до стабильных 0.3 — 0.5 в режиме покоя.
- CPU: График стал ровным, без резких пиков. Процессор загружен в среднем на 15-20%.
- Оперативная память: Высвободилось около 5 ГБ памяти благодаря режиму
ondemand. - Стабильность: Все 80 сайтов работают быстро, Elementor сохраняет страницы мгновенно, ошибки 500 исчезли.
Вывод для будущего
Размещение большого количества проектов на одном сервере требует ухода от стандартных настроек «из коробки». Переход на ondemand, выделение достаточного memory_limit и использование Opcache — это обязательный минимум для веб-мастера в 2026 году. Этот опыт позволил мне не просто починить сервер, но и создать надежную платформу для дальнейшего роста моих проектов в Костроме и за её пределами.
