Намиране на скриптове, които използват CPU и RAM на Linux сървър с помощта на командата htop

Командата htop на Linux сървър е един от най-практичните инструменти за мониторинг, използвани за идентифициране на скриптове, които прекомерно консумират CPU и RAM в реално време. С помощта на екрана на htop можете да видите кои PHP, Python, Node.js, cron, бази данни или системни процеси натоварват сървъра, като прегледате колоните CPU%, MEM%, PID, USER, TIME+ и COMMAND; след това можете безопасно да интервенцирате, проверявайки собственика на процеса, пътя на файла и целта на изпълнението.

Независимо дали става въпрос за споделен хостинг, VPS, VDS или dedicated сървър, значителна част от внезапните забавяния произтичат от неконтролирано работещи скриптове. Например, дефектен WordPress плъгин, PHP файл, който влиза в безкраен цикъл, интензивно работеща cron задача, неоптимизирана SQL заявка или компрометирано уеб приложение могат да увеличат употребата на CPU до почти 100% за минути. Когато консумацията на RAM нараства, услугите могат да се забавят, MySQL връзките могат да паднат, уеб сайтовете могат да върнат 503 грешка или Linux ядрото да приключи някои процеси с OOM Killer.

В това ръководство ще разгледаме стъпка по стъпка как да инсталираме htop, как да прочетем екрана, как да идентифицираме скриптове, които изразходват CPU и RAM, как да намерим пътя на файла чрез PID и как безопасно да интервенцираме в процеса. Освен това ще обсъдим съмнения за сигурност, проверка на cron, анализ на логове и приложими оптимизационни предложения, за да предотвратим повторение на проблема. Ако често имате проблеми с лимитите на ресурсите на вашия сървър, можете да прегледате страниците за VPS сървърни пакети и Уеб хостинг с висока производителност, за да преразгледате избора на инфраструктура.

Какво е htop и защо е по-полезно от командата top?

htop е терминален инструмент, който позволява интерактивно наблюдение на работещите процеси в Linux системи. Подобно на класическата команда top, htop предлага по-четим интерфейс, цветни индикатори за ресурси, лесно сортиране, търсене, филтриране и управление на процеси. По тази причина, особено при бърза диагностика на активен сървър, htop е един от първите инструменти, на които системните администратори се спират.

С htop можете да видите следната информация в реално време:

• Процент на CPU, използван от всеки процес
• Процент на RAM, използван от всеки процес, и количеството памет
• PID номер на процеса
• Потребителят, който изпълнява процеса
• Команден ред или име на скрипта
• Време на работа и стойност на приоритета
• Load average, обща RAM, swap и използване на CPU ядра

Когато същевременно в хостинг среда работят множество сайтове, потребители или услуги, просто виждането на общото потребление на ресурси не е достатъчно. Необходимо е да се установи на кой потребител, кой уебсайт, коя cron задача или кой скрипт принадлежи проблемът. Командата htop на Linux сървър предоставя бърза първоначална диагностика в този контекст.

Инсталиране на htop: Команди в зависимост от дистрибуцията

В много съвременни Linux дистрибуции 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 не винаги е проблем. Например, по време на архивиране, визуална оптимизация, изчистване на кеш или интензивен трафик CPU може временно да нарасне. Проблемът е, когато същият процес показва високи нива на CPU или RAM за минути, load average значението е значително над броя на ядрата и уеб услугите не могат да отговорят.

Намиране на скриптове, които използват CPU с htop

За да намерите скриптове, които прекомерно използват CPU, докато htop е отворен, можете да натиснете F6, за да изберете полето за сортиране, или да сортирате по колоната CPU%. В някои терминали, ако е активна поддръжка на мишка, просто щракването върху заглавието CPU% също е достатъчно. Процесите, които виждате най-горе, са тези, които в момента използват най-много CPU.

Стъпка 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/kullanici/public_html/index.php, може да става въпрос за уеб искане, генерирано от трафик. Ако изглежда като php /home/kullanici/public_html/wp-content/plugins/bilinmeyen-eklenti/task.php, проблемът може да е свързан с плъгин.

Стъпка 4: Проверете пътя на файла и отворените файлове

Инструментът lsof е много полезен за виждане на файловете, които използва един процес:

lsof -p PID

Тази команда показва отворените файлове, библиотеки, лог файлове и мрежови връзки на процеса. В уеб хостинг среда, благодарение на този изход, можете да разберете кой сайт директория е активна. Например, ако видите PHP файл с странно име в /home/example/public_html/wp-content/uploads, това може да е признак за нарушение на сигурността. В такава ситуация просто приключването на процеса не е достатъчно; трябва да се извършат и почистване на файлове, смяна на пароли, обновяване на плъгини и проверка за сигурност. Страницата за решения за SSL сертификати също може да бъде прегледана за конфигурации на SSL и сигурни връзки.

Намиране на скриптове, които използват RAM с htop

Проблемите с RAM могат да се развиват по-тайно от проблемите с CPU. Когато CPU се повиши, обикновено се усеща моментно забавяне; когато RAM изчерпва, услугите могат да се затворят неочаквано, swap може да се използва интензивно и закъснението в сървъра нараства. Можете да сортирате по колоната MEM% на екрана на htop, за да изброите процесите, които използват най-много памет.

Разбиране на връзката между MEM%, RES и Swap

htop по подразбиране показва процента MEM%. В някои конфигурации могат да се видят и колоните VIRT, RES и SHR. При анализ на RAM, стойността RES е особено важна, защото отразява действителната площ, която процесът заема в физическата памет. Стойността VIRT не винаги означава реална консумация на RAM и може да бъде подвеждаща сама по себе си.

Например, на VPS с 4 GB RAM, ако един единствен PHP процес използва 900 MB RES, това не е нормално. По подобен начин, ако приложението на Node.js с времето се увеличи от 200 MB до 1.5 GB, това предполага риск от изтичане на памет. Високото използване на RAM от MySQL или MariaDB може понякога да е нормално поведение на кеша; в този случай производителността на заявките, настройките на буфера и общата памет на системата трябва да се оценят заедно.

Типични причини за RAM консумиращи скриптове

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

В такива случаи затварянето на процеса само с командата kill предоставя временно облекчение. За постоянен резултат трябва да се анализира какво прави скриптът, с какви входове е задействан и защо не освобождава памет.

Търсене, филтриране и дървесен изглед в htop

Ако на сървъра работят стотици процеси, е трудно да се прави ръчно търсене в списъка. htop предлага полезни комбинации от клавиши за тази цел. Можете да търсите с F3, да прилагате филтри с F4 и да превключите на дървесен изглед с F5. Дървесният изглед е особено важен за визуализиране на отношенията род-дете. Например, можете да видите по-ясно child процесите на php-fpm, работещи под nginx или Apache, скриптовете, задействани от cron, или Node.js услугите, управлявани от supervisor.

Практически примери за филтриране

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

Тези филтри спестяват време, особено на много потребителски сървъри. Например, ако на същия сървър хоствате 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, и логът на PHP-FPM за бавни заявки предоставят важни улики.

3. Опитайте първо нежен терминал

Ако процесът е действително неконтролируем, изпратете стандартен сигнал за прекратяване:

kill PID

Изчакайте няколко секунди и проверете в htop дали процесът се е затворил. Ако не затвори и сериозно нарушава здравето на системата, може да се използва следната команда като последна инстанция:

kill -9 PID

Сигналът kill -9 прекратява процеса, без да му позволява да направи почистване. Поради това трябва да се използва внимателно за операции с бази данни, процеси на записване на файлове или задачи за архивиране.

4. Ако се рестартира, намерете задействането

Ако процесът се рестартира в рамките на секунди след затварянето, зад него може да стои cron, systemd service, supervisor, уеб искане или бот трафик. За записите на cron проверете crontab -l, за системните услуги използвайте systemctl status service_name, а за уеб трафика проверете логовете за достъп. Ако проблемът е свързан с WordPress wp-cron, настройките на реалния cron и политиката на кеширане трябва да се преразгледат.

Комбиниране на находките от htop с логовете

htop ви показва какво консумира ресурси; логовете ви помагат да разберете защо. Когато тези две данни не се използват заедно, диагнозата остава непълна. Например, процесът php-fpm в htop може да използва 180% CPU; обаче, без логовете за достъп, може да не видите кой URL или бот задейства този процес.

Примери за логове, които можете да проверите, включват:

• Лог на уеб сървъра за достъп: показва URL адресите, които получават интензивни заявки.
• Лог на уеб сървъра за грешки: показва PHP грешки, права на файлове и 500 грешки.
• Лог на PHP-FPM за бавни заявки: показва бавно работещи PHP файлове и функции.
• Лог на MySQL за бавни заявки: идентифицира тежки SQL заявки.
• Лог за удостоверяване или защитен лог: показва съмнителни опити за вход.
• Лог на cron: показва кога са изпълнени планираните задачи.

Например, ако PID с висока CPU консумация в htop получава хиляди заявки за /wp-admin/admin-ajax.php в същата минута, проблемът може да е свързан с плъгин, бот трафик или лошо проектиран AJAX процес. В този случай трябва да се обмислят WAF, rate limit, кеширане и оптимизация на плъгини. За по-широк подход към производителността на уеб сайта, Оптимизация на скоростта на уебсайт може да бъде полезна.

Как да различим нормалното натоварване от проблемното натоварване?

Не всяко високо потребление на ресурси означава криза. Хардуерът на сървъра, нивото на трафика, типът на приложението и поддръжката трябва да бъдат взети под внимание. За VPS с 2 ядра, ако стойността на load average остава дълго време между 6-8, това е сериозен bottleneck. В dedicated сървър с 16 ядра, същата стойност може да е нормална. Затова при интерпретиране на load average е важно да се знае броят на ядрата.

Тази сравнителна таблица помага да се отдели ненужната паника от истинската производствена криза. Особено в сайтовете за електронна търговия, периодите на кампании, интеграции на плащания и актуализации на наличности могат да причинят временно увеличение на ресурсите. Но ако това увеличение нарушава потребителското изживяване, оптимизацията на приложението и капацитета на сървъра трябва да се оценят заедно.

Съмнение за сигурност: Може ли скриптът, който консумира ресурси, да е вреден?

Скрипт, който консумира CPU или RAM, не винаги е невинна грешка. На компрометирани уебсайтове нападателите могат да стартират спам, крипто копаене, прокси трафик, DDoS ботове или скриптове за заден вход. Ненормални команди, работещи под неочаквани потребители, произволно именувани файлове, бинарни файлове, работещи от /tmp директорията, или PHP файлове в public_html/uploads трябва да се разглеждат сериозно от гледна точка на сигурността.

Съмнителни признаци

• Имената на файловете в полето COMMAND с безсмислени или произволни символи
• Файлове, работещи от директории /tmp, /dev/shm или uploads
• Процеси с perl, python или bash, които обикновено не би трябвало да съществуват
• Процеси, които създават голямо количество външни мрежови връзки
• Същият потребител стартира много процеси за кратък период
• Наскоро направени неразрешени промени в уеб файловете

В такава ситуация, преди да затворите процеса, е препоръчително да вземете изходите на командите като доказателство. След това проверете правата на файловете, изолирайте вредните файлове, сменете паролите на всички панели и CMS, обновете основните файлове на плъгините и темите и извършете проверка за сигурност. Освен това, използването на двуфакторна автентикация в административните панели и премахването на ненужни разрешения за запис дългосрочно намалява риска.

Най-добри практики за предотвратяване на повторение на проблеми с производителността

Намирането на проблема с htop е важно, но истинската стойност е в предотвратяването на повтарянето на същия проблем. Следните мерки значително намаляват прекъсванията, причинени от CPU и RAM на Linux сървъри.

• Настройте стойностите на PHP memory_limit, max_execution_time и pm.max_children в съответствие с капацитета на сървъра.
• Използвайте механизъм за кеширане в WordPress, Joomla или специализирани софтуерни приложения.
• Премахнете ненужни плъгини, теми и модули.
• Оптимизирайте тежките заявки с MySQL slow query log.
• Не натрупвайте cron задачи в същата минута; изпълнявайте ги на интервали.
• Прилагайте rate limit, robots.txt и правила за защитна стена за бот трафик.
• Редовно ротация на логовете; следете влиянието на огромните лог файлове върху диска и RAM.
• Следете сървърните метрики не само по време на криза, но и редовно.

Ако, въпреки оптимизациите, потреблението на ресурси остава постоянно високо, проблемът може да не е само в софтуера. Трафикът е нараснал, приложението е нараснало или текущият хостинг пакет не е достатъчен. В такъв случай, скалируем VPS, повече RAM, по-бърз NVMe диск или изолиран ресурсен сървър стават разумен избор. За анализ на нуждите можете да сравните опции за Хостинг пакети и корпоративни решения за сървъри.

Примерен сценарий: Пикове на CPU в WordPress сайт

Нека да разгледаме един реалистичен сценарий. На VPS с 4 ядра и 8 GB RAM работят няколко WordPress сайта. Потребителите съобщават, че сайтът е бавен и понякога получават 502 грешка. Когато отворите htop в терминала, load average е на ниво 12, всички CPU ядра са заети и на върха виждате множество php-fpm процеси, свързани с един и същ потребител.

С F4 филтрирате по потребителско име. Записвате PID на процеса, който използва CPU. В изхода на ps -fp PID се показва php-fpm worker; с lsof -p PID се установява достъп до файла /home/site/public_html/wp-content/plugins/example-importer/import.php. При преглед на логовете за достъп, в същите минути се виждат искания от администратор, задействащи този файл, и след това повтарящи се AJAX повиквания.

Като решение, процесът на импортиране се спира, планираната задача на плъгина се деактивира, голямото количество данни за импортиране се разделя на по-малки части и лимитът на PHP max_execution_time се преразглежда. Освен това, вместо wp-cron, се използва системният cron. В резултат, load average спада от 12 до 1.8, потреблението на CPU се нормализира, а времето за отговор на уеб сайта значително се подобрява. Този пример показва, че htop е ефективен не само самостоятелно; когато е комбиниран с ps, lsof и анализ на логове, той е изключително полезен.

Често срещани грешки при използването на htop

• Да затворите само най-горния процес, без да проучите основната причина.
• Да смятате стойността VIRT за реална употреба на RAM.
• Да приемате директно RAM употребата на MySQL за проблем.
• Да използвате kill -9 като първи вариант.
• Да обвинявате приложението или потребителя без проверка на логовете.
• Да интерпретирате стойността на load average независимо от броя на CPU ядрата.
• Да не проверявате целостта на файловете при съмнение за нарушение на сигурността.

Избягването на тези грешки не само намалява времето за прекъсване, но и намалява риска от загуба на данни поради неправилна интервенция. Правилната диагностика в системното управление често е по-ценна от бързата намеса.

Често задавани въпроси

Каква е употребата на командата htop на Linux сървър?

Командата htop на Linux сървър показва информация за работещите процеси, включително CPU, RAM, потребител, PID и командни данни в реално време. По този начин можете бързо да идентифицирате скриптове, които прекомерно консумират CPU или памет.

Как да намеря скрипта, който използва CPU с htop?

Сортирайте процесите в htop по колоната CPU%, запишете PID и USER на дългосрочния процес. След това потвърдете пътя на файла и какво изпълнява с командите ps -fp PID и lsof -p PID.

Кой е по-значим при анализ на RAM: MEM% или VIRT?

При анализа на RAM по-значими са MEM% и особено стойността RES. VIRT показва количеството резервирана виртуална памет и не винаги означава физическа консумация на RAM.

Правилно ли е да затворя ресурсоемкия процес веднага с kill -9?

Обикновено не. Първо е по-безопасно да документирате какво представлява процесът, да проверите пътя на файла и да опитате стандартния kill PID. kill -9 трябва да се използва само в краен случай, когато процесът е неподвижен и сериозно нарушава здравето на сървъра.

Високото потребление на CPU в htop винаги ли е признак за атака?

Не. Архивирането, импортирането, създаването на кеш или интензивния трафик също могат да увеличат потреблението на CPU. Въпреки това, ненормалните имена на файлове, файлове, работещи от /tmp или uploads, и процеси под неочаквани потребители предизвикват съмнение за сигурност.

В заключение, командата htop на Linux сървър е бърза, практична и ефективна отправна точка за намиране на скриптове, които консумират CPU и RAM. За най-точни резултати е необходимо да комбинирате данните от htop с анализа на PID, изхода на lsof, проверка на cron и преглед на логове. Ако проблемите с ресурсите често се повтарят на вашия сървър, оценете както софтуерната оптимизация, така и капацитета на инфраструктурата; при нужда можете да сравните решенията за хостинг, VPS и SSL на Hostragons без натиск за продажба, за да изберете най-подходящата структура за вашия проект.