Jak znaleźć skrypty obciążające CPU i RAM na serwerze Linux za pomocą komendy "htop"

Na serwerze Linux komenda htop to jedno z najpraktyczniejszych narzędzi do monitorowania w czasie rzeczywistym, które pozwala zidentyfikować skrypty nadmiernie zużywające procesor i pamięć RAM. Analizując kolumny CPU%, MEM%, PID, USER, TIME+ oraz COMMAND możesz szybko zorientować się, który proces PHP, Python, Node.js, cron, baza danych lub inny systemowy obciąża serwer. Następnie, sprawdzając właściciela procesu, ścieżkę pliku i jego przeznaczenie, możesz bezpiecznie podjąć odpowiednie działania.

Niezależnie od tego, czy korzystasz z hostingu współdzielonego, VPS, VDS czy serwera dedykowanego, nagłe spowolnienia często są efektem niekontrolowanych skryptów. Przykładowo, błędna wtyczka WordPressa, skrypt PHP wpadający w nieskończoną pętlę, intensywnie działające zadanie cron, nieoptymalne zapytanie do bazy danych czy zainfekowany plik na stronie może w ciągu kilku minut podnieść zużycie CPU nawet do 100%. Wzrost zużycia RAM może natomiast powodować zawieszanie usług, rozłączanie połączeń MySQL, błędy 503 na stronach lub aktywację mechanizmu OOM Killer w jądrze Linux, który eliminuje wybrane procesy.

W tym przewodniku krok po kroku omówimy instalację htop, interpretację ekranu, jak rozpoznać skrypty wyczerpujące CPU i RAM, jak odnaleźć ścieżkę pliku na podstawie PID oraz jak bezpiecznie reagować na takie procesy. Dodatkowo podpowiemy, jak zweryfikować podejrzenia o naruszenie bezpieczeństwa, kontrolować zadania cron, analizować logi i wdrożyć optymalizacje zapobiegające powtórzeniu problemów. Jeśli na Twoim serwerze często pojawiają się problemy z limitami zasobów, warto też rozważyć wybór odpowiedniej infrastruktury – zajrzyj do Pakiety serwerów VPS oraz Hostowanie stron internetowych o wysokiej wydajności.

Co to jest htop i dlaczego jest lepszy niż polecenie top?

htop to interaktywne narzędzie terminalowe do monitorowania procesów działających na systemach Linux. Jest podobne do klasycznego top, ale wyróżnia się bardziej czytelnym interfejsem, kolorowymi wskaźnikami zużycia zasobów, łatwą możliwością sortowania, wyszukiwania, filtrowania oraz zarządzania procesami. Dzięki temu htop jest pierwszym wyborem wielu administratorów przy szybkiej diagnostyce serwera na żywo.

Dzięki htop możesz na bieżąco zobaczyć między innymi:

• Procentowe użycie CPU przez każdy proces
• Procentowe i ilościowe zużycie pamięci RAM
• Numer PID procesu
• Użytkownika, który uruchomił proces
• Nazwę polecenia lub skryptu
• Czas działania oraz priorytet procesu
• Wartości load average, całkowitą pamięć RAM, swap oraz wykorzystanie rdzeni CPU

Szczególnie na serwerach hostingowych, gdzie działa wiele stron, użytkowników i usług, samo monitorowanie łącznego zużycia zasobów to za mało. Trzeba ustalić, który użytkownik, witryna, zadanie cron lub skrypt jest źródłem problemu. Komenda htop jest tutaj niezastąpionym narzędziem do szybkiej wstępnej diagnozy.

Instalacja htop: polecenia dla różnych dystrybucji

W wielu nowoczesnych dystrybucjach Linux htop nie jest preinstalowany, ale jeśli masz uprawnienia root lub sudo, instalacja zajmie kilka sekund. Przed instalacją warto odświeżyć listę pakietów, co zmniejsza ryzyko błędów, zwłaszcza na świeżo skonfigurowanym serwerze.

Instalacja htop na Ubuntu i Debianie

Na serwerach opartych o Ubuntu lub Debian użyj komend:

sudo apt update

sudo apt install htop -y

Po instalacji wystarczy wpisać htop, aby uruchomić narzędzie. Jeśli nie masz uprawnień sudo, skontaktuj się z dostawcą hostingu. Na zarządzalnym VPS masz zwykle pełny dostęp root.

Instalacja na AlmaLinux, Rocky Linux, CentOS i RHEL

W systemach bazujących na RHEL menadżer pakietów to dnf lub yum, zależnie od wersji:

sudo dnf install htop -y

W starszych wersjach CentOS może być konieczne wcześniejsze włączenie repozytorium EPEL:

sudo yum install epel-release -y

sudo yum install htop -y

Po instalacji wpisanie htop otworzy kolorowy ekran monitoringu. Jeśli dopiero zaczynasz z administracją serwerem, podstawowe komendy Linux znajdziesz w poradnik komend Linux.

Jak czytać ekran htop? Co oznaczają poszczególne kolumny?

Po uruchomieniu htop u góry widoczny jest podział na rdzenie CPU, wykorzystanie RAM, swap, liczba zadań i wątków, load average oraz uptime systemu. Poniżej pojawia się lista aktywnych procesów. Najważniejsze kolumny pomocne w diagnozie to:

Warto pamiętać, że krótkotrwały wzrost CPU nie zawsze oznacza problem – może to być np. backup, optymalizacja obrazów, czyszczenie cache lub nagły wzrost ruchu. Problem pojawia się, gdy proces przez wiele minut zużywa dużo CPU lub RAM, load average przekracza znacznie liczbę rdzeni, a serwisy przestają odpowiadać.

Jak znaleźć skrypty obciążające CPU za pomocą htop?

W htop możesz posortować procesy według zużycia CPU naciskając klawisz F6 i wybierając odpowiednią kolumnę lub klikając nagłówek kolumny CPU%, jeśli Twój terminal obsługuje myszkę. Procesy na górze listy to te, które w danym momencie najbardziej obciążają procesor.

Krok 1: Sortuj procesy według CPU%

Podczas działania htop uporządkuj procesy według zużycia CPU. Jeśli na szczycie są stale procesy jak php-fpm, php, python3, node, java, mysqld lub bash, zanotuj je. Na maszynach wielordzeniowych pojedynczy proces może wykazywać wartości procentowe przekraczające 100%, bo używa kilku rdzeni jednocześnie.

Krok 2: Zanotuj PID i USER

Zapisz numer PID i użytkownika podejrzanego procesu. Przykładowo, jeśli PID to 24819, USER to siteuser, a w polu COMMAND widzisz php /home/siteuser/public_html/wp-cron.php, problem prawdopodobnie wiąże się z mechanizmem cron lub WordPressem na tej stronie. Jeśli pole COMMAND jest zbyt krótkie, możesz włączyć wyświetlanie pełnej linii polecenia w ustawieniach htop lub użyć komendy ps, aby uzyskać szczegóły.

Krok 3: Sprawdź pełne polecenie procesu

Aby zobaczyć szczegółową linię poleceń dla danego PID, użyj:

ps -fp PID

Przykład:

ps -fp 24819

Ta komenda pokaże, z którego pliku skrypt jest uruchamiany. Jeśli jest to np. php /home/użytkownik/public_html/index.php, to może być zwykłe żądanie HTTP. Jeśli jednak to php /home/użytkownik/public_html/wp-content/plugins/nieznana-wtyczka/task.php, problem może leżeć w wadliwej wtyczce.

Krok 4: Sprawdź otwarte pliki i połączenia

Do sprawdzenia, jakie pliki i zasoby używa proces, idealne jest narzędzie lsof:

lsof -p PID

Wyświetli ono wszystkie otwarte pliki, biblioteki, logi i połączenia sieciowe. W środowisku hostingowym pozwala to ustalić, która witryna jest aktywna pod danym procesem. Jeśli zauważysz podejrzane pliki w katalogach takich jak /home/example/public_html/wp-content/uploads, może to świadczyć o naruszeniu bezpieczeństwa. W takim przypadku samo zakończenie procesu to za mało – należy oczyścić pliki, zmienić hasła, zaktualizować wtyczki i przeprowadzić skan bezpieczeństwa. Warto też zapoznać się z Rozwiązania certyfikatów SSL, by wzmocnić ochronę połączeń.

Jak znaleźć skrypty wyczerpujące pamięć RAM za pomocą htop?

Problemy z RAM są często bardziej podstępne niż te z CPU. Wzrost CPU zwykle powoduje odczuwalne spowolnienia, ale gdy pamięć się kończy, usługi mogą niespodziewanie się zamykać, swap jest intensywnie używany, a ogólna wydajność systemu spada. W htop możesz posortować procesy według kolumny MEM%, aby wyświetlić najbardziej pamięciożerne.

Jak interpretować MEM%, RES i swap?

htop standardowo pokazuje MEM%, czyli procent pamięci RAM zajętej przez proces. Dodatkowo można zobaczyć kolumny VIRT, RES i SHR. Szczególnie ważna jest wartość RES, która obrazuje faktyczne zużycie fizycznej pamięci. VIRT to pamięć wirtualna, która nie zawsze odpowiada rzeczywistej pamięci RAM, więc nie należy jej mylić z realnym zużyciem.

Przykładowo, na VPS z 4 GB RAM pojedynczy proces PHP używający 900 MB RES to już sygnał ostrzegawczy. Podobnie, jeśli aplikacja Node.js rośnie z 200 MB do 1,5 GB RAM, może to wskazywać na wyciek pamięci. W przypadku MySQL lub MariaDB wysokie zużycie RAM może być normalne, jeśli jest to cache – wtedy należy ocenić konfigurację buforów i całkowitą dostępność pamięci.

Typowe przyczyny wysokiego zużycia RAM przez skrypty

• Nieskończone pętle w kodach PHP, Python lub Node.js
• Ładowanie dużych plików CSV, XML lub JSON do pamięci za jednym razem
• Nieoptymalne wtyczki i funkcje motywów WordPressa
• Przetwarzanie obrazów, generowanie PDF lub konwersja wideo
• Brak cache powodujący powtarzające się ciężkie zapytania
• Duża ilość uruchomionych instancji tego samego skryptu spowodowana botami lub atakami
• Długotrwałe procesy z wyciekami pamięci

W takich przypadkach samo zabicie procesu komendą kill przynosi tylko chwilową ulgę. Trzeba zidentyfikować, co dokładnie skrypt robi, jakie ma wejścia i dlaczego nie zwalnia pamięci.

Wyszukiwanie, filtrowanie i widok drzewa w htop

Gdy na serwerze działa setki procesów, ręczne przeszukiwanie listy staje się kłopotliwe. htop oferuje wygodne skróty klawiszowe: F3 do wyszukiwania, F4 do filtrowania, F5 do przełączania widoku drzewa procesów. Widok drzewa jest szczególnie przydatny do zobaczenia zależności między procesami rodzic – dziecko, np. procesy php-fpm uruchomione przez nginx lub apache, skrypty wywoływane przez cron czy usługi Node.js zarządzane przez supervisor.

Przykładowe filtry

• Wpisz php, aby wyświetlić tylko procesy PHP
• python, aby wyłuskać skrypty Python
• wp-cron do kontroli zadań cron WordPressa
• node do sprawdzenia aplikacji Node.js
• filtruj według nazwy użytkownika, by zobaczyć procesy jednego konta hostingowego

Filtry znacznie przyspieszają diagnozę na serwerach z wieloma użytkownikami i stronami. Jeśli chcesz uprościć zarządzanie projektami domenowymi, zajrzyj do Sprawdzanie domen i rejestracja.

Bezpieczny plan działania wobec podejrzanego PID

Znajdując proces pożerający zasoby, łatwo jest od razu użyć kill -9, ale takie działanie może powodować utratę danych, przerwanie zapisu lub niestabilność usług. Lepiej podejść do sprawy etapami.

1. Dokumentuj proces

Zapisz PID, USER, COMMAND, CPU%, MEM% i czas działania. Jeśli możesz, zrób zrzut ekranu htop. To ułatwi porównania, a także uwiarygodni raporty techniczne, np. dla klientów agencji czy sklepów internetowych.

2. Zweryfikuj ścieżkę pliku

Użyj komend:

ps -fp PID

lsof -p PID

Sprawdź, czy plik znajduje się w katalogu strony i przejrzyj jej logi – wp-content/debug.log dla WordPressa, logi dostępu i błędów serwera WWW, PHP-FPM slow log. To może dać wskazówki co do przyczyny.

3. Najpierw spróbuj łagodnego zakończenia

Wyślij standardowy sygnał zakończenia:

kill PID

Poczekaj kilka sekund i sprawdź, czy proces zniknął z htop. Jeśli nie, a sytuacja jest krytyczna, wtedy dopiero użyj:

kill -9 PID

Ten ostatni sygnał zamyka proces natychmiast, nie dając mu szansy na posprzątanie, więc należy go stosować ostrożnie.

4. Znajdź źródło ponownego uruchamiania procesu

Jeśli proces wstaje zaraz po zabiciu, może go wywoływać cron, usługa systemowa systemd, supervisor, żądanie webowe lub bot. Sprawdź:

crontab -l

systemctl status nazwa_usługi

logi dostępu serwera www

Jeżeli problemem jest wp-cron w WordPressie, rozważ przejście na systemowy cron i optymalizację cache.

Łączenie wyników htop z analizą logów

htop pokaże, co zużywa zasoby, ale logi wyjaśnią, dlaczego. Bez połączenia tych danych diagnoza jest niepełna. Przykładowo, jeśli w htop php-fpm zużywa 180% CPU, to bez logów nie dowiesz się, które URL-e lub boty wywołują ten proces.

Sprawdź następujące logi:

• Logi dostępu serwera WWW – pokazują obciążające URL-e
• Logi błędów serwera – ujawniają błędy PHP, problemy z uprawnieniami i błędy 500
• PHP-FPM slow log – identyfikuje wolno działające skrypty i funkcje
• MySQL slow query log – pozwala zoptymalizować ciężkie zapytania SQL
• Logi uwierzytelniania – wykrywają podejrzane próby logowania
• Logi zadań cron – informują o czasie uruchomienia zadań

Jeśli w htop widzisz PID z wysokim zużyciem CPU, a w tym samym czasie access log pokazuje tysiące wywołań adresu /wp-admin/admin-ajax.php, może to być problem z wtyczką, botem lub źle zoptymalizowanym AJAX-em. W takim przypadku warto rozważyć zastosowanie WAF, ograniczeń liczby zapytań, cache i optymalizacji wtyczek. Szersze wskazówki znajdziesz w Optymalizacja prędkości strony internetowej.

Jak odróżnić normalne obciążenie od problematycznego?

Wysokie wykorzystanie zasobów nie zawsze oznacza kryzys. Trzeba uwzględnić sprzęt, natężenie ruchu, typ aplikacji i prace serwisowe. Na przykład load average 6-8 na serwerze z dwoma rdzeniami to poważny problem, ale na dedykowanym serwerze z 16 rdzeniami taki poziom może być normalny. Dlatego przy interpretacji load average zawsze trzeba znać liczbę rdzeni.

Takie porównanie pozwala odróżnić fałszywą panikę od realnego problemu. W sklepach internetowych okresy promocji czy aktualizacje mogą chwilowo zwiększać obciążenie, ale jeśli wpływa to na komfort użytkownika, trzeba działać w zakresie optymalizacji i skalowania serwera.

Czy skrypty obciążające zasoby mogą być złośliwe?

Wysokie zużycie CPU lub RAM nie zawsze wynika z błędów – może być objawem infekcji. Atakujący na przejętych stronach mogą uruchamiać spam, koparki kryptowalut, boty DDoS, proxy lub tylne drzwi. W htop warto zwrócić uwagę na procesy z nietypowymi nazwami, działające pod dziwnymi użytkownikami, z katalogów /tmp, /dev/shm lub uploadów, a także na niespodziewane procesy perl, python czy bash. Wysokie połączenia sieciowe i szybkie tworzenie procesów pod jednym użytkownikiem też budzą niepokój.

Oznaki podejrzanej aktywności

• COMMAND z losowymi lub niezrozumiałymi nazwami plików
• Procesy uruchamiane z katalogów tymczasowych lub uploadów
• Nieoczekiwane procesy perl, python, bash
• Procesy generujące duży ruch zewnętrzny
• Duża liczba procesów od jednego użytkownika w krótkim czasie
• Niedawne, nieautoryzowane zmiany w plikach webowych

W takim przypadku najpierw zbierz dowody – wyeksportuj informacje o procesach. Sprawdź uprawnienia plików, wyizoluj zainfekowane pliki, zmień wszystkie hasła do paneli i CMS-ów, zaktualizuj wtyczki, motywy i rdzeń, przeprowadź pełne skanowanie bezpieczeństwa. Długoterminowo stosuj dwuskładnikowe uwierzytelnianie i ogranicz prawa zapisu tam, gdzie to możliwe.

Najlepsze praktyki, by zapobiegać powtarzającym się problemom z wydajnością

Znajdowanie przyczyny htopem to dopiero początek – prawdziwą wartością jest zapobieganie powtórkom. Oto rekomendacje, które znacząco zmniejszą ryzyko awarii związanych z CPU i RAM:

• Dopasuj parametry PHP memory_limit, max_execution_time i pm.max_children do możliwości serwera
• Wykorzystuj systemy cache w WordPressie, Joomla i innych aplikacjach
• Usuń niepotrzebne wtyczki, motywy i moduły
• Optymalizuj wolne zapytania dzięki MySQL slow query log
• Nie uruchamiaj wielu zadań cron w tym samym czasie – rozłóż je w czasie
• Stosuj ograniczenia ruchu botów, reguły robots.txt i firewall
• Zadbaj o rotację logów, aby nie zajmowały zbyt dużo miejsca na dysku i w pamięci
• Monitoruj metryki serwera regularnie, nie tylko w kryzysowych momentach

Jeśli problemy nadal się powtarzają, przyczyna może leżeć poza samym oprogramowaniem. Może ruch wzrósł, aplikacja się rozrosła lub obecny plan hostingowy jest za słaby. Wtedy warto rozważyć skalowalny VPS, więcej RAM, szybki dysk NVMe lub serwer z dedykowanymi zasobami. Porównaj dostępne opcje na Pakiety hostingu i rozwiązania serwerowe dla firm.

Przykładowy scenariusz: nagły wzrost obciążenia CPU na stronie WordPress

Wyobraźmy sobie VPS z 4 rdzeniami i 8 GB RAM, na którym działa kilka stron WordPress. Użytkownicy zgłaszają spowolnienia i sporadyczne błędy 502. Otwierając htop widzimy load average na poziomie 12, wszystkie rdzenie zajęte, a na liście procesów wiele php-fpm pod tym samym użytkownikiem.

Filtrujemy listę wg użytkownika (F4), notujemy PID najbardziej obciążających procesów. Komenda ps -fp PID pokazuje, że to worker php-fpm, a lsof -p PID wskazuje plik /home/site/public_html/wp-content/plugins/example-importer/import.php. Analiza logów dostępu ujawnia, że w tych samych chwilach wywoływane są zapytania administratora i powtarzające się AJAX-y.

W efekcie zatrzymujemy import, wyłączamy zaplanowane zadania w wtyczce, dzielimy duże importy na mniejsze części i zwiększamy limit max_execution_time w PHP. Dodatkowo zastępujemy wp-cron standardowym crontabem. Po tych działaniach load average spada do 1,8, zużycie CPU wraca do normy, a strony działają płynniej. Ten przykład pokazuje, jak skutecznie wykorzystać htop wraz z ps, lsof i analizą logów.

Najczęstsze błędy przy korzystaniu z htop

• Zamknięcie tylko najwyżej pozycjonowanego procesu bez sprawdzenia przyczyny
• Mylenie wartości VIRT z rzeczywistym zużyciem RAM
• Bezrefleksyjne traktowanie pamięci cache MySQL jako problemu
• Używanie kill -9 jako pierwszej metody zakończenia procesu
• Obwinianie aplikacji lub użytkownika bez analizy logów
• Interpretowanie load average bez uwzględnienia liczby rdzeni
• Ignorowanie podejrzeń o naruszenie bezpieczeństwa i brak weryfikacji integralności plików

Unikanie tych błędów pozwoli ograniczyć czas przestojów i ryzyko utraty danych. W administracji serwerem trafna diagnoza często jest ważniejsza niż szybka reakcja.

Najczęściej zadawane pytania

Do czego służy komenda htop na serwerze Linux?

htop wyświetla w czasie rzeczywistym informacje o procesach, takie jak zużycie CPU, RAM, użytkownik, PID i polecenie. Umożliwia szybkie zlokalizowanie skryptów nadmiernie obciążających serwer.

Jak za pomocą htop znaleźć skrypt zużywający dużo CPU?

W htop posortuj procesy według kolumny CPU%, zanotuj PID i użytkownika najbardziej obciążających procesów. Następnie użyj ps -fp PID i lsof -p PID, aby sprawdzić, jaki plik jest wykonywany.

Czy przy analizie zużycia pamięci ważniejszy jest MEM% czy VIRT?

MEM% i szczególnie wartość RES (fizyczna pamięć) są bardziej miarodajne. VIRT to pamięć wirtualna i nie odzwierciedla faktycznego użycia RAM.

Czy od razu należy zamykać procesy kill -9?

Zwykle nie. Najpierw udokumentuj proces i spróbuj łagodnego zakończenia komendą kill PID. kill -9 stosuj tylko, gdy proces nie reaguje i szkodzi stabilności systemu.

Czy wysokie zużycie CPU w htop zawsze oznacza atak?

Nie. Może to być backup, import danych, generowanie cache lub wzmożony ruch. Jednak nietypowe nazwy procesów, działanie z katalogów tymczasowych i podejrzani użytkownicy wskazują na zagrożenie.

Podsumowując, komenda htop to szybkie, praktyczne i skuteczne narzędzie do wykrywania skryptów obciążających CPU i RAM na serwerze Linux. Najlepsze efekty daje łączenie jej wyników z analizą PID, lsof, zadaniami cron i logami. Jeśli problemy z zasobami powtarzają się często, warto równolegle optymalizować aplikacje i rozważyć modernizację infrastruktury. Hostragons oferuje bez presji sprzedażowej porównanie rozwiązań hostingowych, VPS oraz certyfikatów SSL, pomagając wybrać najlepszą konfigurację dla Twojego projektu.