DLE-сайт тормозит или падает: что проверить в хостинге, PHP, MySQL и кэше

DLE-сайты часто используют для новостных, download, кино, контентных и файловых проектов. На старте такой сайт может работать быстро даже на обычном shared hosting. Проблемы начинаются позже: растет база, появляются тысячи новостей, heavy-шаблон, тизерные сети, внешние JS, комментарии, поиск, похожие новости, рейтинги, download-ссылки, боты, парсеры, Яндекс/Google-роботы и пиковый трафик после публикаций.

Типичная жалоба владельца DLE звучит так: “сайт иногда летает, а иногда открывается 10-15 секунд”, “в час пик падает”, “админка висит”, “MySQL грузит сервер”, “после добавления рекламы все стало медленно”, “хостинг говорит превышение CPU”, “переехали на VPS, но лучше не стало”.

Главная ошибка — сразу менять хостинг или покупать более мощный сервер без диагностики. Если DLE тормозит из-за отключенного кэша, кривого шаблона, старой версии движка, тяжелого модуля, отсутствующего индекса или внешней рекламы, новый сервер только временно замаскирует проблему. Правильный путь — сначала понять, где узкое место: хостинг, PHP, MySQL, кэш, шаблон, реклама, download-трафик или боты.

Сначала определите тип проблемы

Не все “тормозит” означает одно и то же. У DLE нужно разделять симптомы.

• Сайт медленно открывается всегда.
• Сайт тормозит только иногда.
• Сайт падает при пике трафика.
• Главная работает, а полные новости тормозят.
• Админка тормозит сильнее публичной части.
• Поиск по сайту вешает сервер.
• Сайт падает при публикации новой новости.
• Сайт падает при очистке или перестроении кэша.
• Сайт тормозит только с рекламными блоками.
• Сайт работает быстро для вас, но медленно для посетителей.
• Сайт открывается быстро, но download-файлы грузятся медленно.
• MySQL уходит в 100% CPU.
• PHP-FPM или Apache забивает все процессы.
• Сервер уходит в swap или OOM.

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

Почему DLE начинает тормозить на shared hosting

Shared hosting подходит для небольших сайтов. Но DLE-проекты часто вырастают быстрее, чем владелец замечает. Сначала 500 новостей, потом 10 000, потом 50 000, потом десятки тысяч картинок, теги, категории, похожие новости, поиск, комментарии, рейтинги, внешняя реклама и download-файлы.

На shared hosting обычно есть ограничения:

• CPU time;
• RAM;
• I/O;
• число процессов;
• число одновременных PHP-запусков;
• лимит MySQL-запросов;
• лимит подключений к базе;
• ограничения на cron;
• ограничения на долгие запросы;
• ограничения на download-трафик.

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

Какие версии PHP и MySQL нужны для DLE

Актуальные версии DLE требуют современный стек: PHP 8.0 или выше, MySQL 5.6+ или MariaDB 10.0+. Но “поддерживается” не значит “лучше вслепую переключить PHP на самый новый”. Старые шаблоны, хаки и модули DLE могут ломаться на новых версиях PHP.

Проверьте:

• версию DLE;
• версию PHP;
• версию MySQL или MariaDB;
• активные PHP-расширения;
• ошибки PHP после смены версии;
• совместимость шаблона;
• совместимость сторонних модулей;
• совместимость старых хаков;
• кодировку базы;
• тип таблиц MyISAM/InnoDB.

Если DLE старый, а PHP новый, возможны warnings, fatal errors, медленная работа и поломка отдельных функций. Если DLE новый, а PHP слишком старый, будут проблемы с совместимостью и безопасностью. Нормальная миграция DLE начинается с совместимости версий, а не с “поставим что свежее”.

Шаг 1. Проверьте нагрузку на сервер

Если сайт на VPS или dedicated server, начните с фактов. Во время тормозов зайдите по SSH и проверьте нагрузку.

uptime

top

free -h

df -h

iostat -xz 1

Если iostat не установлен:

apt install -y sysstat

Что смотреть:

• load average;
• CPU user/system/iowait;
• свободную RAM;
• использование swap;
• занятость диска;
• I/O wait;
• процессы php-fpm, apache, nginx, mysqld;
• количество одновременных процессов;
• нет ли OOM killer.

Если CPU свободен, но высокий iowait — узкое место диск. Если RAM закончилась и сервер ушел в swap — проблема в памяти. Если mysqld держит CPU — смотрим MySQL. Если php-fpm забил процессы — смотрим PHP, кэш и тяжелые страницы.

Шаг 2. Проверьте OOM killer и swap

DLE может падать не потому, что “движок плохой”, а потому что серверу не хватает RAM. Когда память заканчивается, Linux может убить MySQL, PHP-FPM или другой важный процесс.

Проверьте:

dmesg -T | grep -i "killed process\|out of memory"

journalctl -k --no-pager | grep -i "killed process\|out of memory"

Если в логах видно, что killed process — это mysqld, mariadbd, php-fpm или apache2, сайт падает из-за нехватки ресурсов.

Типичные причины:

• маленький VPS;
• слишком много PHP-FPM workers;
• MySQL забирает слишком много RAM;
• нет кэша страниц;
• тяжелые боты создают много одновременных запросов;
• download-файлы отдаются тем же сервером без ограничения;
• cron или backup запускается в час пик;
• неправильно настроен swap.

Swap не должен быть основным решением. Если сайт постоянно живет в swap, он будет тормозить. Нужна оптимизация или больше RAM.

Шаг 3. Проверьте PHP-FPM или Apache

На современных VPS DLE часто работает через nginx + PHP-FPM. На старых или shared-средах может быть Apache + mod_php или Apache + FastCGI. Суть одна: PHP должен успевать обрабатывать запросы.

Проверьте PHP-FPM:

systemctl status php*-fpm

journalctl -u php*-fpm --no-pager -n 200

Ищите ошибки:

• server reached pm.max_children;
• PHP Fatal error;
• Allowed memory size exhausted;
• Primary script unknown;
• upstream timed out;
• permission denied;
• connect() to unix socket failed.

Если PHP-FPM достиг pm.max_children, это означает, что все PHP-процессы заняты. Причины: мало workers, медленный PHP-код, долгие MySQL-запросы, отключенный кэш, боты, поиск, тяжелый шаблон или нехватка CPU/RAM.

Шаг 4. Проверьте ошибки веб-сервера

Nginx и Apache часто прямо говорят, что не так.

Для nginx:

tail -200 /var/log/nginx/error.log

grep " 5[0-9][0-9] " /var/log/nginx/access.log | tail -100

Для Apache:

tail -200 /var/log/apache2/error.log

или на AlmaLinux:

tail -200 /var/log/httpd/error_log

Частые ошибки:

• 502 Bad Gateway;
• 504 Gateway Timeout;
• upstream timed out;
• client intended to send too large body;
• permission denied;
• too many open files;
• FastCGI sent in stderr;
• PHP Fatal error;
• file not found из-за неправильного root/location.

Если в access log много 499, пользователи или боты не дожидаются ответа. Это часто признак медленного backend, тяжелых запросов или перегрузки сервера.

Шаг 5. Проверьте кэш DLE

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

Проверьте в админке DLE:

• включено ли кэширование;
• не отключен ли кэш на главной;
• кэшируются ли счетчики, если это доступно в вашей версии;
• работает ли кэш категорий;
• не очищается ли кэш слишком часто;
• не ломает ли кэш сторонний модуль;
• не забита ли папка cache;
• есть ли права на запись в cache-директории;
• не хранится ли кэш на медленном сетевом диске;
• не отключен ли кэш во время отладки.

Проверьте права на папки DLE, связанные с кэшем и загрузками. Если PHP не может писать в кэш, сайт может работать, но каждый запрос будет тяжелее.

Типичная ошибка: владелец отключил кэш “на время правок шаблона” и забыл включить обратно. На маленьком сайте это незаметно. На новостном проекте с трафиком это убивает производительность.

Шаг 6. Не путайте кэш DLE, OPcache и MySQL cache

У кэша есть разные уровни. Их нельзя смешивать.

• Кэш DLE снижает генерацию страниц и блоков на уровне CMS.
• OPcache ускоряет выполнение PHP-кода.
• Кэш nginx/CDN может отдавать готовый HTML или статику.
• Кэш браузера снижает повторные загрузки ресурсов.
• MySQL/MariaDB buffer pool кэширует данные и индексы в памяти.
• MySQL Query Cache в MySQL 8.0 уже отсутствует, поэтому это не универсальный путь.

Правильная оптимизация DLE — это не “включить один кэш”. Это несколько слоев: кэш DLE, OPcache, нормальные MySQL buffers, статика через nginx/CDN, аккуратные expires-заголовки и отсутствие тяжелых динамических блоков там, где они не нужны.

Шаг 7. Проверьте OPcache

OPcache почти обязателен для PHP-сайтов. Без него PHP каждый раз заново обрабатывает скрипты, что увеличивает CPU-нагрузку.

Проверьте:

php -i | grep -i opcache.enable

Для PHP-FPM важно проверять именно конфиг FPM, а не только CLI. Можно создать временный phpinfo-файл, открыть его через сайт, проверить OPcache и удалить файл сразу после проверки.

Что важно:

• OPcache включен для веб-PHP;
• памяти OPcache достаточно;
• нет постоянного переполнения;
• validate_timestamps настроен разумно;
• после обновления файлов кэш корректно сбрасывается;
• не включены конфликтующие настройки.

Если OPcache выключен, на DLE с посещаемостью CPU будет тратиться впустую.

Шаг 8. Включите slow query log

Если MySQL грузит сервер, не надо гадать. Нужно включить slow query log и посмотреть реальные медленные запросы.

В MySQL/MariaDB проверьте:

SHOW VARIABLES LIKE 'slow_query_log';

SHOW VARIABLES LIKE 'long_query_time';

Временно для диагностики можно поставить порог 1-2 секунды. Для активного анализа иногда ставят ниже, но осторожно, чтобы не залить диск логами.

Пример включения до перезапуска:

SET GLOBAL slow_query_log = 'ON';

SET GLOBAL long_query_time = 1;

SET GLOBAL log_queries_not_using_indexes = 'ON';

После сбора логов проверьте файл slow log. Расположение зависит от системы и настроек.

Типовые места:

/var/log/mysql/mysql-slow.log

/var/log/mysql/mariadb-slow.log

/var/lib/mysql/hostname-slow.log

Обобщить slow log можно так:

mysqldumpslow -s t -t 20 /var/log/mysql/mysql-slow.log

Смысл slow log: найти не “MySQL плохой”, а конкретные запросы, которые тормозят. Часто виноват один модуль, один блок шаблона, поиск, похожие новости, комментарии или выборка по дополнительным полям.

Шаг 9. Проверьте MySQL-процессы в момент тормозов

Когда сайт тормозит, зайдите в MySQL и посмотрите активные запросы.

SHOW FULL PROCESSLIST;

Ищите:

• много запросов в состоянии Sending data;
• долгие Copying to tmp table;
• долгие Sorting result;
• запросы с Locked;
• много одинаковых SELECT;
• запросы от поиска;
• запросы по xfields;
• запросы по комментариям;
• запросы от сторонних модулей;
• долгие UPDATE/INSERT при публикации.

Если в processlist постоянно висят одинаковые SELECT, нужно смотреть кэш и индексы. Если висят UPDATE/LOCK, смотрите тип таблиц и запись. Если каждый посетитель запускает тяжелую выборку, проблема в коде или модуле.

Шаг 10. Проверьте индексы в таблицах

У DLE-проектов часто тормозят запросы по категориям, датам, дополнительным полям, комментариям, тегам и поиску. Если запрос идет по большому количеству строк без индекса, сервер будет тратить CPU и диск.

Проверьте структуру таблиц:

SHOW INDEX FROM dle_post;

SHOW INDEX FROM dle_comments;

Для медленного запроса используйте:

EXPLAIN SELECT ...;

Что смотреть в EXPLAIN:

• используется ли индекс;
• сколько rows просматривается;
• есть ли Using temporary;
• есть ли Using filesort;
• какой key выбран;
• не идет ли full table scan по большой таблице.

Не добавляйте индексы вслепую. Индекс ускоряет чтение, но замедляет запись и занимает место. Добавлять нужно под конкретный медленный запрос из slow log, а не “по совету из старой темы”.

Шаг 11. Проверьте тип таблиц: MyISAM или InnoDB

Старые DLE-сайты часто живут с MyISAM-таблицами. Для старых сценариев это было обычным делом, но на современных нагрузках MyISAM может давать блокировки и проблемы при записи. InnoDB обычно лучше для конкурентной нагрузки, транзакций и row-level locking.

Проверьте тип таблиц:

SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = DATABASE();

Если сайт старый, перед любыми изменениями делайте backup. Нельзя просто массово конвертировать таблицы без теста. У старых DLE-версий, модулей и кодировок могут быть нюансы.

Практический подход:

• сначала backup базы;
• сначала тестовая копия;
• проверить совместимость DLE и модулей;
• сравнить нагрузку;
• проверить кодировки;
• проверить индексы;
• только потом менять production.

Шаг 12. Проверьте размер и мусор в базе

Размер базы сам по себе не всегда проблема. На форумах это часто повторяют: база в 20 MB не причина тормозов. Но база с мусором, логами, временными таблицами, миллионами комментариев, неочищенными статистическими данными и плохими индексами — уже проблема.

Проверьте самые большие таблицы:

SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024, 2) AS mb FROM information_schema.tables WHERE table_schema = DATABASE() ORDER BY mb DESC LIMIT 20;

Ищите:

• раздутые таблицы комментариев;
• таблицы статистики;
• таблицы логов;
• временные или старые таблицы модулей;
• мусор от удаленных плагинов;
• старые сессии;
• неочищенные поисковые индексы;
• дубли;
• поврежденные таблицы.

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

Шаг 13. Проверьте MySQL buffers

Если база активная, MySQL/MariaDB должен использовать память эффективно. Самая частая ошибка на VPS: серверу дали 4-8 GB RAM, но MySQL работает с дефолтными настройками, а данные постоянно читаются с диска.

Проверьте основные параметры:

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

SHOW VARIABLES LIKE 'max_connections';

SHOW VARIABLES LIKE 'tmp_table_size';

SHOW VARIABLES LIKE 'max_heap_table_size';

SHOW VARIABLES LIKE 'query_cache%';

Для InnoDB важен innodb_buffer_pool_size. Он должен соответствовать размеру сервера и роли базы. Но нельзя просто поставить “80% RAM”, если на этом же сервере живут nginx, PHP-FPM, Redis, backup, cron и другие процессы.

Плохие признаки:

• MySQL постоянно читает с диска;
• много temporary tables on disk;
• слишком большой max_connections;
• слишком маленький buffer pool;
• слишком агрессивный query cache на MariaDB под высокой записью;
• MySQL забирает всю RAM и вызывает OOM.

Шаг 14. Не надейтесь на MySQL Query Cache как на универсальное решение

В старых инструкциях по DLE часто встречается совет включить MySQL query cache. Для старых MySQL/MariaDB и read-heavy сайтов это иногда помогало. Но сейчас это нельзя считать универсальной практикой.

Почему:

• в MySQL 8.0 Query Cache удален;
• в MySQL 5.7 он уже был deprecated;
• на многопоточных нагрузках query cache может мешать из-за блокировок;
• при частых изменениях таблиц кэш постоянно инвалидируется;
• для активных сайтов лучше искать медленные запросы, индексы и CMS-кэш.

Если у вас MariaDB и сайт в основном read-only, query cache можно тестировать аккуратно. Но это тест, а не религия. Смотрите реальные метрики: cache hits, lowmem prunes, lock contention, время ответа страниц. Если стало хуже — выключайте.

Шаг 15. Проверьте поиск DLE

Поиск часто вешает DLE-сайты. Особенно если сайт большой, а поиск открыт ботам, нет ограничений, плохие индексы или поиск идет по большим текстовым полям.

Проверьте:

• много ли запросов к поиску в access log;
• индексируются ли поисковые страницы роботами;
• не спамят ли боты поиск;
• есть ли rate limit;
• есть ли captcha для подозрительной активности;
• какие SQL-запросы генерирует поиск;
• не попадает ли поиск в slow log;
• закрыты ли мусорные search URL от индексации.

Найдите обращения к поиску:

grep -E "do=search|/index.php\\?do=search|/search" /var/log/nginx/access.log | tail -100

Если поиск создает тяжелые SQL-запросы и открыт всем ботам, сервер будет периодически ложиться без видимой причины.

Шаг 16. Проверьте похожие новости, теги и дополнительные поля

На DLE часто тормозят не сами новости, а блоки вокруг них: похожие материалы, последние новости, популярное, теги, выборки по xfields, рейтинги, комментарии, блоки “с этим смотрят”.

Проверьте шаблон полной новости:

• сколько дополнительных блоков генерируется;
• кэшируются ли эти блоки;
• есть ли запросы по дополнительным полям;
• не делает ли каждый блок отдельный SQL-запрос;
• не идет ли выборка случайных новостей через ORDER BY RAND();
• не выбираются ли тысячи строк ради одного блока;
• не вызывается ли тяжелый модуль на каждой странице;
• не отключен ли кэш для динамического блока.

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

Шаг 17. Проверьте рекламу, тизеры и внешние JS

Владельцы новостных и download-сайтов часто ставят несколько тизерных сетей, пуши, popunder, счетчики, анти-adblock, CPA-виджеты и внешние скрипты. Потом сайт “тормозит”, но сервер при этом не загружен.

Здесь важно различать:

• серверный TTFB;
• полную загрузку страницы в браузере;
• блокировку рендера внешним JS;
• задержки рекламных сетей;
• тяжелую верстку;
• мобильные тормоза.

Если HTML отдается за 100-300 мс, но страница визуально грузится 8 секунд, проблема может быть не в хостинге, а во внешних скриптах.

Проверьте:

• сколько внешних рекламных скриптов стоит;
• не блокируют ли они рендер;
• есть ли async/defer;
• не грузятся ли скрипты из медленных доменов;
• нет ли битых рекламных endpoints;
• не вызывают ли скрипты длинные main-thread tasks;
• не отличаются ли мобильная и десктопная версии;
• не вставляет ли рекламный код лишние iframe и редиректы.

Технически сервер может быть быстрым, а пользователь видит тормоза из-за рекламы. Для контентных проектов это частая причина.

Шаг 18. Проверьте download-нагрузку

Для download-проектов DLE часто используется как каталог, а файлы отдаются с того же сервера. Это отдельная нагрузка. PHP и MySQL могут быть нормальными, но канал или диск забит скачиваниями.

Проверьте:

• какой объем download-трафика;
• отдаются ли файлы через nginx напрямую;
• не проходят ли большие файлы через PHP;
• есть ли ограничение скорости;
• есть ли hotlink protection;
• не качают ли файлы боты;
• не забивает ли download весь исходящий канал;
• не хранится ли все на медленном диске;
• не нужен ли отдельный storage/CDN;
• не смешаны ли сайт и файловая раздача на одном маленьком VPS.

Большие файлы нельзя отдавать через PHP без необходимости. Лучше, чтобы nginx отдавал статику напрямую. Если download-трафика много, сайт и файлы лучше разделять: сайт на одном сервере, файлы/CDN/storage — отдельно.

Шаг 19. Проверьте ботов и парсеров

Новостные и download-сайты часто сканируют боты, парсеры, SEO-сервисы, поисковики, зеркальщики и мусорные crawler-ы. Владелец думает, что сайт “падает сам”, а в логах видно тысячи запросов от нескольких IP.

Посмотрите топ IP:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -30

Посмотрите самые частые URL:

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -30

Посмотрите user-agent:

awk -F\" '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -30

Ищите:

• один IP делает тысячи запросов;
• бот ходит по search URL;
• бот перебирает страницы пагинации;
• бот качает файлы;
• бот обращается к несуществующим URL;
• бот игнорирует robots.txt;
• бот создает нагрузку на PHP, а не только на статику.

Решение — не “заблокировать всех ботов”. Поисковых роботов блокировать нельзя. Нужен rate limit, firewall, robots.txt для мусорных зон, защита поиска, ограничение download и анализ настоящих user-agent.

Шаг 20. Проверьте cron, backup и задачи DLE

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

Проверьте cron:

crontab -l

ls -la /etc/cron.*

grep CRON /var/log/syslog | tail -100

На AlmaLinux:

journalctl -u crond --no-pager -n 100

Проверьте:

• не запускается ли backup в час пик;
• не идет ли импорт одновременно с пиковым трафиком;
• не очищается ли кэш слишком часто;
• не выполняется ли несколько одинаковых задач параллельно;
• не пишет ли cron огромные логи;
• не делает ли backup дамп базы на тот же диск под нагрузкой;
• не сжимает ли архивы CPU в рабочее время.

Для DLE-проектов с трафиком cron нужно планировать, а не оставлять случайно.

Шаг 21. Проверьте права на файлы и cache/uploads

После переноса DLE на другой сервер часто ломаются права. Сайт может открываться, но кэш не пишется, картинки не загружаются, шаблоны не обновляются, а PHP пишет ошибки.

Проверьте владельца файлов:

ls -la

find . -type d -name cache -o -name uploads

Проверьте error log на permission denied:

grep -i "permission denied" /var/log/nginx/error.log | tail -50

Что важно:

• PHP-пользователь может писать в cache;
• PHP-пользователь может писать в uploads, если нужны загрузки;
• шаблоны имеют корректные права;
• нет 777 на всем сайте без причины;
• владелец файлов соответствует пользователю сайта;
• после миграции не осталось root:root на рабочих директориях;
• права не мешают созданию миниатюр.

Не лечите все командой chmod -R 777. Это быстрый путь к проблемам безопасности. Нужно выставлять владельца и минимально нужные права.

Шаг 22. Проверьте папки с изображениями и миниатюрами

DLE-сайты часто имеют много картинок. Если thumbnails генерируются на лету, нет кэша миниатюр или изображения слишком тяжелые, сервер и браузер будут страдать.

Проверьте:

• размер папки uploads;
• количество файлов;
• есть ли слишком большие изображения;
• генерируются ли миниатюры;
• не создаются ли миниатюры заново при каждом запросе;
• отдаются ли картинки через nginx напрямую;
• есть ли expires/cache-control для статики;
• не пропали ли картинки после миграции;
• не отдаются ли картинки через PHP;
• нет ли 404 по изображениям.

Проверьте 404 по изображениям:

grep " 404 " /var/log/nginx/access.log | grep -E "\.jpg|\.jpeg|\.png|\.webp|\.gif" | tail -100

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

Шаг 23. Проверьте шаблон DLE

Шаблон DLE может быть главной причиной тормозов. Особенно если он старый, перегружен таблицами, внешними скриптами, тяжелыми блоками и некэшируемыми вставками.

Проверьте:

• сколько SQL-запросов генерирует страница;
• есть ли тяжелые custom-блоки;
• нет ли ORDER BY RAND();
• нет ли десятков внешних скриптов;
• нет ли тяжелых inline-скриптов;
• не грузятся ли большие изображения без lazy loading;
• нет ли повторяющихся блоков;
• не тянутся ли старые JS-библиотеки;
• не вызывает ли шаблон сторонние API;
• работает ли мобильная версия.

Если старый DLE-шаблон был сделан много лет назад и пережил несколько версий движка, его нужно проверять отдельно. Нельзя считать, что “раз раньше работал, значит не он”.

Шаг 24. Проверьте сторонние модули и хаки

У DLE часто стоят сторонние модули: SEO, похожие новости, парсеры, рейтинги, комментарии, sitemap, турбо-страницы, реклама, антиботы, download-модули, плееры, дополнительные поля, API-интеграции.

Любой модуль может:

• делать тяжелые SQL-запросы;
• не поддерживать новую версию PHP;
• ломать кэш;
• создавать много файлов;
• обращаться к внешним API;
• выполняться на каждой странице;
• создавать lock-и в базе;
• писать огромные логи;
• конфликтовать с другим модулем.

Практическая диагностика: временно отключать не все сразу, а по одному модулю на тестовой копии или в окно низкого трафика, смотреть TTFB, SQL, логи и нагрузку.

Шаг 25. Проверьте логи DLE и PHP

Если PHP errors выводятся в лог, там часто уже написана причина.

Найдите PHP error log:

php -i | grep error_log

Проверьте типовые места:

/var/log/php_errors.log

/var/log/php*-fpm.log

/var/log/nginx/error.log

Ищите:

• Fatal error;
• Deprecated warnings после смены PHP;
• memory exhausted;
• undefined function;
• permission denied;
• failed to open stream;
• database errors;
• missing extension;
• ошибки шаблона;
• ошибки сторонних модулей.

Если лог каждую секунду забивается warning-ами, это тоже нагрузка. Ошибки нужно исправлять, а не просто скрывать display_errors.

Шаг 26. Проверьте конфигурацию nginx для DLE

Если DLE работает на nginx, важны rewrite-правила. Неправильный конфиг может давать 404, гонять запросы через PHP без необходимости или ломать статику.

Проверьте:

• правильный root сайта;
• корректный try_files;
• статика отдается напрямую;
• PHP обрабатывает только PHP-файлы;
• закрыты опасные директории;
• не отдаются конфиги наружу;
• есть gzip/brotli, если используется;
• есть cache-control для статики;
• нет лишних rewrite loops;
• нет передачи больших файлов через PHP.

Для DLE нельзя брать первый попавшийся nginx-конфиг из старой темы без проверки под вашу версию, структуру URL и панель управления. Особенно если сайт на HestiaCP, ISPmanager, aaPanel или самописной конфигурации.

Шаг 27. Проверьте Apache/.htaccess

Если сайт работает на Apache или nginx+Apache, .htaccess может сильно влиять на производительность. Большой .htaccess с множеством rewrite rules, редиректов и проверок выполняется на каждый запрос.

Проверьте:

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

Если после переноса с Apache на nginx ЧПУ сломались, проблема часто в том, что правила .htaccess не были перенесены в nginx-конфиг.

Шаг 28. Проверьте CDN

CDN может помочь DLE-сайту, особенно если много картинок, статики и download-файлов. Но CDN может и навредить, если настроен неправильно.

Проверьте:

• кэшируются ли статические файлы;
• не кэшируется ли админка;
• не кэшируются ли пользовательские страницы с сессиями;
• не ломаются ли cookies;
• не отдается ли старый HTML после обновления новости;
• не блокируются ли поисковые роботы;
• не ломается ли HTTPS между CDN и origin;
• не идет ли весь трафик мимо CDN;
• не кэшируются ли 404/500 слишком долго.

Для DLE лучше начинать с кэша статики и изображений. Полный HTML-кэш через CDN требует аккуратности: админка, авторизованные пользователи, комментарии, рейтинги и динамические блоки могут сломаться.

Шаг 29. Проверьте защиту от hotlink

Download и контентные сайты часто страдают от hotlink: другие сайты вставляют ваши картинки или файлы, а трафик платите вы. Это может забить канал и диск.

Проверьте access log по большим файлам и картинкам:

awk '{print $7}' /var/log/nginx/access.log | grep -E "\.zip|\.rar|\.mp4|\.jpg|\.png|\.webp" | sort | uniq -c | sort -nr | head -50

Проверьте referer:

awk -F\" '{print $4}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -50

Если чужие домены массово тянут ваши файлы, нужна hotlink-защита, CDN, отдельное файловое хранилище или ограничение доступа.

Шаг 30. Проверьте безопасность и заражение

Старые DLE-сайты с модулями и хаками часто взламывают. Взлом может проявляться не только редиректами, но и нагрузкой: скрытые скрипты, spam pages, дорвеи, майнеры, массовые запросы к базе, чужие cron-задачи.

Проверьте:

• неизвестные PHP-файлы в uploads;
• измененные engine-файлы;
• подозрительные eval/base64;
• новые cron-задачи;
• странные администраторы в DLE;
• неизвестные iframe/scripts в шаблоне;
• внезапный рост страниц в индексе;
• исходящие соединения с сервера;
• подозрительные процессы;
• изменения файлов за последние дни.

Команды для первичной проверки:

find /path/to/site -type f -name "*.php" -mtime -7

grep -R "base64_decode\|eval(" /path/to/site --include="*.php" | head

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

Что делать, если DLE тормозит только иногда

Периодические тормоза сложнее постоянных. Нужно поймать момент.

Проверьте:

• cron в это время;
• backup в это время;
• ботов в access log;
• пики download-трафика;
• slow query log за этот период;
• PHP-FPM max_children;
• MySQL processlist;
• iowait;
• OOM killer;
• внешние рекламные скрипты.

Если сайт иногда открывается 10-15 секунд, а иногда быстро, это часто не “большая база”. Это периодические блокировки, медленные внешние запросы, боты, кэш-промахи, cron, MySQL locks, I/O wait или лимиты shared hosting.

Что делать, если DLE падает при пике трафика

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

Порядок действий:

• включить и проверить кэш DLE;
• включить OPcache;
• проверить PHP-FPM workers;
• проверить MySQL slow log;
• проверить ботов;
• проверить heavy-блоки шаблона;
• вынести статику на nginx/CDN;
• ограничить поиск и download;
• проверить RAM и swap;
• перенести сайт на VPS/dedicated, если shared уперся в лимиты.

Если проект новостной и регулярно получает всплески, сервер должен быть рассчитан не на средний трафик, а на пики.

Что делать, если тормозит админка DLE

Админка может тормозить по другим причинам, чем публичная часть.

Проверьте:

• количество новостей;
• фильтры и поиск в админке;
• количество комментариев;
• модули в панели;
• ошибки PHP;
• медленные запросы при открытии списка новостей;
• права на папки;
• версии PHP и DLE;
• внешние проверки лицензий или обновлений модулей;
• блокировку внешних API.

Если публичная часть быстрая из-за кэша, а админка медленная, проблема часто в базе, списках, фильтрах, модулях и PHP, а не в nginx-кэше.

Что делать, если тормозит поиск

Поиск на больших DLE-сайтах нужно ограничивать и оптимизировать.

• Закрыть мусорные search URL от индексации.
• Добавить rate limit для поиска.
• Проверить slow query log.
• Проверить индексы.
• Ограничить частоту запросов с одного IP.
• Не давать ботам бесконечно перебирать поиск.
• Рассмотреть внешний поисковый движок для крупных проектов.
• Кэшировать популярные выдачи, если это оправдано.

Если на сайте сотни тысяч материалов, встроенный поиск CMS может стать слабым местом. В таком случае нужно не покупать CPU бесконечно, а менять подход к поиску.

Что делать, если тормозит из-за рекламы

Проверьте серверный ответ отдельно от полной загрузки страницы.

Команда для TTFB:

curl -o /dev/null -s -w "TTFB:%{time_starttransfer} Total:%{time_total}\n" https://example.com/

Если TTFB хороший, а браузер грузит страницу долго, смотрите рекламные сети и JS.

Что сделать:

• убрать лишние сети;
• оставить только доходные блоки;
• использовать async/defer;
• проверить waterfall в браузере;
• отключить медленные виджеты;
• не ставить тяжелую рекламу над первым экраном без необходимости;
• проверить мобильную версию;
• сравнить доход и скорость после отключения каждого блока.

Реклама должна приносить деньги, а не убивать сайт. Если один блок дает копейки и добавляет секунды загрузки, его нужно убрать.

Когда DLE пора переносить с shared hosting на VPS

Переход на VPS нужен, когда shared hosting уже не дает контроля и ресурсов.

Признаки:

• хостинг регулярно пишет о превышении CPU;
• есть лимиты Entry Processes;
• MySQL ограничен и недоступен для настройки;
• нельзя включить нужные PHP-расширения;
• нельзя настроить OPcache;
• нельзя смотреть полноценные логи;
• нельзя включить slow query log;
• download-трафик упирается в лимиты;
• кэширование на уровне сервера недоступно;
• сайт приносит деньги, а downtime уже стоит дороже VPS.

Но VPS требует администрирования. Если вы не хотите сами настраивать nginx, PHP-FPM, MySQL, firewall, backup и мониторинг, нужен Managed VPS или помощь администратора.

Какая конфигурация VPS нужна для DLE

Для небольшого DLE-сайта без download-нагрузки можно начать с 2 vCPU и 4 GB RAM. Для новостного или download-проекта с активным трафиком лучше смотреть 4 vCPU, 8 GB RAM и NVMe. Для крупных проектов, тяжелых баз, больших файлов и пикового трафика нужен dedicated server или отдельная архитектура: сайт отдельно, база отдельно, файлы/CDN отдельно.

Минимальный старт для живого DLE-проекта:

• 2 vCPU;
• 4 GB RAM;
• 40+ GB NVMe;
• 1 публичный IPv4;
• nginx + PHP-FPM;
• MariaDB/MySQL;
• OPcache;
• backup;
• доступ к логам.

Комфортнее для новостного/download-сайта:

• 4 vCPU;
• 8 GB RAM;
• 80+ GB NVMe;
• большой лимит трафика;
• настроенный nginx;
• настроенный PHP-FPM;
• настроенная MariaDB;
• кэш DLE;
• CDN для статики или файлов;
• мониторинг.

Если сайт отдает большие файлы, считайте не только CPU/RAM, но и исходящий трафик. Download-проект может упереться в канал раньше, чем в процессор.

Как проверить, что оптимизация помогла

Нельзя оптимизировать “на ощущениях”. До и после изменений замерьте:

• TTFB главной;
• TTFB полной новости;
• TTFB категории;
• количество SQL-запросов;
• slow query log;
• CPU load;
• RAM;
• iowait;
• количество 5xx;
• количество 404 по статике;
• время генерации страницы;
• скорость админки;
• пиковое количество одновременных пользователей;
• потребление трафика.

Если после включения кэша TTFB упал с 2 секунд до 200 мс, это реальный результат. Если после смены сервера TTFB не изменился, значит узкое место было не в железе или переехала та же проблема.

Частые ошибки владельцев DLE

Ошибка 1. Менять хостинг без диагностики.

Если причина в коде, шаблоне, модуле или кэше, новый хостинг не решит проблему полностью.

Ошибка 2. Держать старую версию DLE годами.

Старый движок, старый шаблон и старые хаки плохо переживают новые версии PHP и современные нагрузки.

Ошибка 3. Отключить кэш.

Для DLE с трафиком это почти гарантированная нагрузка на PHP и MySQL.

Ошибка 4. Считать размер базы главной причиной.

База может быть большой и быстрой, если есть индексы и нормальная настройка. Маленькая база может тормозить из-за плохих запросов.

Ошибка 5. Ставить много внешней рекламы.

Сервер может отвечать быстро, но пользователь будет ждать рекламные скрипты.

Ошибка 6. Отдавать download-файлы через PHP.

Большие файлы должны отдаваться веб-сервером, CDN или storage, а не тяжелым PHP-скриптом без необходимости.

Ошибка 7. Не смотреть slow query log.

Без slow log вы не знаете, какие SQL-запросы реально тормозят.

Ошибка 8. Добавлять индексы наугад.

Индекс должен решать конкретный медленный запрос. Иначе можно ухудшить запись и раздуть базу.

Ошибка 9. Отключать firewall и защиту ради “ускорения”.

Так вы получите ботов, парсеров и атаки. Нужны аккуратные правила, а не отключение защиты.

Ошибка 10. Не делать backup перед изменениями.

Любая оптимизация базы, таблиц, движка и шаблона без backup — риск потерять сайт.

Быстрый чек-лист диагностики DLE

• Проверить load average, CPU, RAM, swap, iowait.
• Проверить OOM killer.
• Проверить nginx/Apache error log.
• Проверить 500/502/504 в access log.
• Проверить PHP-FPM max_children.
• Проверить PHP Fatal errors.
• Проверить, включен ли кэш DLE.
• Проверить права на cache/uploads.
• Проверить OPcache.
• Включить slow query log.
• Посмотреть SHOW FULL PROCESSLIST во время тормозов.
• Проверить индексы под медленные запросы.
• Проверить тип таблиц MyISAM/InnoDB.
• Проверить раздутые таблицы.
• Проверить поиск DLE.
• Проверить похожие новости, теги, xfields.
• Проверить сторонние модули и хаки.
• Проверить внешнюю рекламу и JS.
• Проверить download-трафик.
• Проверить ботов и парсеров.
• Проверить cron и backup.
• Проверить CDN и статику.
• Проверить безопасность и заражение.

Как HSTQ может помочь DLE-проекту

Для DLE-сайта важен не просто “любой VPS”. Новостные, download и контентные проекты требуют нормального CPU, NVMe-диска, достаточной RAM, стабильной сети, доступа к логам, настройки nginx/Apache, PHP-FPM, MariaDB/MySQL, OPcache, кэша, backup и мониторинга.

HSTQ может помочь с VPS/VDS или dedicated server для DLE, переносом сайта, первичной настройкой сервера, диагностикой PHP/MySQL, проверкой логов, настройкой веб-сервера, SSL, кэша и базовой оптимизацией окружения. Если сайт уже упирается в shared hosting, правильный путь — не угадывать тариф, а сначала понять нагрузку: посещаемость, размер базы, объем файлов, download-трафик, ошибки, slow queries и пики.

Посмотреть VPS/VDS можно здесь: https://cp.hstq.net/store/vps-vds-nmve.

Если DLE-сайт тормозит или падает, при обращении лучше сразу подготовить: домен, версию DLE, версию PHP