Медленная работа MySQL и постоянные ошибки 502 Bad Gateway — главные враги сайтов на WordPress (Elementor, WooCommerce). В этой статье мы проведем полную диагностику и настроим идеальный баланс между Базой Данных, PHP и Nginx для максимальной производительности сервера.
Диагностика и выявление «бутылочного горлышка»
Первым делом проверяем основной параметр — размер буфера InnoDB. Он определяет, сколько данных MySQL может держать в быстрой оперативной памяти.
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
| Variable_name | Value |
|---|---|
| innodb_buffer_pool_size | 134217728 (128MB) |
Проблема: По умолчанию выделено всего 128MB. Если ваша база данных (например, 628MB) больше этого значения, сервер начинает читать данные с диска, что вызывает скачки CPU до 400%.
Оптимизация MySQL: Настройка my.cnf
Для стабильной работы WordPress нам нужно выделить достаточно памяти под базу, оставив запас для тяжелых PHP-процессов Elementor.
Актуальный баланс: Для сервера с 8GB RAM оптимально выделить 2GB под MySQL. Это покроет базу в 600-1500MB и оставит место для PHP-процессов, которые при активации WooCommerce могут потреблять до 512MB на каждый поток.
nano /etc/mysql/my.cnf
[mysqld]
# Основной буфер (увеличиваем до 2GB)
innodb_buffer_pool_size = 2G
innodb_buffer_pool_instances = 2
# Оптимизация записи и транзакций
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 32M
innodb_flush_method = O_DIRECT
# Ограничение временных таблиц (чтобы избежать Out of Memory)
tmp_table_size = 32M
max_heap_table_size = 32M
# Настройки соединений
max_connections = 150
skip_name_resolve = 1Индексация и чистка мусора
Даже быстрая память не спасет, если запросы не оптимизированы. Мы добавим индексы в самые «медленные» таблицы WordPress.
-- Ускоряем выборку настроек сайта
ALTER TABLE wp_options ADD INDEX idx_autoload (autoload);
-- Оптимизация WooCommerce и логов
ALTER TABLE wp_woocommerce_shipping_zones ADD INDEX idx_zone_order (zone_order);
ALTER TABLE wp_wpmailsmtp_debug_events ADD INDEX idx_created_at (created_at);
-- Чистка раздутых таблиц логов
TRUNCATE TABLE wp_wpmailsmtp_debug_events;
TRUNCATE TABLE wp_rank_math_404_logs;Связка: Nginx + PHP-FPM (Борьба с 502)
Если база работает быстро, но Nginx не может принять тяжелый ответ от PHP, вы увидите «Bad Gateway». Нужно расширить буферы передачи данных.
# Добавьте в конфиг Nginx в блок location ~ \.php$
fastcgi_buffer_size 128k;
fastcgi_buffers 64 64k;
fastcgi_busy_buffers_size 256k;
fastcgi_read_timeout 300;Почему это важно: Плагины безопасности (Cerber) и конструкторы (Elementor) передают огромные Cookie и заголовки. Без этих настроек Nginx будет «сбрасывать» соединение, считая его ошибочным.
Итоги глобальной оптимизации
Диагностика (Было)
- База 628MB жила в 128MB памяти
- Постоянный своп (чтение) с диска
- Ошибки 502 из-за узких буферов Nginx
- CPU 400% из-за очереди запросов
Результат (Стало)
- База полностью в RAM (2GB Buffer Pool)
- Nginx «проглатывает» любые заголовки
- Индексы ускорили wp_options в разы
- Нагрузка на CPU снижена до 15-20%
Теперь ваш сервер работает как единый слаженный механизм. Данные мгновенно отдаются из MySQL в PHP, а Nginx без задержек транслирует их пользователю.
systemctl restart mysql php8.1-fpm nginx
Какие проверки помогают найти проблему в MySQL
В WordPress и WooCommerce база данных часто становится не единственной, но важной частью проблемы с производительностью. Даже если на графиках в первую очередь видна нагрузка на CPU, её могут усиливать тяжёлые запросы к метаполям, большие автозагружаемые настройки, старые временные данные или фоновые очереди магазина.
Что стоит проверить
- Медленные SQL-запросы. Slow query log помогает увидеть конкретные запросы, а не гадать, какой плагин виноват.
- Текущие процессы MySQL. Список активных запросов показывает, что происходит в момент нагрузки.
- Автозагружаемые опции. Если их слишком много, WordPress тратит лишнее время почти на каждом открытии страницы.
- Таблицы WooCommerce. Для магазина особенно важны таблицы заказов, товаров, lookup-данных и очередей фоновых задач.
- Индексы. Добавлять их стоит только под реальные запросы, которые подтверждены диагностикой.
Безопасный порядок оптимизации
- Сделать backup базы перед любыми изменениями.
- Сохранить примеры запросов, которые реально создают нагрузку.
- Очистить очевидный мусор: старые временные данные, логи и зависшие фоновые задачи, если это безопасно для сайта.
- Проверить запросы через EXPLAIN перед добавлением индексов.
- После правок сравнить время ответа страниц, количество SQL-запросов и нагрузку на сервер.
Оптимизация MySQL должна опираться на данные сайта. Настройки сервера и индексы дают хороший результат только тогда, когда понятно, какой запрос или таблица создаёт узкое место.
