Ця стаття допоможе швидко визначити, чому сайт на 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. Інструкція щодо роботи та підключення доступна тут.

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