CPU завантажений на 100%

Плато на графіку CPU у вкладці «Огляд» саме собою не є надзвичайною ситуацією: збірка проєкту чи створення архіву чесно використають усі ядра, а потім їх звільнять. Тривожно, коли плато тримається годинами, а машина перестає відповідати. Розберімося, хто винен.

Крок 1. Подивіться, що споживає ресурси

Вкладка «Екран» (VNC) зручна для роботи з повноекранними програмами:

btop
htop

Послідовна консоль не передає розмір вікна; там завжди 80×24, тож інтерфейс буде обрізаний. Для текстової консолі використовуйте стандартні команди:

top -b -n1 | head -20
ps aux --sort=-%cpu | head -10

Пам’ятайте арифметику: %CPU рахується на ядро. 400% на VDS-3 означає всі чотири ядра, а 100% на VDS-4 — лише одне з шести.

Крок 2. Відрізніть CPU від диска

Середнє навантаження (load average) зростає й від очікування вводу-виводу, не лише від обчислень:

uptime
vmstat 1 5

У виводі vmstat дивіться на стовпці us (код користувача), sy (ядро), wa (очікування диска) і st (вкрадений час). Великий wa означає, що CPU простоює в очікуванні диска — вузьке місце у швидкості запису, а не в обчисленнях. Плато диска на наших тарифах задає правило: запис 60 МБ/с на ядро, не нижче 60 і не вище 400 МБ/с, читання вдвічі вище, а сплеск утричі понад плато триває 30 секунд. Якщо завдання пише безперервно, сплеск закінчиться і ви впретеся в плато.

Крок 3. Дослідіть конкретний процес

pidstat -p <pid> 1 5
cat /proc/<pid>/status
journalctl -u <service> -n 100 --no-pager

Типові знахідки:

• вебзастосунок крутиться в нескінченному циклі після невдалого запиту;
• база даних виконує запит без індексу — перевірте її власний журнал повільних запитів;
• завдання cron запускається частіше, ніж встигає завершитися, і копії накопичуються: ps aux | grep <name> покаже десяток примірників;
• майнер, що потрапив на машину через слабкий пароль root. Ознака — процес із безглуздою назвою під нетиповим користувачем і високий вихідний трафік. У такому разі простіше перевстановити машину з вкладки «Доступ», ніж чистити її.

Крок 4. Обмежуйте, а не вбивайте

Якщо процес потрібен, але не повинен заважати решті:

renice -n 15 -p <pid>
systemctl set-property myapp.service CPUQuota=200%

CPUQuota=200% — це два повних ядра. Ліміт systemd переживає перезапуск служби; renice — ні.

Перш ніж вбивати процес через kill -9, спробуйте звичайний systemctl stop. Примусове вбивство бази даних коштує пошкоджених файлів і довгого відновлення під час наступного запуску.

Коли винен не код

Якщо навантаження законне й постійне, CPU Ryzen 9 7950X робить свою роботу — просто ядер не вистачає для завдання. Тариф можна змінити лише в бік збільшення, з доплатою за дні, що залишилися оплаченого періоду: дивіться статтю Підвищення тарифу та доплата різниці. Знизити назад не можна, тож спершу переконайтеся за графіками тижня й місяця, що плато не є одноразовим випадком.