Hitta CPU- och RAM-konsumerande skript med htop på Linux-server

htop-kommandot på en Linux-server är ett av de mest praktiska övervakningsverktygen för att i realtid identifiera skript som överanvänder CPU och RAM. Genom att granska kolumnerna CPU%, MEM%, PID, USER, TIME+ och COMMAND på htop-skärmen kan du se vilket PHP-, Python-, Node.js-, cron-, databas- eller systemprocess som belastar servern. Du kan sedan, genom att kontrollera processens ägare, filväg och syfte, göra en säker åtgärd.

Oavsett om det är delad hosting, VPS, VDS eller dedikerad server, är en stor del av plötsliga långsamheter orsakade av skript som körs okontrollerat. Till exempel kan ett felaktigt WordPress-plugin, en PHP-fil som går in i en oändlig loop, en intensivt körande cron-uppgift, en icke-optimerad databasfråga eller en kapad webbfil snabbt öka CPU-användningen till nästan 100%. När RAM-förbrukningen ökar kan tjänster frysa, MySQL-anslutningar kan brytas, webbplatser kan ge 503-fel eller Linux-kärnan kan avsluta vissa processer med OOM Killer.

I denna guide kommer vi att gå igenom installationen av htop, hur man läser skärmen, hur man särskiljer skript som överanvänder CPU och RAM, hur man hittar filvägen via PID och hur man säkert kan ingripa i processen steg för steg. Vi kommer också att ta upp säkerhetsmisstankar, cron-kontroll, logganalys och genomförbara optimeringsförslag för att förhindra att problemen återkommer. Om du ofta har problem med resursbegränsningar på din server kan du också överväga att granska val av infrastruktur genom att titta på VPS serverpaket och Högpresterande webbhosting.

Vad är htop och varför är det mer användbart än top-kommandot?

htop är ett terminalverktyg som används för att interaktivt övervaka processer som körs på Linux-system. Det är liknande det klassiska top-kommandot men erbjuder en mer läsbar gränssnitt med färgade resursindikatorer, enkel sortering, sökning, filtrering och processhantering. Därför är htop en av de första verktygen som många systemadministratörer kollar på, särskilt när de snabbt diagnostiserar problem på en live-server.

Med htop kan du se följande information i realtid:

• CPU-användning för varje process i procent
• RAM-användning för varje process i procent och mängd
• PID-nummer för processen
• Användaren som kör processen
• Kommando eller skriptnamn
• Körtid och prioritet
• Load average, total RAM, swap och CPU-kärn användning

Särskilt i en hosting-miljö där flera webbplatser, användare eller tjänster körs på samma server, är det inte tillräckligt att bara se den totala resursanvändningen. Det är nödvändigt att identifiera vilken användare, vilken webbplats, vilken cron-uppgift eller vilket skript som orsakar problemet. htop-kommandot på en Linux-server ger snabbt en första diagnos i detta avseende.

Installation av htop: Kommandon beroende på distribution

Inte alla moderna Linux-distributioner levereras med htop förinstallerat. Om du har root- eller sudo-rättigheter kan du installera det på bara några sekunder. Att uppdatera pakethanterarens lista innan installationen minskar risken för fel, särskilt på nyinstallerade servrar.

Installation av htop på Ubuntu och Debian-servrar

På en server baserad på Ubuntu eller Debian kan följande kommandon användas:

sudo apt update

sudo apt install htop -y

Efter installationen kan du starta verktyget genom att skriva htop. Om du inte har sudo-rättigheter kan det vara nödvändigt att begära support från din hostingleverantör. Om du använder en hanterad VPS har du vanligtvis root-åtkomst.

Installation på AlmaLinux, Rocky Linux, CentOS och RHEL

I RHEL-baserade system kan paketförvaltaren vara dnf eller yum beroende på version:

sudo dnf install htop -y

För äldre CentOS-versioner kan EPEL-repo behövas:

sudo yum install epel-release -y

sudo yum install htop -y

Om installationen är framgångsrik öppnas en färgglad övervakningsskärm när du skriver htop i terminalen. Om du är ny på serverhantering kan guide för Linux-kommandon ge en praktisk introduktion till grundläggande Linux-kommandon.

Att läsa htop-skärmen: Vad betyder varje kolumn?

När htop öppnas visas CPU-kärnor, RAM, swap, antal uppgifter, antal trådar, load average och uptime-information i den övre delen av skärmen. I den nedre delen listas de aktiva processerna. De mest använda områdena för problemdiagnos är följande:

En viktig punkt att notera här är att en plötslig CPU-spik inte alltid indikerar ett problem. Till exempel kan CPU-användningen kortvarigt öka under backup, bildoptimering, cache-rensning eller hög trafik. Problemet uppstår när samma process förbrukar hög CPU eller RAM under flera minuter, load average-värdet överstiger antalet kärnor kraftigt och webbservicen slutar svara.

Att hitta CPU-konsumerande skript med htop

För att hitta skript som använder för mycket CPU kan du välja sorteringsområde med F6-tangenten medan htop är öppet eller sortera efter CPU%-kolumnen. I vissa terminaler kan du också klicka på CPU%-rubriken om musstöd är aktiverat. Processerna som visas högst upp är de som för närvarande använder mest CPU.

Steg 1: Sortera efter CPU%-kolumnen

Med htop öppet, sortera processerna efter CPU-användning. Om en process som php-fpm, php, python3, node, java, mysqld eller bash ständigt ligger i topp, notera den processen. Vid enkel kärnanvändning kan 100% verka som det normala övre gränsvärdet, medan i flerkärniga system kan en process visa värden på 200% eller 400%. Detta betyder att processen använder flera kärnor.

Steg 2: Notera PID och USER-information

Anteckna PID-numret och USER-informationen för den misstänkta processen. Om PID är 24819, USER är siteuser och COMMAND är php /home/siteuser/public_html/wp-cron.php, är det högst troligt att problemet är relaterat till cron eller WordPress-mekanismen på den aktuella webbplatsen. Om COMMAND-fältet är för kort kan du aktivera visningen av hela kommandoraden i htop:s inställningar eller använda ps-kommandot för att få detaljer.

Steg 3: Se processens verkliga kommando

För att se den detaljerade kommandoraden via PID kan följande kommando användas:

ps -fp PID

Exempel på användning:

ps -fp 24819

Denna utdata visar vanligtvis vilken fil skriptet körs från. Om kommandot ser ut som php /home/användare/public_html/index.php kan det vara en webbförfrågan orsakad av trafik. Om det ser ut som php /home/användare/public_html/wp-content/plugins/okänt-plugin/task.php kan det vara ett plugin-relaterat problem.

Steg 4: Kontrollera filvägen och öppna filer

För att se vilka filer en process använder är lsof-verktyget mycket värdefullt:

lsof -p PID

Detta kommando visar de filer, bibliotek, loggar och nätverksanslutningar som processen håller öppna. I webbhostingmiljöer är denna utdata användbar för att förstå vilken webbplatskatalog som är aktiv. Om du ser en konstig PHP-fil i /home/example/public_html/wp-content/uploads kan det vara en indikation på en säkerhetsöverträdelse. I sådana fall räcker det inte att bara avsluta processen; filrengöring, lösenordsbyte, plugin-uppdatering och säkerhetsskanning bör genomföras. För SSL och konfigurationer av säkra anslutningar kan du också granska lösningar för SSL-certifikat sidan.

Att hitta RAM-konsumerande skript med htop

RAM-problem kan vara mer subtila än CPU-problem. När CPU:n ökar känns det ofta som en kortvarig långsamhet; när RAM:et tar slut kan tjänster stängas oväntat, swap används intensivt och servern upplever allmän fördröjning. Genom att sortera efter MEM%-kolumnen på htop-skärmen kan du lista de processer som använder mest minne.

Att förstå relationen mellan MEM%, RES och Swap

htop visar MEM%-värdet i standardvyn. I vissa konfigurationer kan kolumnerna VIRT, RES och SHR också visas. När du analyserar RAM är RES-värdet särskilt viktigt; eftersom det representerar det faktiska minnesutrymme som processen använder i fysisk RAM. VIRT-värdet betyder inte alltid verklig RAM-användning, så det kan vara missvisande när det står ensamt.

Till exempel är det inte normalt att en enda PHP-process använder 900 MB RES på en VPS med 4 GB RAM. På samma sätt kan en Node.js-applikation som över tid går från 200 MB till 1,5 GB indikera en minnesläcka. Hög RAM-användning på MySQL eller MariaDB kan ibland vara normalt cachebeteende; här bör frågeprestanda, buffertinställningar och det totala systemminnet utvärderas tillsammans.

Typiska orsaker till RAM-konsumerande skript

• PHP-, Python- eller Node.js-kod som går in i en oändlig loop
• Stora CSV-, XML- eller JSON-filer som laddas in i minnet på en gång
• Ej optimerade WordPress-plugins och temafunktioner
• Bearbetning av bilder, PDF-generering eller videokonvertering
• Återkommande tunga frågor på grund av otillräcklig cache-användning
• Bot-trafik eller attacker som resulterar i att samma skript körs många gånger
• Långvariga bakgrundstjänster med minnesläckor

I sådana fall ger det bara tillfällig lindring att stänga processen med kill-kommandot. För en permanent lösning bör skriptets funktion, vilka ingångar som triggar det och varför det inte frigör minne analyseras.

Sökning, filtrering och trädpresentation i htop

Om det finns hundratals processer som körs på servern kan det vara svårt att göra en manuell sökning i listan. htop erbjuder användbara genvägar för detta ändamål. Du kan söka med F3, filtrera med F4 och växla till trädpresentation med F5. Trädpresentationen är särskilt viktig för att se föräldra-barn-relationer. Till exempel kan du tydligare se php-fpm-barnprocesser som körs under nginx eller Apache, script som triggas av cron eller Node.js-tjänster som hanteras av supervisorn.

Praktiska filterexempel

• Skriv php för att visa endast PHP-processer.
• Skriv python för att filtrera ut Python-skript.
• Skriv wp-cron för att kontrollera WordPress cron-beteende.
• Skriv node för att granska Node.js-applikationer.
• Filtrera efter användarnamn för att se processerna för ett enda hostingkonto.

Dessa filter sparar tid, särskilt på servrar med många användare. Om samma server har 30 olika webbplatser kan USER-kolumnen och kommandovägen inspekteras tillsammans för att snabbt avgöra vilken konto som orsakar problemet. Om du vill förenkla administrationssidan för dina domänbaserade projekt kan du kolla in Domänsökning och registrering sidan.

En säker åtgärdsplan för misstänkta PID

När du hittar en resurskrävande process kan det vara frestande att omedelbart använda kill -9. Men denna metod kan leda till dataförlust, ofullständiga skrivoperationer eller inkonsistenser i tjänster. En mer säker plan bör följas.

1. Dokumentera processen

Notera först PID, USER, COMMAND, CPU%, MEM% och tiden. Om möjligt, ta en skärmdump av htop-skärmen. Dessa register gör det lättare att jämföra vid återkommande problem. Särskilt i byrå-, e-handels- eller företagsprojekt kan dessa data vara användbara när du ger tekniska förklaringar till kunder.

2. Verifiera processens filväg

Verifiera filvägen med ps -fp PID och lsof -p PID-utdata. Om filen ligger i webbroten, granska loggarna för den relevanta applikationen. För WordPress ger wp-content/debug.log, webbserverns access log och error log samt PHP-FPM:s slow log viktiga ledtrådar.

3. Försök att avsluta snällt först

Om processen verkligen är okontrollerad, skicka först en standardavslutningssignal:

kill PID

Vänta ett par sekunder och kontrollera på htop-skärmen om processen har stängts. Om den inte stängs och allvarligt påverkar systemets hälsa, kan följande kommando användas som en sista utväg:

kill -9 PID

kill -9-signalen avslutar processen utan att ge möjlighet till städning. Därför bör den användas med försiktighet för databasoperationer, filskrivningsprocesser eller backup-uppgifter.

4. Hitta triggarna om processen startar om

Om en process startar om inom sekunder efter att du har stängt den kan det bero på cron, systemd-tjänst, supervisor, webbförfrågan eller bot-trafik. För cron-loggar, använd crontab -l, för systemtjänster, använd systemctl status tjänstnamn, och granska access-loggen för webbtrafik. Om problemet är relaterat till WordPress wp-cron, bör den verkliga cron-konfigurationen och cachepolicyn granskas.

Kombinera htop-fynd med loggar

htop visar vad som förbrukar resurser; loggar hjälper dig att förstå varför det förbrukar dem. När dessa två data inte används tillsammans blir diagnosen ofullständig. Till exempel kan php-fpm-processen på htop använda 180% CPU; men utan access-loggen kan du inte se vilken URL eller bot som triggar denna process.

Exempel på loggar som kan kontrolleras inkluderar:

• Webbserverns access-logg: Visar URL:er som får många förfrågningar.
• Webbserverns error-logg: Visar PHP-fel, filrättigheter och 500-fel.
• PHP-FPM:s slow log: Visar långsamt körande PHP-filer och funktioner.
• MySQL:s slow query log: Identifierar tunga SQL-frågor.
• Auth-logg eller secure log: Visar misstänkta inloggningsförsök.
• Cron-logg: Visar när schemalagda uppgifter kördes.

Om du ser att PID:n som förbrukar hög CPU i htop samtidigt får tusentals förfrågningar från /wp-admin/admin-ajax.php i access-loggen, kan problemet bero på ett plugin, bot-trafik eller en dåligt utformad AJAX-process. I detta fall bör WAF, hastighetsbegränsning, cache och optimering av plugins beaktas. För att ta itu med webbplatsens prestanda i större skala kan Webbplats hastighetsoptimering innehållet vara användbart.

Hur skiljer man mellan normal och problematisk belastning?

All hög resursanvändning betyder inte kris. Serverns hårdvara, trafiknivå, typ av applikation och underhållsåtgärder bör beaktas. För en 2-kärnig VPS är det allvarligt om load average-värdet länge ligger på 6-8. I en dedikerad server med 16 kärnor kan samma värde vara normalt. Därför bör load average tolkas med kunskap om antalet kärnor.

Denna jämförelse hjälper till att skilja onödig panik från verkliga prestandakrisproblem. Särskilt för e-handelswebbplatser kan kampanjperioder, betalningsintegrationer och lageruppdateringar orsaka tillfällig resursökning. Men om denna ökning påverkar användarupplevelsen bör applikationsoptimering och serverkapacitet utvärderas tillsammans.

Säkerhetsmisstankar: Kan resurskonsumerande skript vara skadliga?

CPU- eller RAM-konsumerande skript är inte alltid oskyldiga fel. På kapade webbplatser kan angripare köra skript för att skicka skräppost, kryptovaluta-mining, proxy-trafik, DDoS-botar eller bakdörrar. I htop-skärmen bör märkliga kommandon som körs under oväntade användare, slumpmässigt namngivna filer, binära filer som körs från /tmp-katalogen eller PHP-filer som körs i public_html/uploads tas på allvar ur säkerhetsperspektiv.

Misstänkta tecken

• Meningslösa eller slumpmässiga tecken i COMMAND-fältet
• Fil som körs från /tmp, /dev/shm eller uploads-mappen
• Processer som normalt inte bör finnas, som perl, python eller bash
• Processer som skapar hög utgående nätverksanslutning
• Samma användare startar många processer på kort tid
• Nyligen oauktoriserade ändringar i webbfil

I sådana fall bör du, innan du stänger processen, om möjligt ta kommandoutdata som bevis. Kontrollera sedan filrättigheterna, isolera skadliga filer, ändra alla panel- och CMS-lösenord, uppdatera kärnfiler för plugins och teman samt genomföra en säkerhetsskanning. Dessutom bör tvåfaktorsautentisering användas i administrationspaneler och onödiga skrivbehörigheter tas bort för att minska risken på lång sikt.

Bästa praxis för att förebygga prestandaproblem

Att hitta problemet med htop är viktigt; men det verkliga värdet ligger i att förhindra att samma problem upprepas. Följande åtgärder minskar CPU- och RAM-relaterade avbrott på Linux-servrar avsevärt.

• Justera PHP:s memory_limit, max_execution_time och pm.max_children-värden i förhållande till serverns kapacitet.
• Använd cache-mekanismer i WordPress, Joomla eller egna program.
• Ta bort onödiga plugins, teman och moduler.
• Optimera tunga frågor med MySQL slow query log.
• Schemalägg inte cron-jobb att köras vid samma minut; kör dem med intervall.
• Implementera hastighetsbegränsningar, robots.txt och brandväggsregler för bot-trafik.
• Rotera applikationsloggar regelbundet; övervaka effekten av stora loggfiler på disk och RAM.
• Övervaka servermetrik inte bara vid kriser, utan regelbundet.

Om resursanvändningen förblir hög trots optimeringar, kan problemet vara mer än bara mjukvarurelaterat. Trafiken kan ha ökat, applikationen kan ha växt eller den befintliga hostingplanen kan vara otillräcklig. I detta fall kan en skalbar VPS, mer RAM, snabbare NVMe-disk eller en isolerad resursserver bli en logisk lösning. För behovsanalys kan Hostingpaket och lösningar för företagsservrar länkarna användas för att jämföra alternativ.

Exempel på scenario: CPU-explosion på en WordPress-webbplats

Låt oss gå igenom ett realistiskt scenario. På en VPS med 4 kärnor och 8 GB RAM körs flera WordPress-webbplatser. Användare rapporterar att webbplatsen är långsam och ibland ger 502-fel. När htop öppnas i terminalen är load average 12, CPU-kärnorna är fulla och många php-fpm-processer tillhör samma användare visas högst upp.

F4 används för att filtrera efter användarnamn. PID för den CPU-användande processen noteras. I ps -fp PID-utdata syns php-fpm-arbetaren; med lsof -p PID upptäcks tillgång till /home/site/public_html/wp-content/plugins/example-importer/import.php-filen. När access-loggen granskas syns en administrativ förfrågan som triggar denna fil samtidigt som upprepade AJAX-anrop sker.

Som lösning stoppas importprocessen, det schemalagda uppdraget för pluginet stängs av, den stora dataimporten delas upp och PHP:s max_execution_time-gräns justeras. Dessutom används systemcron i stället för wp-cron. Resultatet är att load average sjunker från 12 till 1,8, CPU-användningen återgår till det normala och svarstiderna för webbplatsen förbättras markant. Detta exempel visar hur htop inte bara är effektivt i sig, utan också när det används tillsammans med ps, lsof och logganalys.

Vanliga misstag vid användning av htop

• Att bara stänga den process som ligger högst upp utan att undersöka den grundläggande orsaken.
• Att tro att VIRT-värdet innebär verklig RAM-användning.
• Att direkt betrakta MySQL:s cacheanvändning som ett problem.
• Att använda kill -9 som första alternativ.
• Att anklaga en applikation eller användare utan att kontrollera loggar.
• Att tolka load average-värdet oberoende av antalet CPU-kärnor.
• Att inte granska filintegriteten vid misstanke om säkerhetsöverträdelse.

Att undvika dessa misstag minskar både stilleståndstiden och risken för dataförlust orsakad av felaktiga ingripanden. Korrekt diagnos inom systemadministration är ofta mer värdefull än snabba åtgärder.

Vanliga frågor

Vad används htop-kommandot för på en Linux-server?

htop-kommandot på en Linux-server visar realtidsinformation om aktiva processer, inklusive CPU, RAM, användare, PID och kommandon. Detta gör att du snabbt kan identifiera skript som överanvänder CPU eller RAM.

Hur hittar jag ett CPU-konsumerande skript med htop?

Sortera processerna efter CPU%-kolumnen på htop-skärmen, notera PID- och USER-informationen för processen som ligger högst under längre tid. Använd sedan ps -fp PID och lsof -p PID för att verifiera skriptets filväg och vad som körs.

Bör jag fokusera på MEM% eller VIRT vid RAM-användning?

Vid RAM-analys är MEM% och särskilt RES-värdet mer meningsfulla. VIRT representerar mängden allokerad virtuell minneskapacitet och betyder inte alltid verklig fysisk RAM-användning.

Är det okej att stänga en resurskrävande process med kill -9 direkt?

Generellt sett nej. Det är säkrare att först dokumentera processen, kontrollera filvägen och försöka med standardkill PID-kommandot. Kill -9 bör endast användas som sista utväg när processen inte stänger och allvarligt påverkar serverns hälsa.

Indikerar hög CPU-användning på htop alltid ett angrepp?

Nej. Backup, import, cache-generering eller hög trafik kan också öka CPU-användningen. Men ovanliga filnamn, skript som körs från /tmp eller uploads och processer under oväntade användare ger upphov till säkerhetsmisstankar.

Sammanfattningsvis är htop-kommandot på en Linux-server en snabb, praktisk och effektiv utgångspunkt för att hitta skript som överanvänder CPU och RAM. För att få de mest korrekta resultaten bör du kombinera htop-data med PID-analys, lsof-utdata, cron-kontroll och logganalys. Om resursproblem ofta återkommer, utvärdera både mjukvaruoptimering och infrastrukturkapacitet; vid behov kan du jämföra Hostragons hosting-, VPS- och SSL-lösningar utan försäljningspress för att välja den mest lämpliga strukturen för ditt projekt.