htop naredba na Linux poslužitelju jedan je od najpraktičnijih alata za praćenje koji se koristi za brzo pronalaženje skripti koje prekomjerno troše CPU i RAM. Na htop ekranu možete pregledati stupce CPU%, MEM%, PID, USER, TIME+ i COMMAND kako biste vidjeli koja PHP, Python, Node.js, cron, baza podataka ili sistemski proces opterećuje poslužitelj; zatim možete provjeriti vlasnika procesa, putanju do datoteke i svrhu rada kako biste mogli sigurno intervenirati.
Bilo da je riječ o dijeljenom hostingu, VPS-u, VDS-u ili namjenskom poslužitelju, značajan dio iznenadnih usporavanja dolazi od neuređenih skripti. Na primjer, neispravan WordPress dodatak, PHP datoteka koja ulazi u beskonačnu petlju, intenzivna cron zadaća, neoptimizirana SQL upit ili zaražena web datoteka mogu brzo povećati CPU upotrebu blizu 100%. Kada se poveća potrošnja RAM-a, usluge se mogu usporiti, MySQL veze se mogu prekinuti, web stranice mogu prikazati 503 grešku ili Linux kernel može pokrenuti OOM Killer kako bi završio neke procese.
U ovom vodiču počet ćemo od instalacije htop-a, a zatim ćemo korak po korak objasniti kako čitati ekran, kako razlikovati skripte koje troše CPU i RAM, kako pronaći putanju do datoteke putem PID-a i kako sigurno intervenirati u proces. Također ćemo se osvrnuti na sigurnosne sumnje, provjeru crona, analizu logova i primjenjive optimizacijske preporuke kako bismo spriječili ponavljanje problema. Ako često imate problema s ograničenjem resursa na svom poslužitelju, možete pregledati VPS server paketi i Web hosting visoke performanse stranice kako biste preispitali svoj izbor infrastrukture.
Što je htop i zašto je korisniji od top naredbe?
htop je terminalski alat koji služi za interaktivno praćenje procesa koji se izvode na Linux sustavima. Sličan je klasičnoj top naredbi, ali nudi čitljivije sučelje, šarene indikatore resursa, jednostavno sortiranje, pretraživanje, filtriranje i upravljanje procesima. Stoga je htop jedan od prvih alata na koje se većina sistemskih administratora oslanja prilikom brze dijagnostike na aktivnom poslužitelju.
Uz htop možete trenutno vidjeti sljedeće informacije:
- Postotak CPU-a koji koristi svaki proces
- Postotak i količina RAM-a koju koristi svaki proces
- PID broj procesa
- Korisnik koji pokreće proces
- Ime naredbe ili skripte
- Vrijeme trajanja i prioritet procesa
- Prosječno opterećenje, ukupni RAM, swap i korištenje CPU jezgri
Osobito u okruženju hostinga, kada na istom poslužitelju radi više web stranica, korisnika ili usluga, nije dovoljno samo vidjeti ukupnu potrošnju resursa. Potrebno je pronaći koji korisnik, koja web stranica, koja cron zadaća ili koja skripta uzrokuje problem. htop naredba na Linux poslužitelju pruža brzu prvu dijagnozu u ovom slučaju.
Instalacija htop-a: Naredbe prema distribuciji
Na mnogim modernim Linux distribucijama htop možda nije unaprijed instaliran. Ako imate root ili sudo ovlasti, možete ga instalirati u nekoliko sekundi. Ažuriranje popisa paketa prije instalacije smanjuje mogućnost pogreške, posebno na svježe postavljenim poslužiteljima.
Instalacija htop-a na Ubuntu i Debian poslužiteljima
Na Ubuntu ili Debian temeljenom poslužitelju možete koristiti sljedeće naredbe:
sudo apt update
sudo apt install htop -y
Nakon instalacije možete pokrenuti alat jednostavno upisivanjem htop. Ako nemate sudo ovlasti, možda ćete morati zatražiti podršku od svog pružatelja hostinga. Ako koristite upravljivi VPS, root pristup obično pripada vama.
Instalacija na AlmaLinux, Rocky Linux, CentOS i RHEL
Na RHEL temeljenim sustavima upravitelj paketa može biti dnf ili yum, ovisno o verziji:
sudo dnf install htop -y
Na starijim verzijama CentOS-a, može biti potrebna EPEL repozitorij:
sudo yum install epel-release -y
sudo yum install htop -y
Ako je instalacija uspješna, kada upišete htop u terminal, otvorit će se zaslon za praćenje s bojama. Ako ste novi u upravljanju poslužiteljima, sadržaj vodič za Linux naredbe također pruža dobar početak za osnovne Linux naredbe.
Kako čitati htop ekran: Što znače stupci?
Kada se htop otvori, na vrhu ekrana nalaze se informacije o CPU jezgrama, RAM-u, swapu, broju zadataka, broju niti, prosječnom opterećenju i uptime-u. U donjem dijelu prikazani su aktivni procesi. Najčešće korištena područja u dijagnostici problema su sljedeća.
| Stupac | Značenje | Kada posumnjati? |
|---|---|---|
| PID | Jedinstveni identifikacijski broj procesa. | Potrebno je za istraživanje putanje do datoteke i veza. |
| KORISNIK | Korisnik Linux-a koji pokreće proces. | Treba provjeriti ako proces radi pod neočekivanim korisnikom. |
| CPU% | Trenutni postotak korištenja CPU-a od strane procesa. | Procesi koji dugo ostaju u rasponu od 80-100% trebaju se istražiti. |
| MEM% | Dijeli RAM-a koji koristi proces. | Ako jedan skript koristi 20% ili više RAM-a, to je rizično. |
| TIME+ | Ukupno vrijeme CPU-a koje je proces potrošio. | Prikazuje poslove koji troše resurse dulje vrijeme, a ne kratkotrajno. |
| NAZIV | Informacija o izvršavnoj naredbi, usluzi ili skripti. | Putanja do datoteke treba se tražiti u procesima poput php, python, node, perl, bash, java. |
Važno je napomenuti da kratkotrajni skok CPU-a ne mora uvijek značiti problem. Na primjer, tijekom izrade sigurnosne kopije, optimizacije slika, čišćenja predmemorije ili u slučaju velike prometa, CPU može kratko porasti. Problem nastaje kada isti proces troši visoku CPU ili RAM dulje od nekoliko minuta, a vrijednost prosječnog opterećenja premašuje broj jezgri, što dovodi do neodgovarajućih web usluga.
Pronalaženje skripti koje troše CPU uz htop
Da biste pronašli skripte koje prekomjerno koriste CPU, dok ste na htop ekranu, možete pritisnuti F6 kako biste odabrali područje sortiranja ili možete sortirati prema stupcu CPU%. U nekim terminalima, ako je podržana upotreba miša, jednostavno kliknite na naslov CPU% da biste sortirali. Procesi koji se nalaze na vrhu trenutačno su oni koji najviše koriste CPU.
Korak 1: Sortirajte prema stupcu CPU%
Dok je htop aktivan, sortajte procese prema korištenju CPU-a. Na primjer, ako jedan od procesa kao što su php-fpm, php, python3, node, java, mysqld ili bash stalno ostaje na visokim pozicijama, zabilježite taj proces. Na sustavima s jednim jezgrom, 100% se može činiti kao normalno gornje granice, dok na višejezgrenim sustavima proces može pokazati vrijednosti od 200% ili 400%. To znači da proces koristi više od jedne jezgre.
Korak 2: Zabilježite PID i informacije o korisniku
Zabilježite PID broj sumnjivog procesa i informacije o korisniku. Na primjer, ako je PID 24819, korisnik siteuser i u polju COMMAND stoji php /home/siteuser/public_html/wp-cron.php, postoji velika vjerojatnost da je problem povezan s cron zadaćom ili WordPress mehanizmom na toj web stranici. Ako je polje COMMAND prekratko, možete aktivirati opciju za prikaz cijelog naziva naredbe u htop postavkama ili dobiti detalje pomoću ps naredbe.
Korak 3: Pogledajte stvarnu naredbu procesa
Da biste vidjeli detaljnu naredbu putem PID-a, možete koristiti sljedeću naredbu:
ps -fp PID
Primjer korištenja:
ps -fp 24819
Ovaj izlaz obično pokazuje iz koje datoteke skripta radi. Ako se naredba prikazuje kao php /home/korisnik/public_html/index.php, to može biti web zahtjev uzrokovan prometom. Ako se prikazuje kao php /home/korisnik/public_html/wp-content/plugins/bilinmeyen-eklenti/task.php, to može značiti problem s dodatkom.
Korak 4: Provjerite putanju do datoteke i otvorene datoteke
Za pregled datoteka koje koristi proces, alat lsof je vrlo koristan:
lsof -p PID
Ova naredba prikazuje otvorene datoteke, biblioteke, logove i mrežne veze koje drži proces. U web hosting okruženjima, ova izlazna informacija može pokazati koja direktorija web stranice je aktivna. Na primjer, ako vidite PHP datoteku s čudnim imenom koja radi unutar /home/example/public_html/wp-content/uploads, to može biti znak sigurnosne povrede. U takvim slučajevima, samo završavanje procesa nije dovoljno; potrebno je provesti čišćenje datoteka, promijeniti lozinke, ažurirati dodatke i izvršiti sigurnosno skeniranje. Također možete provjeriti stranicu Rješenja za SSL certifikate za konfiguracije SSL-a i sigurnih veza.
Pronalaženje skripti koje troše RAM uz htop
Problemi s RAM-om mogu se razvijati tiše od problema s CPU-om. Kada CPU poraste, obično se osjeti trenutačno usporavanje; kada RAM ponestane, usluge se mogu neočekivano zatvoriti, swap se intenzivno koristi, a općenito se povećava kašnjenje na poslužitelju. Možete sortirati procese prema stupcu MEM% na htop ekranu kako biste dobili popis onih koji najviše koriste memoriju.
Razumijevanje odnosa između MEM%, RES i Swap
htop u svom zadnjem prikazu prikazuje omjer MEM%. U nekim konfiguracijama mogu biti vidljivi i stupci VIRT, RES i SHR. Kada analizirate RAM, RES vrijednost je posebno važna, jer označava fizički prostor koji proces stvarno koristi u memoriji. VIRT vrijednost ne znači uvijek stvarnu potrošnju RAM-a, pa može biti obmanjujuća kada se koristi sama.
Na primjer, na VPS-u s 4 GB RAM-a, ako jedan PHP proces koristi 900 MB RES, to nije normalno. Slično tome, ako Node.js aplikacija tijekom vremena poraste s 200 MB na 1.5 GB, to može značiti curenje memorije. Visoka potrošnja RAM-a na MySQL ili MariaDB može ponekad biti normalno ponašanje predmemorije; ovdje treba razmotriti izvedbu upita, postavke predmemorije i ukupnu memoriju sustava zajedno.
Tipični uzroci za skripte koje troše RAM
- Skripte u beskonačnoj petlji u PHP, Pythonu ili Node.js
- Velike CSV, XML ili JSON datoteke koje se učitavaju u memoriju odjednom
- Neoptimizirani WordPress dodaci i funkcije tema
- Obrade slika, generiranje PDF-a ili konverzije videa
- Ponovljeni teški upiti zbog nedostatka korištenja predmemorije
- Bot prometa ili napada zbog čega se ista skripta pokreće više puta
- Dugotrajne pozadinske usluge s curenjem memorije
U ovim slučajevima, samo zatvaranje procesa s kill naredbom pruža privremeno olakšanje. Za trajno rješenje potrebno je analizirati što skripta radi, koje ulaze koristi za aktivaciju i zašto ne oslobađa memoriju.
Pretraživanje, filtriranje i prikaz stabla u htop-u
Kada na poslužitelju radi stotine procesa, ručno pretraživanje popisa postaje teško. htop nudi korisne prečace za to. Možete pretraživati pomoću F3, primijeniti filter s F4 i preći na prikaz stabla s F5. Prikaz stabla je važan za vidjeti odnose između roditelja i djece. Na primjer, možete jasnije vidjeti child procese php-fpm koji rade pod nginx ili Apache, skripte koje pokreću cron ili Node.js servise koje upravlja supervisor.
Praktični primjeri filtriranja
- Upisivanjem php prikazujete samo PHP procese.
- Upisivanjem python filtrirate Python skripte.
- Upisivanjem wp-cron provjeravate ponašanje WordPress cron-a.
- Upisivanjem node pregledavate Node.js aplikacije.
- Filtriranje prema korisničkom imenu prikazuje procese samo jednog hosting računa.
Ovi filtri štede vrijeme, osobito na višekorisničkim poslužiteljima. Na primjer, ako se na istom poslužitelju nalazi 30 različitih web stranica, brzo se može utvrditi iz koje je korisničkog računa problem provjerom stupca USER i putanje do naredbe. Ako želite pojednostaviti upravljanje za svoje projekte temeljene na domenama, možete pogledati stranicu Provjera domene i registracija.
Siguran plan intervencije za sumnjivi PID
Kada pronađete proces koji troši resurse, može biti primamljivo odmah koristiti kill -9. Međutim, ovaj pristup može uzrokovati gubitak podataka, nedovršene operacije pisanja ili nesigurnosti u uslugama. Potrebno je slijediti sigurniji plan.
1. Dokumentirajte proces
Prvo zabilježite PID, KORISNIK, COMMAND, CPU%, MEM% i vrijeme. Ako je moguće, napravite snimku zaslona htop-a. Ovi zapisi olakšavaju usporedbu ponovljenih problema. Ove informacije će biti korisne, posebno u agencijskim, e-trgovinskim ili korporativnim projektima, kada je potrebno pružiti tehničko objašnjenje klijentu.
2. Provjerite putanju datoteke procesa
Provjerite putanju datoteke s ps -fp PID i lsof -p PID ispravama. Ako se datoteka nalazi u korijenskom direktoriju weba, provjerite odgovarajuće aplikacijske logove. Za WordPress, wp-content/debug.log, za web server access log i error log, a za PHP-FPM slow log pružaju važne naznake.
3. Prvo pokušajte s nježnim završetkom
Ako je proces doista nekontroliran, prvo pošaljite standardni signal za završavanje:
kill PID
Pričekajte nekoliko sekundi i provjerite na htop ekranu je li proces zatvoren. Ako se ne zatvara i ozbiljno ugrožava zdravlje sustava, kao posljednje sredstvo može se upotrijebiti sljedeća naredba:
kill -9 PID
kill -9 signal završava proces bez mogućnosti čišćenja. Stoga treba biti oprezan pri njegovoj upotrebi za operacije s bazama podataka, procese pisanja datoteka ili zadatke sigurnosnog kopiranja.
4. Ako se proces ponovo pokreće, pronađite uzrok
Ako se proces ponovno pokrene nekoliko sekundi nakon zatvaranja, uzrok može biti cron, systemd usluga, supervisor, web zahtjev ili bot promet. Za cron zapise, koristite crontab -l, za sistemske usluge systemctl status nazivservisa, a za web promet pregledajte access log. Ako je problem uzrokovan WordPress wp-cron, potrebno je preispitati stvarnu cron konfiguraciju i politiku predmemorije.
Spajanje htop nalaza s logovima

htop vam pokazuje što troši resurse; logovi vam pomažu razumjeti zašto ih troši. Ako se ova dva podatka ne koriste zajedno, dijagnostika može biti nepotpuna. Na primjer, htop može pokazati da php-fpm proces koristi 180% CPU-a; međutim, bez access loga nećete moći vidjeti koji URL ili koji bot aktivira ovaj proces.
Primjeri logova koje možete provjeriti uključuju:
- Web server access log: Prikazuje URL-ove koji primaju intenzivne zahtjeve.
- Web server error log: Prikazuje PHP greške, dozvole datoteka i 500 greške.
- PHP-FPM slow log: Prikazuje spore PHP datoteke i funkcije.
- MySQL slow query log: Otkriva teške SQL upite.
- Auth log ili secure log: Prikazuje sumnjive pokušaje prijave.
- Cron log: Prikazuje kada su zakazani zadaci izvršeni.
Na primjer, ako se PID s visokim CPU-om u htop-u u istoj minuti prikazuje s tisućama zahtjeva na /wp-admin/admin-ajax.php u access logu, problem može biti povezan s dodatkom, bot prometom ili loše dizajniranom AJAX funkcijom. U ovom slučaju, WAF, ograničenje brzine, predmemorija i optimizacija dodataka trebaju se razmotriti zajedno. Za širu analizu performansi web stranice, sadržaj Optimizacija brzine web stranice može biti koristan.
Kako razlikovati normalno opterećenje od problematičnog?
Svaka visoka potrošnja resursa ne znači krizu. Treba uzeti u obzir hardver poslužitelja, razinu prometa, vrstu aplikacije i održavanje. Za VPS s 2 jezgre, dugotrajna vrijednost prosječnog opterećenja od 6-8 smatra se ozbiljnim uskim grlom. S druge strane, isto na namjenskom poslužitelju s 16 jezgri može biti normalno. Stoga, prilikom tumačenja prosječnog opterećenja, broj jezgri mora se uvijek znati.
| Observacija | Potencijalna situacija | Preporučena akcija |
|---|---|---|
| CPU kratko 100%, zatim se vraća na normalu | Privremeni intenzivan proces | Potvrdite log, nemojte odmah intervenirati. |
| Isti PID koristi visoku CPU tijekom minuta | Beskonačna petlja ili težak proces | Pronađite put do PID-a, pregledajte skriptu. |
| RAM stalno raste i ne opada | Curenje memorije | Provjerite kod usluge i postavke radnika. |
| Swap korištenje brzo raste | Nedostatak fizičkog RAM-a | Planirajte optimizaciju RAM-a ili nadogradnju paketa. |
| Postoji mnogo istih PHP procesa | Bot promet ili intenzivni zahtjev | Provjerite access log, firewall i predmemoriju. |
Ova usporedba pomaže u odvojenju nepotrebne panike od stvarne krize performansi. Osobito u e-commerce stranicama, kampanje, integracije plaćanja i ažuriranja zaliha mogu uzrokovati privremeno povećanje resursa. Međutim, ako ovo povećanje ometa korisničko iskustvo, potrebno je zajedno razmotriti optimizaciju aplikacije i kapacitet poslužitelja.
Sumnja na sigurnost: Može li skripta koja troši resurse biti zlonamjerna?
Skripta koja troši CPU ili RAM ne mora uvijek biti benigni greška. Na zaraženim web stranicama, napadači mogu pokretati spam, kripto rudarenje, proxy promet, DDoS botove ili skripte za stražnja vrata. Sumnjivi procesi koji se izvode pod neočekivanim korisnicima, neobični nazivi datoteka, binarne datoteke koje rade iz /tmp direktorija ili PHP datoteke unutar public_html/uploads trebaju se ozbiljno shvatiti s aspekta sigurnosti.
Znaci sumnje
- Besmisleni ili nasumični nazivi datoteka u polju COMMAND
- Datoteke koje rade iz /tmp, /dev/shm ili uploads direktorija
- Normalno nebi trebale biti prisutne perl, python ili bash skripte
- Procesi koji stvaraju visoku vanjsku mrežnu vezu
- Isti korisnik pokreće mnogo procesa u kratkom vremenu
- Recentne neovlaštene promjene u web datotekama
U takvim slučajevima, prije zatvaranja procesa, ako je moguće, prikupite izlaze naredbi kao dokaze. Zatim provjerite dozvole datoteka, izolirajte zlonamjerne datoteke, promijenite sve lozinke za panele i CMS, ažurirajte datoteke dodataka i tema, te izvršite sigurnosno skeniranje. Također, korištenje dvofaktorske autentifikacije na administrativnim panelima i uklanjanje nepotrebnih privilegija pisanja smanjuje rizik na duži rok.
Najbolje prakse za sprječavanje ponavljanja problema s performansama
Pronalazak problema s htop-om je važan; no, prava vrijednost leži u sprječavanju ponovnog pojavljivanja istih problema. Sljedeće mjere mogu značajno smanjiti prekide uzrokovane CPU i RAM resursima na Linux poslužiteljima.
- Podesite PHP memory_limit, max_execution_time i pm.max_children vrijednosti prema kapacitetu poslužitelja.
- Koristite mehanizam predmemorije u WordPressu, Joomli ili prilagođenim aplikacijama.
- Uklonite nepotrebne dodatke, teme i module.
- Optimizirajte teške upite s MySQL slow query log-om.
- Ne grupirajte cron zadatke u istu minutu; postavite ih da se izvode u intervalima.
- Primijenite ograničenje brzine, robots.txt i pravila vatrozida za bot promet.
- Redovito rotirajte aplikacijske logove; pratite učinak ogromnih log datoteka na disk i RAM.
- Redovito pratite metrike poslužitelja, ne samo u kriznim situacijama.
Ako, unatoč optimizacijama, potrošnja resursa ostaje visoka, problem možda nije samo na softverskoj strani. Promet može biti povećan, aplikacija proširena ili trenutni hosting paket neadekvatan. U tom slučaju, skalabilni VPS, više RAM-a, brži NVMe disk ili poslužitelj s izoliranim resursima postaju logičan izbor. Za analizu potreba, opcije se mogu usporediti putem Hosting paketi i korporativna rješenja za servere.
Primjer scenarija: WordPress stranica s naglim porastom CPU-a
Pogledajmo realan scenarij. Na VPS-u s 4 jezgre i 8 GB RAM-a radi nekoliko WordPress stranica. Korisnici javljaju da se stranica usporava i povremeno prikazuje 502 grešku. Kada otvorite htop u terminalu, prosječno opterećenje iznosi 12, svi CPU jezgre su zauzete i na vrhu se vidi mnogo php-fpm procesa koji pripadaju istom korisniku.
Filtrirate korisničko ime pritiskom na F4. Zapisujete PID jednog od procesa koji troši CPU. U ps -fp PID izlazu pojavljuje se php-fpm worker; s lsof -p PID otkriva se pristup datoteci /home/site/public_html/wp-content/plugins/example-importer/import.php. Kada se pregleda access log, vidi se da je u istim minutama zabilježen zahtjev od administratora koji aktivira tu datoteku, a zatim slijede ponavljajući AJAX pozivi.
Kao rješenje, proces uvoza se prekida, zakazana zadaća dodatka se isključuje, veliki podaci se uvoze u dijelovima, a PHP max_execution_time ograničenje se ponovo podešava. Također se koristi sistemski cron umjesto wp-cron. Kao rezultat toga, prosječno opterećenje pada s 12 na 1.8, potrošnja CPU-a se vraća na normalu i vrijeme odgovora web stranica se značajno poboljšava. Ovaj primjer pokazuje koliko je htop učinkovit kada se koristi zajedno s ps, lsof i analizom logova.
Uobičajene greške prilikom korištenja htop-a
- Samo zatvoriti proces na vrhu i ne istraživati osnovni uzrok.
- VIRT vrijednost zamijeniti sa stvarnom potrošnjom RAM-a.
- Izravno smatrati korištenje RAM-a od strane MySQL-a kao problem.
- kill -9 koristiti kao prvi izbor.
- Optuživati aplikaciju ili korisnika bez provjere logova.
- Neovisno tumačiti load average vrijednost bez obzira na broj jezgri.
- Ne provjeriti cjelovitost datoteka u slučaju sumnje na sigurnosnu povredu.
Izbjegavanje ovih grešaka smanjuje vrijeme prekida i rizik od gubitka podataka zbog pogrešnih intervencija. U upravljanju sustavom, ispravna dijagnostika često je vrijednija od brze intervencije.
Česta pitanja
Za što se koristi htop naredba na Linux poslužitelju?
htop naredba na Linux poslužitelju prikazuje informacije o radnim procesima, uključujući CPU, RAM, korisnika, PID i naredbu u stvarnom vremenu. Tako možete brzo otkriti skripte koje prekomjerno troše CPU ili memoriju.
Kako pronaći skriptu koja troši CPU uz htop?
Sortirajte procese u htop-u prema stupcu CPU%, zabilježite PID i informacije o korisniku procesa koji dugo ostaje na vrhu. Zatim provjerite putanju do skripte koristeći ps -fp PID i lsof -p PID.
Treba li se kod potrošnje RAM-a oslanjati na MEM% ili VIRT?
U analizi RAM-a, MEM% i posebno RES vrijednost su značajniji. VIRT pokazuje količinu rezervirane virtualne memorije i ne znači uvijek fizičku potrošnju RAM-a.
Je li ispravno odmah zatvoriti proces koji troši resurse s kill -9?
Općenito ne. Prvo zabilježite informacije o procesu, provjerite putanju do datoteke i pokušajte s kill PID. kill -9 treba koristiti samo kao posljednje sredstvo kada proces ne reagira i ozbiljno ugrožava zdravlje sustava.
Je li visoka potrošnja CPU-a uvijek znak napada?
Ne. Backup, import, kreiranje predmemorije ili visoki promet također mogu povećati potrošnju CPU-a. Međutim, nasumični nazivi datoteka, skripte koje rade iz /tmp ili uploads, i procesi pod neočekivanim korisnicima mogu izazvati sumnju na sigurnost.
Ukratko, htop naredba na Linux poslužitelju predstavlja brzu, praktičnu i učinkovitu početnu točku za pronalaženje skripti koje troše CPU i RAM. Za najpreciznije rezultate, podatke iz htop-a treba kombinirati s analizom PID-a, izlazom lsof, provjerom crona i analizom logova. Ako se problemi s resursima često ponavljaju na vašem poslužitelju, razmotrite optimizacije softvera i kapacitet infrastrukture; u slučaju potrebe, možete usporediti rješenja za hosting, VPS i SSL od Hostragons-a bez pritiska na prodaju kako biste odabrali najprikladniju strukturu za vaš projekt.