Коротка відповідь: Запустіть top, натисніть P і прочитайте три верхні процеси — винуватець знайдеться за секунди. Порівняйте load average із кількістю ядер, щоб оцінити серйозність, і вирішіть: некерований процес (перезапустити), сплеск трафіку (кешувати/масштабувати) чи завислий джоб (прибити). Для роботи з першопричиною є докладний гайд.

Огляд

Це інцидентний чекліст для «сервер раптово гальмує»: ідентифікувати, стабілізувати, потім розслідувати. Докладний гайд із тюнінгу — у категорії VPS.

Що потрібно мати

  • Доступ по SSH; якщо сервер занадто навантажений для входу — KVM Console.

Покрокова інструкція

  1. Зробіть знімок ситуації:
    uptime
    top -bn1 | head -20
    Load average вище за кількість vCPU-ядер означає реальну чергу (2 ядра + load 8 = насичення).
  2. Визначте головних споживачів у top (P сортує за CPU). Типові винуватці: php-fpm, mysqld, бекап-джоб, завислий скрипт.
  3. Перевірте, чи не маскується I/O wait під навантаження CPU — високий wa у top означає, що вузьке місце диск, а не процесор.
  4. Стабілізуйте: перезапустіть сервіс, що тече (sudo systemctl restart php8.3-fpm), прибийте некерований процес (kill PID) або призупиніть проблемний cron-джоб.
  5. Якщо навантаження — легітимний трафік, увімкніть кешування й розгляньте апгрейд плану; стабільні 100% на всіх ядрах — сигнал про розмір, а не баг.

Типові проблеми

  • Малвар/криптомайнери: невідомі процеси на повному CPU — звірте з чеклістом компрометації.
  • Штурми WordPress-крону чи боти: патерн видно в access-лозі — обмежте частоту або кешуйте.
  • Бекапи в години пік: перенесіть на найтихіше вікно.

Коли звертатися в підтримку

Якщо CPU тримається на межі без видимого процесу-споживача, або продуктивність різко впала без жодних змін навантаження з вашого боку, — відкрийте тикет із виводами uptime і top -bn1 та часовим вікном.

Часті запитання

Який load average завеликий для мого VPS?

Порівняйте з кількістю vCPU: load, що дорівнює кількості ядер, — повна утилізація, помітно вище — черга. VPS на 4 ядра з load 4 зайнятий, а з load 12 — насичений.

Невідомий процес зʼїдає весь CPU — що робити?

Розглядайте як можливу компрометацію: перевірте шлях до бінарника, користувача-власника й мережеві зʼєднання, перш ніж прибивати, і пройдіть чекліст зламаного сервера, якщо щось виглядає чужим.

Схожі статті

Потрібна допомога? Звернутися в підтримку Cloud2Y →

Ця відповідь Вам допомогла? 0 Користувачі, які знайшли це корисним (0 Голосів)