DLE под нагрузкой: что ломается первым и как искать причину

Когда сайт на DataLife Engine начинает отдавать 502, страницы открываются по 5–10 секунд, а MySQL занимает процессор, причина обычно не в одном неудачном запросе. Под нагрузкой DLE проходит несколько узких мест: PHP-воркеры, соединения с базой, выборка новостей, полнотекстовый поиск, дополнительные поля и комментарии. Разбирать их нужно в таком порядке, иначе индексы не спасут сайт, на котором просто закончились рабочие процессы.

Сначала зафиксируйте, что именно сломалось

Материал рассчитан на DLE 17.x и типичную связку Nginx или Apache, PHP-FPM и MySQL либо MariaDB. Названия таблиц и набор включённых модулей могут отличаться: префикс базы задаётся при установке, а плагины часто добавляют собственные запросы.

Перед изменениями снимите базовую картину хотя бы за 10–15 минут и сравните её с периодом нагрузки:

• время ответа отдельно для HTML, админки, поиска и страницы новости;
• количество запросов в секунду и долю ответов 5xx;
• загрузку CPU, память, swap и дисковую задержку;
• число активных PHP-FPM-процессов и очередь на пуле;
• число соединений MySQL, медленные запросы и блокировки;
• какие URL и параметры чаще всего вызывают рост нагрузки.

Не включайте подробное логирование навсегда. На рабочем сайте оно само добавляет операции записи и может исказить картину. Для замера выберите короткое окно, сохраните логи, затем верните безопасные настройки.

Первый вопрос под нагрузкой — не «какой индекс добавить», а «какой ресурс закончился первым».

Сноска. Slow query log — журнал MySQL или MariaDB, куда попадают запросы, выполнявшиеся дольше заданного порога. Это не список всех плохих запросов: быстрый запрос, который запускается тысячи раз, тоже может стать проблемой.

Что ломается первым

1. PHP-FPM и очередь запросов

Первым ограничителем часто становится не база, а пул PHP-FPM. Если все рабочие процессы заняты, новые запросы ждут в очереди. Снаружи это выглядит как медленный DLE, хотя отдельный запрос к MySQL может выполняться быстро.

Проверьте в статусе PHP-FPM число активных процессов, достигался ли максимум и растёт ли очередь. Если при увеличении трафика база не загружена, а время ответа растёт, сначала ищите проблему здесь. Причины — слишком маленький пул, долгие внешние HTTP-запросы, тяжёлые плагины, генерация изображений или операции с файловой системой.

Увеличивать число процессов вслепую опасно. Каждый процесс PHP потребляет память, а слишком большой пул приводит к swap и замедляет уже весь сервер. Подбирайте лимит по фактическому потреблению одного процесса и доступной памяти, затем повторяйте нагрузочный тест.

2. Соединения и блокировки в MySQL

Если PHP-процессы заняты ожиданием базы, смотрите не только на CPU MySQL. Важнее состояние соединений и ожиданий: активные запросы, заблокированные операции, время до первого результата и количество подключений.

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

Для короткой диагностики в клиенте MySQL можно использовать стандартные команды. Они подходят для MySQL 8.0 и распространённых версий MariaDB, но набор столбцов в выводе отличается:

SHOW FULL PROCESSLIST;
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Threads_running';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';

Команда не объясняет, почему запрос медленный, но показывает, есть ли очередь и много ли операций выполняется одновременно. Для анализа плана нужен EXPLAIN, а для запросов с фактическими задержками — средства профилирования конкретной версии MySQL или MariaDB.

3. Главная страница и списки новостей

Главная DLE обычно собирает несколько блоков: последние публикации, популярные материалы, комментарии, рейтинги и дополнительные виджеты. Каждый блок может выполнять собственную выборку. На небольшом сайте это незаметно, а при трафике стоимость умножается на каждый запрос к главной.

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

Особенно внимательно проверьте сортировку по полям, которые добавляют плагины, выборку «популярных» материалов за период и блоки с комментариями. Если условие фильтра и сортировка не поддерживаются индексом, база может читать и сортировать большой объём строк перед тем, как вернуть небольшую страницу.

4. Поиск и фильтры

Поиск — частый кандидат на роль первого тяжёлого запроса. Он может проверять заголовок, краткое и полное описание, дополнительные поля и метки. Если запрос содержит несколько вариантов совпадения или сортировку по релевантности, обычный индекс по одному столбцу не обязательно поможет.

Сравните время поиска по одному слову, редкому слову и пустому или слишком общему запросу. Проверьте отдельные URL с параметрами фильтра: именно они часто обходят кеш и создают разные планы выполнения.

Не добавляйте индексы на все текстовые поля подряд. Поля с большими текстами требуют другого подхода, а лишние индексы увеличивают размер базы и цену записи новости, редактирования и импорта. Для полнотекстового поиска сначала определите, поддерживает ли используемая версия базы и конкретная схема DLE нужный тип индекса, затем сравните план и фактическое время.

5. Комментарии, рейтинг и счётчики

Комментарии создают нагрузку не только на страницу новости. На популярной публикации параллельно идут чтение списка, запись новых сообщений, обновление счётчиков и проверка ограничений. Если несколько операций меняют связанные данные, появляются блокировки и конкуренция.

Измерьте отдельно страницу с большим числом комментариев и страницу без них. Посмотрите, не выполняется ли полный подсчёт строк при каждом открытии. Пагинация, ограничение числа отображаемых комментариев и кеширование безопасных для кеша блоков обычно дают больший эффект, чем увеличение лимита соединений.

Как связать симптом с причиной

Что менять в первую очередь

1. Разделите трафик по сценариям. Отдельно измерьте главную, категорию, новость, поиск, авторизацию и админку. Проверка успешна, если вы знаете не только среднее время ответа, но и самый медленный сценарий.
2. Найдите повторяющийся запрос. Включите slow query log на короткое окно, сгруппируйте записи по тексту и URL-источнику. Проверка успешна, если у каждой группы есть частота и суммарное время, а не только максимальная длительность.
3. Посмотрите план выполнения. Для конкретного запроса используйте EXPLAIN и проверьте, какие таблицы читаются, используется ли индекс и сколько строк оценивает оптимизатор. Проверка успешна, если объяснение подтверждено замером на копии данных, а не только красивым планом.
4. Уберите лишние вызовы из шаблона. По очереди отключите виджеты и плагины на тестовой копии. Проверка успешна, если время и число запросов уменьшаются после одного конкретного изменения.
5. Только потом меняйте индексы и настройки пулов. Зафиксируйте план отката и повторите тест с той же параллельностью. Проверка успешна, если улучшился p95 или p99, а не только среднее значение.

Где оптимизация ломается

Индекс не исправит запрос, который сначала преобразует значение функции, ищет по большому текстовому полю или сортирует результат после выборки. Кеш страницы не поможет, если URL содержит постоянно меняющиеся параметры, пользователь авторизован или плагин принудительно отключает кеш.

Есть и другая ловушка: тест на одной странице. Главная может ускориться, а запись новой новости станет медленнее из-за лишних индексов. Поиск может стать быстрее, но сервер начнёт тратить больше памяти на параллельные операции. После каждого изменения проверяйте минимум чтение, запись, поиск и комментарии.

Не переносите настройки с одного сервера на другой без замеров. Версия MySQL или MariaDB, объём оперативной памяти, тип диска, PHP-расширения и размер таблиц меняют результат. Для DLE особенно важно учитывать плагины: два сайта с одинаковым шаблоном могут выполнять совершенно разный набор запросов.

Что делать дальше

Соберите небольшой повторяемый тест: фиксированный набор URL, одинаковые параметры поиска, известное число параллельных запросов и отдельная копия базы. Запишите p50, p95 и p99, число запросов к базе, ошибки 5xx и максимальное потребление памяти PHP.

После этого настройте наблюдение за тремя сигналами: очередью PHP-FPM, долгими запросами MySQL и долей медленных URL. Сначала найдите узкое место, которое съедает основную долю времени, затем исправьте один фактор и повторите тот же тест. Инвалидация кеша и архитектура полнотекстового поиска — отдельные темы; здесь важно не смешивать их с диагностикой первого отказавшего ресурса.