Як знайти скрипти, що навантажують процесор і ОЗП на Linux-сервері за допомогою команди htop

Команда htop на Linux-сервері — це один із найзручніших інструментів для моніторингу в реальному часі, який допомагає виявити скрипти, що надмірно споживають процесор та оперативну пам’ять. Аналізуючи колонки CPU%, MEM%, PID, USER, TIME+ та COMMAND у вікні htop, ви можете швидко зрозуміти, який саме PHP, Python, Node.js, cron, база даних або системний процес виснажує сервер. Далі залишається лише перевірити власника процесу, шлях до файлу та його призначення, щоб безпечно втрутитися.

Неважливо, чи це спільний хостинг, VPS, VDS або виділений сервер — більшість раптових уповільнень викликані неконтрольованими скриптами. Наприклад, некоректний плагін WordPress, PHP-файл із нескінченним циклом, інтенсивний cron-запуск, неоптимізований запит до бази даних або зламаний веб-файл можуть за лічені хвилини вивести CPU на 100%. Коли ж зростає споживання ОЗП, сервіси починають зависати, зникають з’єднання MySQL, сайти видають помилку 503, а ядро Linux може примусово завершити процеси через OOM Killer.

У цьому матеріалі ми поетапно розглянемо встановлення htop, як читати його вікно, виявляти скрипти, що виснажують процесор і пам’ять, знаходити шлях до файлів за PID та безпечно втручатися у процеси. Також розберемо, як перевіряти підозрілі сценарії, контролювати cron, аналізувати логи і впроваджувати профілактичні оптимізації. Якщо ж ви часто стикаєтеся з обмеженнями ресурсів, рекомендуємо також ознайомитися з Пакети VPS-серверів і Веб-хостинг високої продуктивності для вибору оптимальної інфраструктури.

Що таке htop і чому він кращий за команду top?

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

За допомогою htop ви можете в режимі реального часу побачити:

• Відсоток CPU, що використовує кожен процес
• Відсоток та обсяг використаної оперативної пам’яті кожним процесом
• PID процесу
• Користувача, який запустив процес
• Командний рядок або ім’я скрипта
• Час роботи та пріоритет процесу
• Load average, загальний обсяг RAM, swap та завантаження ядер CPU

Особливо у хостинг-середовищі, де на одному сервері працює багато сайтів, користувачів чи сервісів, недостатньо дивитися лише загальне споживання ресурсів. Важливо зрозуміти, до якого користувача, сайту, cron-завдання чи скрипта належить проблема. Команда htop на Linux саме для цього і служить швидкою стартовою точкою діагностики.

Встановлення htop: команди для різних дистрибутивів

У сучасних дистрибутивах Linux htop не завжди встановлений за замовчуванням. Якщо у вас є root або sudo-права, інсталяція займе лише кілька секунд. Рекомендується перед встановленням оновити список пакетів, особливо на нових серверах, щоб мінімізувати помилки.

Встановлення на Ubuntu та Debian

На серверах з Ubuntu або Debian скористайтеся такими командами:

sudo apt update

sudo apt install htop -y

Після встановлення запустіть htop командою htop. Якщо ви не маєте sudo-прав, зверніться до служби підтримки хостингу. На керованих VPS рут-доступ зазвичай належить вам.

Встановлення на AlmaLinux, Rocky Linux, CentOS і RHEL

У системах на базі RHEL пакетний менеджер може бути dnf або yum залежно від версії:

sudo dnf install htop -y

На старіших версіях CentOS може знадобитись підключення EPEL репозиторію:

sudo yum install epel-release -y

sudo yum install htop -y

Після успішного встановлення команда htop відкриє кольоровий моніторинговий інтерфейс. Якщо ви новачок у адмініструванні Linux, рекомендуємо ознайомитись з посібник з команд Linux, який допоможе швидко освоїти базові інструменти.

Як читати екран htop: пояснення колонок

При запуску htop у верхній частині екрана відображаються ядра CPU, RAM, swap, кількість завдань (tasks), потоків (threads), load average і час роботи системи (uptime). Нижче розміщено список процесів. Для діагностики найбільше цікавлять такі колонки:

Важливо пам’ятати: короткочасне сплеск навантаження CPU не завжди є проблемою. Зазвичай це буває під час резервного копіювання, оптимізації зображень, очищення кешу або пікової відвідуваності. Проблемою є тривале високе навантаження, зростання load average вище кількості ядер і відмова веб-сервісів відповідати.

Як знайти скрипти, що виснажують процесор, за допомогою htop

Щоб виявити процеси з високим навантаженням CPU, у htop натисніть клавішу F6 і виберіть сортування за CPU%, або просто клікніть на заголовок колонки у терміналах з підтримкою миші. На верху списку будуть процеси з найбільшим споживанням CPU.

Крок 1: Відсортуйте процеси за CPU%

Запустіть htop і сортуйте процеси за завантаженням CPU. Якщо серед перших позицій постійно з’являються php-fpm, php, python3, node, java, mysqld або bash — зверніть на них увагу. На однопроцесорних системах 100% — це максимум, а на багатоядерних значення може сягати 200%, 400% і більше, що означає використання кількох ядер.

Крок 2: Запишіть PID і USER

Зафіксуйте PID та користувача процесу. Наприклад, якщо ви бачите PID 24819, USER — siteuser і COMMAND — php /home/siteuser/public_html/wp-cron.php, то проблема, ймовірно, пов’язана з cron або WordPress сайтом. Якщо назва команди дуже коротка, увімкніть показ повного командного рядка в налаштуваннях htop або скористайтеся командою ps для детального перегляду.

Крок 3: Перевірте командний рядок процесу

Щоб побачити повний командний рядок за PID, виконайте:

ps -fp PID

Наприклад:

ps -fp 24819

Це допоможе точно визначити, з якого файлу запущено скрипт. Якщо це щось на кшталт php /home/korystuvach/public_html/index.php — це, можливо, звичайний веб-запит. Якщо ж php /home/korystuvach/public_html/wp-content/plugins/nevidomyy-plugin/task.php — проблема може бути у плагіні.

Крок 4: Перегляньте відкриті файли процесу

Команда lsof допоможе дізнатися, які файли, бібліотеки, логи, мережеві з’єднання відкриті процесом:

lsof -p PID

Це особливо корисно у хостинг-середовищі, щоб зрозуміти, який сайт або папка активні. Наприклад, якщо ви бачите дивні PHP-файли у каталозі /home/example/public_html/wp-content/uploads, це може свідчити про злом. У такому разі одного завершення процесу недостатньо — треба провести очищення файлів, змінити паролі, оновити плагіни та зробити сканування безпеки. Для налаштування безпечного з’єднання варто ознайомитись із рішення для сертифікатів SSL.

Як знаходити скрипти з великим споживанням ОЗП через htop

Проблеми з пам’яттю часто розвиваються непомітніше. При високому CPU завжди відчувається уповільнення, а при нестачі ОЗП сервіси можуть аварійно закриватись, активно використовуватись swap і зростати затримки. У htop відсортуйте процеси за колонкою MEM%, щоб побачити найбільш «пам’яттєвоємні» процеси.

Розуміння MEM%, RES і Swap

За замовчуванням htop показує MEM% — відсоток від загальної пам’яті. Корисно також звертати увагу на RES — фізичний обсяг пам’яті, який реально зайнятий процесом. VIRT — це віртуальна пам’ять, і вона не завжди відображає реальне споживання, тому нею не варто керуватися самостійно.

Наприклад, на VPS із 4 ГБ RAM один PHP-процес із RES 900 МБ — це надмірно. Якщо Node.js-програма росте з 200 МБ до 1.5 ГБ за час роботи — це може сигналізувати про витік пам’яті. Високе споживання RAM MySQL іноді є нормою через кешування, але тут треба комплексно дивитися налаштування буферів і загальну пам’ять системи.

Типові причини високого споживання RAM

• PHP, Python або Node.js у нескінченному циклі
• Завантаження великих CSV, XML або JSON-файлів у пам’ять за один раз
• Неоптимізовані плагіни та функції тем WordPress
• Обробка зображень, створення PDF або конвертація відео
• Відсутність кешування, що призводить до повторних важких запитів
• Велика кількість одночасних запусків одного скрипту через ботів або атаки
• Довготривалі фонові сервіси з витоками пам’яті

У таких випадках просто вбити процес командою kill — тимчасове рішення. Потрібно зрозуміти, що саме викликає навантаження, які дані обробляються і чому пам’ять не звільняється.

Пошук, фільтрація та дерево процесів у htop

Якщо на сервері працює сотні процесів, вручну шукати потрібний складно. htop має корисні гарячі клавіші: F3 для пошуку, F4 для фільтрації, F5 для відображення у вигляді дерева. Дерево дозволяє бачити, які процеси є дочірніми.

Наприклад, ви зможете легко розпізнати дочірні процеси php-fpm, що запускаються під nginx чи Apache, скрипти, викликані через cron, або Node.js-сервіси під управлінням supervisor.

Приклади корисних фільтрів

• Введіть php, щоб показати лише PHP-процеси
• Введіть python для виявлення Python-скриптів
• Введіть wp-cron для перевірки роботи WordPress cron
• Введіть node для моніторингу Node.js
• Фільтруйте за іменем користувача, щоб побачити процеси конкретного акаунту

Такі фільтри значно економлять час, особливо на серверах із багатьма користувачами. Якщо у вас багато сайтів, аналіз USER і шляху до файлу допомагає швидко визначити джерело проблеми. Для спрощення управління доменами рекомендуємо Перевірка домену та реєстрація.

Безпечний план дій при підозрі на проблемний PID

Знайшовши процес, що споживає багато ресурсів, не поспішайте одразу застосовувати kill -9. Це може призвести до втрати даних, неповних операцій запису або порушення роботи сервісів. Краще діяти поетапно.

1. Документуйте інформацію про процес

Запишіть PID, USER, COMMAND, CPU%, MEM% і час роботи. Зробіть скріншот htop, щоб мати з чим порівнювати при повторних проблемах. Це особливо важливо для агентств, інтернет-магазинів чи корпоративних проєктів, щоб пояснити клієнтам технічні нюанси.

2. Перевірте шлях до файлу процесу

Використовуйте ps -fp PID та lsof -p PID, щоб дізнатися, де знаходиться файл і які логи він генерує. Для WordPress важливо перевірити wp-content/debug.log, логи веб-сервера (access та error log), а для PHP-FPM — slow log.

3. Спробуйте спочатку коректно завершити процес

Надішліть стандартний сигнал завершення:

kill PID

Почекайте кілька секунд і перевірте, чи зник процес у htop. Якщо ні, і це критично для роботи сервера, тоді можна застосувати:

kill -9 PID

Пам’ятайте, що kill -9 миттєво припиняє процес без можливості на прибирання, тому використовуйте її обережно, особливо для операцій із базою даних або файловою системою.

4. Визначте причину повторного запуску

Якщо процес швидко перезапускається, це може бути cron, systemd сервіс, supervisor, веб-запит або атака ботів. Перевірте:

• cron за допомогою crontab -l
• системні сервіси через systemctl status <ім’я_сервісу>
• логи веб-сервера (access log)

Якщо причина у WordPress wp-cron, перегляньте реальну cron-конфігурацію та політику кешування.

Поєднання даних htop з логами для повної картини

htop показує, що саме навантажує ресурси, а логи допомагають зрозуміти чому. Без аналізу логів діагностика буде неповною. Наприклад, якщо pid процесу php-fpm в htop показує 180% CPU, без access log ви не дізнаєтесь, який URL чи бот викликав цей процес.

Корисні логи для перевірки:

• Access log веб-сервера — показує найактивніші URL
• Error log веб-сервера — PHP помилки, проблеми з правами, 500 помилки
• PHP-FPM slow log — повільні PHP сценарії
• MySQL slow query log — важкі SQL запити
• Auth log або secure log — підозрілі спроби входу
• Cron log — час запуску запланованих завдань

Якщо високе споживання CPU збігається з тисячами запитів на /wp-admin/admin-ajax.php, це може бути наслідком поганої роботи плагіна, атаки ботів або невдалої AJAX-операції. У такому випадку варто розглянути WAF, обмеження частоти запитів (rate limit), кешування і оптимізацію плагінів. Для більш глибокого аналізу продуктивності сайту рекомендовано Оптимізація швидкості веб-сайту.

Як відрізнити нормальне навантаження від проблемного?

Високе використання ресурсів не завжди означає кризу. Важливо враховувати апаратне забезпечення, рівень трафіку, тип додатку та технічне обслуговування. Наприклад, для VPS з 2 ядрами load average 6-8 — критично, а для виділеного сервера з 16 ядрами це може бути нормою. Тому при інтерпретації load average завжди враховуйте кількість ядер.

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

Чи може скрипт, що навантажує ресурси, бути шкідливим?

Високе споживання CPU або ОЗП не обов’язково є наслідком помилки. Зламані сайти часто використовують сервер для спаму, майнінгу криптовалют, проксі-трафіку, DDoS-ботів або бекдорів. У htop варто звернути увагу на процеси під підозрілими користувачами, випадкові імена файлів, виконання з /tmp, /dev/shm або папок uploads.

Підозрілі ознаки

• В полі COMMAND — непояснювані або випадкові символи
• Виконання з каталогів /tmp, /dev/shm або uploads
• Нестандартні perl, python або bash процеси
• Процеси з високою зовнішньою мережею
• Швидкий запуск великої кількості процесів від одного користувача
• Недавні несанкціоновані зміни у веб-файлах

Якщо є підозра на злом, перед завершенням процесу зробіть копії виводів команд для доказів. Перевірте права на файли, видаліть шкідливі скрипти, змініть всі паролі в панелі і CMS, оновіть плагіни, теми та ядро. Для безпеки адміністраторських панелей використовуйте двофакторну аутентифікацію, а також обмежуйте непотрібні права запису. Це допоможе знизити ризики у майбутньому.

Рекомендації для запобігання повторних проблем із продуктивністю

Знаходження проблеми через htop — лише початок. Найголовніше — не допустити повторного виникнення. Ось ключові рекомендації для зниження перерв у роботі через CPU і RAM:

• Налаштуйте PHP memory_limit, max_execution_time і pm.max_children відповідно до потужностей сервера
• Використовуйте кешування у WordPress, Joomla або кастомних рішеннях
• Видаляйте непотрібні плагіни, теми та модулі
• Оптимізуйте важкі SQL-запити за допомогою MySQL slow query log
• Не запускайте всі cron-завдання одночасно, розподіляйте їх по часу
• Впровадьте обмеження для ботів через rate limit, robots.txt та правила фаєрвола
• Регулярно обробляйте та архівуйте логи, щоб великі файли не впливали на диск і пам’ять
• Моніторте серверні метрики не лише в кризових ситуаціях, а систематично

Якщо після всіх оптимізацій навантаження залишається високим, можливо, причина у збільшеному трафіку, рості додатку або недостатньому хостинг-плані. Тоді варто обрати масштабовані VPS, додати пам’ять, перейти на швидкі NVMe-диски або виділений сервер із гарантованими ресурсами. Для вибору оптимального рішення порівняйте варіанти на сторінках Пакети хостингу і рішення для корпоративних серверів.

Приклад: сплеск CPU на WordPress-сайті

Розглянемо реальний кейс. VPS з 4 ядрами і 8 ГБ RAM, на якому працює кілька WordPress-сайтів. Користувачі скаржаться на повільність і помилки 502. Через термінал запускаємо htop — load average 12, всі ядра завантажені, а у верхній частині списку — безліч php-fpm процесів від одного користувача.

Фільтруємо по користувачу через F4. Занотовуємо PID процесу з високим навантаженням. Виконуємо ps -fp PID — це php-fpm воркер, потім lsof -p PID показує доступ до файлу /home/site/public_html/wp-content/plugins/example-importer/import.php. Аналізуємо access log — у цей же час адміністратор запускає імпорт, після чого йдуть повторні AJAX-запити.

Рішення: припинити процес імпорту, вимкнути заплановане завдання плагіна, розбити імпорт великого обсягу на частини, підкоригувати max_execution_time PHP. Замість wp-cron налаштовуємо системний cron. В результаті load average падає з 12 до 1.8, завантаження CPU нормалізується, а час відповіді сайту суттєво покращується. Цей приклад демонструє, наскільки ефективним є комплексний підхід із застосуванням htop, ps, lsof і аналізом логів.

Типові помилки при роботі з htop

• Закривати лише процес із найбільшим навантаженням, не досліджуючи корінь проблеми
• Вважати VIRT значення реальним споживанням пам’яті
• Розглядати кеш RAM MySQL як проблему, а не як нормальну поведінку
• Використовувати kill -9 як перший спосіб завершення процесу
• Обвинувачувати користувача або додаток без перевірки логів
• Ігнорувати кількість ядер при аналізі load average
• Не перевіряти цілісність файлів при підозрі на злом

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

Питання та відповіді

Для чого потрібна команда htop на Linux-сервері?

htop показує в режимі реального часу інформацію про процеси, їх використання CPU, ОЗП, користувача, PID і команду запуску. Це допомагає швидко виявити скрипти, що навантажують сервер.

Як за допомогою htop знайти скрипт із високим навантаженням CPU?

Відсортуйте процеси за колонкою CPU%, зафіксуйте PID і користувача підозрілого процесу, а потім за допомогою команд ps -fp PID і lsof -p PID перевірте, що саме запускається і де знаходиться скрипт.

Що важливіше враховувати при аналізі споживання пам’яті: MEM% чи VIRT?

Показники MEM% і особливо RES більш інформативні, бо відображають реальне використання фізичної пам’яті. VIRT показує віртуальну пам’ять і не завжди відповідає дійсному споживанню.

Чи можна одразу завершувати проблемний процес командою kill -9?

Зазвичай ні. Спершу потрібно зібрати інформацію про процес, перевірити шлях до файлу і спробувати завершити процес командою kill PID. kill -9 застосовується лише, якщо процес не завершується і критично впливає на сервер.

Чи завжди високе використання CPU в htop означає атаку?

Ні. Часто це буває через резервне копіювання, імпорт даних, оновлення кешу або піковий трафік. Але якщо процеси з дивними іменами або з /tmp, uploads працюють під незвичайними користувачами — це підозріло.

Отже, команда htop — це швидкий, зручний і потужний інструмент для пошуку скриптів, що виснажують процесор і пам’ять на Linux-сервері. Найкращі результати дає поєднання htop з аналізом PID, lsof, cron і логів. Якщо проблеми з ресурсами повторюються, варто переглянути і програмне забезпечення, і апаратну частину. Для вибору найкращого хостингу, VPS чи SSL-рішень рекомендуємо без тиску порівняти пропозиції на Hostragons.