Як знайсці скрыпты, што «з’ядаюць» CPU і RAM на Linux-серверы праз htop

На Linux-серверы каманда htop — адзін з самых зручных інструментаў для жывога маніторынгу і выяўлення скрыптаў, што перазагружаюць працэсар (CPU) і аператыўную памяць (RAM). У htop можна аналізаваць слупкі CPU%, MEM%, PID, USER, TIME+ і COMMAND: гэта дазваляе бачыць, які PHP, Python, Node.js, cron, база дадзеных ці сістэмны працэс «грузіць» сервер. Далей вы можаце праверыць уладальніка працэсу, шлях да файла і мэту працы — і бяспечна рэагаваць.

Незалежна ад таго, ці карыстаецеся вы shared hosting, VPS, VDS або dedicated-серверам, у большасці выпадкаў раптоўнае запавольванне звязана з неконтраляваным скрыптам. Напрыклад, памылковы WordPress-плагін, PHP-файл у бясконцым цыкле, цяжкі cron, неаптымізаваны SQL-запыт або кампраметаваны web-файл можа за некалькі хвілін давесці CPU да 100%. Калі RAM заканчваецца, сэрвісы «завісаюць», MySQL-злучэнні падаюць, сайты выдаюць 503, а ядро Linux запускае OOM Killer для аварыйнага спынення працэсаў.

У гэтым гайдзе мы разгледзім: як усталяваць htop, як чытаць яго экран, як вылучаць скрыпты, што перазагружаюць CPU і RAM, як знайсці шлях да файла па PID і як бяспечна спыняць працэсы. Таксама будуць парады па бяспецы, аналізе cron, лагам і аптымізацыі, каб праблема не паўтаралася. Калі вы рэгулярна сутыкаецеся з лімітаваннем рэсурсаў, параўнайце Пакеты VPS-сервера і Вэб-хостынг з высокай прадукцыйнасцю, каб пераглядзець інфраструктуру.

Што такое htop і чаму ён лепшы за top?

htop — гэта інтэрактыўны інструмент для маніторынгу працэсаў у Linux. Як і top, ён паказвае нагрузку, але мае больш зручны інтэрфейс: колеры, сартаванне, пошук, фільтры і кіраванне працэсамі. Таму для аператыўнай дыягностыкі htop — першы выбар большасці адміністратраў.

У htop вы бачыце:

• CPU% для кожнага працэсу
• MEM% і аб’ём RAM, які выкарыстоўвае працэс
• Унікальны PID
• USER — хто запусціў працэс
• Камандны радок або назва скрыпта
• Час працы і прыярытэт
• Load average, агульную RAM, swap, выкарыстанне ядраў

У хостынгу, дзе на адным серверы некалькі сайтаў і карыстальнікаў, агульная нагрузка нічога не кажа. Важна — хто, які сайт, cron або скрыпт «грузіць» рэсурсы. htop дае хуткі першы дыягназ.

Як усталяваць htop: каманды для розных дыстрыбутыў

На многіх сучасных дыстрыбутывах htop не ўсталяваны па змаўчанні. Калі ў вас ёсць root або sudo, гэта займае пару секунд. Перад устаноўкай абновіце спіс пакетаў, асабліва на свежых серверах.

Устаноўка htop на Ubuntu і Debian

Каманды для Ubuntu/Debian:

sudo apt update

sudo apt install htop -y

Пасля ўстаноўкі запускайце htop. Калі sudo няма — звярніцеся да хостынг-правайдара. На VPS з кіраваннем root звычайна ваш.

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.

Як чытаць экран htop: што азначае кожны слупок?

У htop у верхняй частцы — ядры CPU, RAM, swap, колькасць задач, load average, uptime. Унізе — спіс працэсаў. Для дыягностыкі важныя слупкі:

Заўважце: кароткачасовы скачок CPU не заўсёды праблема. Напрыклад, падчас backup, аптымізацыі малюнкаў або высокага трафіка CPU можа вырасці. Праблема — калі адзін і той жа працэс хвілінамі «жруць» рэсурсы, load average пераўзыходзіць колькасць ядраў, і вэб-сэрвісы не адказваюць.

Як знаходзіць скрыпты, што перазагружаюць CPU праз htop

Каб выявіць скрыпты з высокай нагрузкай на CPU, у htop можна сартаваць па CPU% (F6 або клік па слупку). Працэсы наверсе — тыя, што зараз найбольш «з’ядаюць» працэсар.

Крок 1: Сартаваць па CPU%

Працуйце ў htop, сартаваўшы па CPU%. Калі, напрыклад, php-fpm, php, python3, node, java, mysqld ці bash пастаянна ў топе — запішыце працэс. На адным ядры 100% — ліміт, на шмат’ядравых сістэмах працэс можа паказваць 200% або 400% (выкарыстоўвае некалькі ядраў).

Крок 2: Запішыце PID і USER

Запішыце PID і USER падазронага працэсу. Калі PID 24819, USER siteuser, COMMAND php /home/siteuser/public_html/wp-cron.php — праблема, хутчэй за ўсё, у cron або WordPress на гэтым сайце. Калі COMMAND кароткі — у htop можна паказаць поўную каманду або скарыстацца ps.

Крок 3: Глядзіце сапраўдную каманду

Для дэталяў па PID:

ps -fp PID

Напрыклад:

ps -fp 24819

Вынік паказвае, з якога файла запушчаны скрыпт. php /home/user/public_html/index.php — трафік, php /home/user/public_html/wp-content/plugins/strange-plugin/task.php — праблема з плагінам.

Крок 4: Праверце шлях да файла і адкрытыя файлы

lsof паказвае, якія файлы адкрыты працэсам:

lsof -p PID

Вынік паказвае адкрытыя файлы, бібліятэкі, лагі і сеткавыя злучэнні. На хостынгу так можна вызначыць, у якой дырэкторыі працуе працэс. Калі ў /home/example/public_html/wp-content/uploads запускаецца дзіўны PHP — гэта можа быць інцыдэнт бяспекі. Тады трэба не толькі спыніць працэс, а і ачысціць файлы, змяніць паролі, абнавіць плагіны і правесці скан бяспекі. Для SSL і бяспечных злучэнняў глядзіце Рашэнні сертыфікатаў SSL.

Як знаходзіць скрыпты, што перазагружаюць RAM праз htop

Праблемы з RAM развіваюцца «падступна»: CPU — гэта адразу запаволенне, RAM — выпадковае спыненне сэрвісаў, swap, агульная затрымка. Сартуйце па MEM% у htop, каб убачыць працэсы, што больш за ўсё «жруць» памяць.

MEM%, RES і Swap: што важна?

Па змаўчанні htop паказвае MEM%. У некаторых настройках — VIRT, RES, SHR. Для RAM важны RES: рэальная занятая памяць. VIRT — не заўсёды сапраўдны расход, можа быць падманлівы.

На VPS з 4 ГБ RAM адзін PHP-працэс з 900 MB RES — ненармальна. Node.js, што вырас з 200 MB да 1.5 GB — верагодна, memory leak. Для MySQL/MariaDB высокая RAM — часам норма (cache), але трэба ацэньваць у комплексе.

Тыповыя прычыны высокага расходу RAM

• PHP, Python, Node.js у бясконцым цыкле
• Загрузка вялікіх CSV, XML, JSON у памяць
• Неаптымізаваныя WordPress-плагіны і функцыі тэм
• Апрацоўка малюнкаў, PDF, відэа
• Адсутнасць cache — цяжкія запыты паўтараюцца
• Бот-трафік або атака — шмат копій аднаго скрыпта
• Memory leak у даўгачасовых сэрвісах

Прастое «kill» працэсу — толькі часовае вырашэнне. Для стабільнасці трэба аналіз скрыпта, што ён робіць і чаму не вызваляе памяць.

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

Калі сотні працэсаў — ручны пошук складана. htop дае F3 (пошук), F4 (фільтр), F5 (дрэва). Дрэва паказвае parent-child: php-fpm пад Apache/nginx, cron-скрыпты пад cron, Node.js пад supervisor.

Практычныя фільтры

• php — толькі PHP-працэсы
• python — толькі Python-скрыпты
• wp-cron — маніторынг WordPress cron
• node — Node.js-прыкладанні
• USER — працэсы канкрэтнага хостынг-аккаунта

Фільтры эканомяць час, калі на серверы 30 сайтаў. 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 — жорстка спыняе, без магчымасці «прыбраць». Асцярожна з базамі дадзеных, запісам у файлы, backup.

4. Калі працэс з’яўляецца зноў — шукайце «трыгер»

Калі працэс запускаецца зноў — верагодна, cron, systemd service, supervisor, web-запыт або бот. Для cron — crontab -l, для сэрвісаў — systemctl status servicename, для web — access log. Для WordPress wp-cron — лепш рэальны cron і cache.

Аб’яднанне htop з лагамі для дыягназу

htop паказвае, што «жруць» рэсурсы; логи — чаму. Без лагаў дыягназ няпоўны. Напрыклад, php-fpm з 180% CPU — але без access log не зразумела, які URL або бот запускае працэс.

Якія логи глядзець:

• Web access log — паказвае нагрузку па URL
• Error log — PHP-памылкі, правы, 500
• PHP-FPM slow log — павольныя PHP-файлы
• MySQL slow query log — цяжкія SQL-запыты
• Auth/secure log — падазроныя ўваходы
• Cron log — калі і што запускаецца

Напрыклад, калі ў htop PID «жруць» CPU і ў той жа час у access log тысячы запытаў на /wp-admin/admin-ajax.php — праблема ў плагіне, боте або дрэнна напісаным AJAX. Тут важныя WAF, rate limit, cache, аптымізацыя плагіна. Для агульнай хуткасці сайта глядзіце Аптымізацыя хуткасці сайта.

Як адрозніць нармальную і праблемную нагрузку?

Высокая нагрузка — не заўсёды крызіс. Улічвайце сервер, трафік, тып праграм, тэхнічнае абслугоўванне. Для VPS з 2 ядрамі load average 6–8 — сур’ёзная праблема. Для dedicated з 16 ядрамі — норма. Load average трэба ацэньваць з улікам ядраў.

Так вы адрозніце непатрэбную паніку ад рэальнага крызісу. У e-commerce нагрузка можа вырасці падчас акцый, аплаты, абнаўлення запасаў — гэта нармальна, пакуль не пагаршае карыстацкі досвед. Калі так — аптымізуйце праграму і сервер разам.

Пытанне бяспекі: ці можа скрыпт, што «жруць» рэсурсы, быць шкодным?

Не кожны «жруць» скрыпт — памылка. На кампраметаваных сайтах хакеры запускаюць spam, cryptomining, proxy, DDoS-боты або «бэкдоры». htop паказвае падазроныя каманды пад нечаканымі карыстальнікамі, выпадковыя імёны, працэсы з /tmp або public_html/uploads — гэта трэба аналізаваць з пункту гледжання бяспекі.

Падазроныя прыкметы

• COMMAND з незразумелымі або выпадковымі імёнамі
• Працэсы з /tmp, /dev/shm або uploads
• perl, python, bash, якіх не павінна быць
• Працэсы з высокім outbound-трафікам
• Мноства працэсаў пад адным карыстальнікам за кароткі час
• Нядаўнія несанкцыянаваныя змены ў вэб-файлах

Перад спыненнем працэсу захавайце доказы (вывад каманды), праверце правы, ізалюйце шкодныя файлы, змяніце ўсе паролі, абнавіце плагіны і тэмы, скануйце сістэму. Дадайце двухфактарную аўтэнтыфікацыю і выдаліце непатрэбныя правы на запіс.

Як прадухіліць паўтор нагрузкі: лепшыя практыкі

Знайсці праблему праз htop — добра; але важней прадухіліць яе паўтор. Вось што істотна для Linux-сервераў:

• Наладзьце PHP memory_limit, max_execution_time, pm.max_children пад магчымасці сервера
• У WordPress, Joomla і іншых скарыстайце cache
• Выдаліце непатрэбныя плагіны, тэмы, модулі
• Аптымізуйце SQL па slow query log
• Не запускайце ўсе cron-заданні адначасова
• Рэйтынг-ліміты, robots.txt, firewall для ботаў
• Рэгулярна круціце логи; вялікія log-файлы ўплываюць на disk і RAM
• Маніторынг не толькі падчас крызісу, а і рэгулярна

Калі нагрузка не падае нават пасля аптымізацыі — магчыма, праблема не ў праграме. Трафік вырас, праект пашырыўся, хостынг-тариф ужо не трымае нагрузку. Тут патрэбны маштабуемы VPS, RAM, NVMe або ізаляваны сервер. Параўнайце Пакеты хостынгу і рашэнні для карпаратыўных сервераў для аналізу патрэб.

Прыклад: выбух CPU на WordPress-сайце

Разгледзім рэальны выпадак. На VPS з 4 ядрамі і 8 ГБ RAM працуе некалькі WordPress-сайтаў. Карыстальнікі скардзяцца на павольнасць і 502-памылкі. У htop load average — 12, усе ядры заняты, наверсе — шмат php-fpm-працэсаў ад аднаго карыстальніка.

F4 — фільтр па карыстальніку, запіс PID, ps -fp PID паказвае php-fpm worker, lsof -p PID — доступ да /home/site/public_html/wp-content/plugins/example-importer/import.php. У access log — масавая актывацыя гэтага файла адміністратарскім запытам і цягам AJAX.

Рашэнне: спыніць імпарт, выключыць задання плагіна, падзяліць імпарт на часткі, скарэктаваць PHP max_execution_time, выкарыстоўваць рэальны cron заміж wp-cron. Load average падае з 12 да 1.8, CPU нармалізуецца, сайты хуткія. Гэты прыклад паказвае — htop эфектыўны ў комплексе з ps, lsof і лагамі.

Папулярныя памылкі пры працы з htop

• Спыняць толькі верхні працэс, не аналізуючы прычыну
• Блытаць VIRT з рэальным расходам RAM
• Лічыць RAM MySQL для cache як праблему
• Адразу выкарыстоўваць kill -9
• Абвінавачваць праграмы або карыстальнікаў без лагаў
• Інтэрпрэтаваць load average без уліку ядраў
• Не правяраць цэласнасць файлаў пры інцыдэнце бяспекі

Пазбягаючы гэтых памылак, вы скарачаеце час прастою і рызыку страты дадзеных. У сістэмным адміністраванні дакладная дыягностыка важней за хуткасць рэакцыі.

Частыя пытанні

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

htop паказвае рэальнае выкарыстанне CPU, RAM, карыстальніка, PID і каманды для кожнага працэсу. Дзякуючы гэтаму можна аператыўна знаходзіць скрыпты, што «жруць» рэсурсы.

Як знайсці скрыпт, што перазагружае CPU праз htop?

Сартаваць працэсы па CPU%, запісаць PID і USER, затым праз ps -fp PID і lsof -p PID даведацца шлях да файла і каманду.

Для RAM MEM% ці VIRT — што ўлічваць?

MEM% і асабліва RES — паказваюць рэальны расход RAM. VIRT — гэта віртуальная памяць, не заўсёды фізічная RAM.

Ці можна адразу спыняць праблемны працэс праз kill -9?

Лепш спачатку дакументаваць працэс, праверыць файл, паспрабаваць стандартны kill PID. kill -9 — толькі калі ўсё астатняе не працуе і сервер «завісае».

Высокі CPU у htop — заўсёды прыкмета атакі?

Не. Backup, імпарт, cache, трафік могуць даваць нагрузку. Але выпадковыя імёны, працэсы з /tmp або uploads і нечаканыя карыстальнікі — падстава для бяспекі.

Сумуючы: htop — хуткі і эфектыўны старт для пошуку скрыптаў, што «жруць» CPU і RAM на Linux-серверы. Для дакладнага дыягназу камбінуецца з аналізам PID, lsof, cron і лагамі. Калі праблемы з рэсурсамі паўтараюцца — ацэньвайце як праграму, так і сервер; пры неабходнасці параўнайце рашэнні Hostragons для хостынгу, VPS і SSL без навязвання, каб выбраць лепшую платформу для вашага праекта.