Данная статья поможет быстро разобраться, почему тормозит сайт на shared-хостинге: из-за нехватки ресурсов аккаунта (CPU/RAM/IO) или из-за кода, базы данных и внешних зависимостей. Материал полезен, когда страницы стали отвечать медленнее, появляются периодические подвисания, а нагрузка ведёт себя нестабильно без очевидной причины.

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

Проверка нагрузки на хостинге

На shared-хостинге обычно нет доступа к системным логам уровня root, но остаются два практичных источника данных, которые помогают понять, есть ли проблема именно в ресурсах аккаунта (CPU/RAM/IO) и повторяется ли она по времени:

1. Отчёт «Использование системных ресурсов» в панели ISPmanager 4 — показывает суммарную нагрузку за сутки и помогает видеть закономерности.
2. Онлайн-наблюдение через top по SSH — показывает картину в реальном времени, когда сайт работает медленно.

Использование системных ресурсов

В этом отчёте обычно отображаются не проценты, а накопленные показатели за период (например, сколько секунд CPU и сколько минут суммарной активности процессов потребил аккаунт).

Смысл отчёта — не поймать пик прямо сейчас, а увидеть тенденцию: что растёт по дням (код/система/ожидания) и что могло это спровоцировать (рост трафика/ботов, новые плагины, фоновые задачи, импорты, изменения темы, разрастание кэша/логов).

Показатели и как их читать:

• Память (GB) Сколько оперативной памяти в среднем занимали процессы сайта в течение дня. Резкий рост часто совпадает с ресурсоёмкими задачами (импорт/экспорт, обработка изображений, прогрев кэша, обновления) или ошибками, которые порождают много параллельных процессов.

• User CPU (sec) Время CPU, потраченное на выполнение кода сайта (PHP/приложение): обработка запросов, плагины, фоновые задачи CMS. Рост User CPU обычно означает одно из трёх:

  • запросов стало больше (посетители/боты);
  • запросы стали более ресурсоёмкими (новые плагины/функции/персонализация);
  • выросла доля фоновых задач (cron, пересборка кэша, рассылки, импорты).

• System CPU (sec) Время на системные операции: файловая система, сеть, работа с диском, логирование и т. п. Практическая логика сравнения:

  • User CPU значительно выше System CPU → доминирует вычислительная работа приложения (логика/плагины/динамика).
  • System CPU высокий и близок к User CPU → заметная доля времени уходит на обслуживающие операции (файлы/диск/логирование/накладные расходы вокруг работы сайта).

• Время работы (minutes) Суммарная длительность работы процессов за день. Если минут много, а CPU не растёт пропорционально, это похоже на длительные ожидания (файлы/внешние запросы) или на фоновые процессы, которые выполняются долго.

• Операции ввода-вывода (IO) Индикатор активности по диску. Рост IO вместе с System CPU часто связан с записью логов, чтением/записью кэш-файлов, обработкой изображений, архивированием/бэкапами, частыми операциями с большим количеством файлов.

Наблюдение динамики нагрузки аккаунта на хостинге

Отчёт по ресурсам в панели обычно показывает накопленные значения за сутки: сколько секунд CPU и сколько минут суммарной активности процессов потребил аккаунт. Поэтому он предназначен не для поиска пика прямо сейчас, а для анализа динамики: что растёт постепенно, что даёт регулярные всплески, и с какими событиями это совпадает (обновления, импорты, новые интеграции, рост посещаемости).

Как смотреть динамику правильно

• Используйте два горизонта: 7 дней (быстрая диагностика) и 30 дней (устойчивый тренд).

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

• Сравнивайте не столько абсолютные числа, сколько форму графика/таблицы:

  • ступенька вверх — постоянное изменение в нагрузке (например, новый функционал или рост трафика);
  • пики по расписанию — cron/фоновые задачи, бэкапы, импорты;
  • плато — закрепившийся новый уровень потребления ресурсов хостинга.

Что означает рост конкретных показателей

• User CPU (sec) растёт — чаще всего это:

  • больше запросов (посетители/боты);
  • запросы стали более ресурсоёмкими (новые плагины/логика/персонализация);
  • увеличилась доля фоновых задач (cron, пересборка кэша, импорты, рассылки).

• System CPU (sec) растёт вместе с User CPU — заметная доля уходит на обслуживающие операции: файловая система, кэш-файлы, логирование, сетевые и дисковые накладные расходы. Практическая проверка: если System CPU становится близок к User CPU, нагрузка часто связана не только с вычислениями, но и с инфраструктурными операциями вокруг приложения.

• Время работы (minutes) растёт быстрее CPU — похоже на ожидания и длительные процессы: внешние HTTP-запросы, блокировки, медленная БД, очереди/воркеры, некорректные cron-задачи.

• Память (GB) растёт скачком — типично для ресурсоёмких операций (импорт/экспорт, обработка изображений, прогрев кэша, обновления) или ошибок, создающих много параллельных процессов.

Корреляция с источником нагрузки через логи

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

Что проверить:

• логи доступа и ошибок веб-сервера/приложения: всплески запросов, одинаковые URI, повторяющиеся User-Agent, серии 404/500;
• события по времени: обновления, импорты, рассылки, cron;
• типичные триггеры (если это WordPress): xmlrpc.php, wp-login.php, admin-ajax.php.

Онлайн-наблюдение через top

Утилита top показывает в реальном времени, какие процессы активны и какие ресурсы они потребляют. Это полезно именно при замедлении сайта.

Что помогает быстро понять:

• есть ли очередь задач (load average);
• упирается ли выполнение в CPU;
• есть ли давление по памяти и начинается ли swap;
• кто создаёт нагрузку: PHP, веб-сервер, фоновые задачи, иногда база.

Запуск и управление top

Для онлайн-наблюдения через top нужен доступ к серверу по SSH (если он доступен на вашем тарифе/услуге). Подключитесь по инструкции.

Если SSH-доступ есть, но вы не можете войти (например, забыли пароль от панели/аккаунта), сначала восстановите доступ по гайду.

После успешного подключения по SSH можно переходить к запуску top.

Выполните команду:

top

Как корректно зафиксировать показатели

Фиксируйте данные во время жалобы, а не после. Минимальный сценарий:

• сделайте 2–3 наблюдения с интервалом 30–60 секунд;

• переключите сортировки p (CPU) и m (Memory), включите c (полная команда);

• запишите:

  • us, sy, wa, id,
  • топ процессов по CPU и по памяти (названия или команды, %CPU, RES).

При необходимости снимок можно сохранить в файл (удобно для передачи в поддержку):

top -b -n 1 | head -n 40 > top_snapshot.txt

mytop — мониторинг нагрузки на MySQL

mytop — консольная утилита в стиле top, которая подключается к MySQL и периодически собирает данные, в том числе через SHOW PROCESSLIST и SHOW GLOBAL STATUS, чтобы быстро увидеть, какие запросы выполняются, кто их запускает и что удерживает базу.

Когда применять

• когда процессы PHP выполняются слишком долго, например, более 2-4 секунд;
• есть рост User CPU/System CPU и подозрение на нагрузку от БД;
• сайт стал подвисать, появляются таймауты, очереди фоновых задач;
• нужно оперативно увидеть ресурсоёмкие запросы и источники (пользователь/хост/база).

Запуск

Практичный запуск с явными параметрами (пример):

mytop --host localhost --u dbuser --d databasename  --prompt

Что смотреть в mytop в первую очередь

• однотипные запросы SQL, которых много или которые выполняются долго
• список потоков/запросов: долгие (Time), в состоянии Locked/Sending data/Copying to tmp table и т. п.;
• повторяющиеся шаблоны запросов: один и тот же Info/таблица/эндпоинт — кандидат на оптимизацию/кэш/индексы;
• скачки QPS (Queries Per Second): коррелируют с ботами, плагинами, cron, массовыми импортами.

Быстрая корреляция с веб-источником

Если в mytop видите всплеск запросов, следующий шаг — сопоставить время и URI/агент/источник по логам веб-сервера и приложения. Для этого используйте: Логи и отчёты в ISPmanager.

Что делать, если база данных перегружена?

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

Чтобы глубже разобраться в этом вопросе и решить проблему медленных запросов, рекомендуем изучить профильные материалы:

• Индексы баз данных: зачем они нужны — базовое руководство о том, как индексы кратно ускоряют поиск данных и снижают общую нагрузку на сервер.
• B-Tree индексы: как они работают — детальный разбор самого популярного типа индексов. Статья поможет понять внутреннюю логику работы MySQL и научиться структурировать данные для максимального быстродействия.

Вывод

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

Если по результатам наблюдений основная нагрузка приходится на CPU со стороны PHP-процессов, приоритет — оптимизация уровня приложения. В первую очередь проверяется корректность работы page cache, затем анализируются ресурсоёмкие плагины, модули и динамические блоки. На практике замедление чаще всего связано с трудоёмкой генерацией страниц, отсутствием или некорректной конфигурацией кэширования и избыточной динамикой.

Если же в показателях нагрузки стабильно доминирует база данных и значительная часть времени уходит на выполнение SQL-запросов, фокус смещается на оптимизацию БД: анализ медленных запросов, правильную расстановку индексов, структуры таблиц и устранение повторяющихся операций. Для первичной проверки структуры БД и проведения оптимизации можно использовать phpMyAdmin. Инструкция по работе и подключению доступна тут.

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