Find CPU- og RAM-hungrende scripts på Linux server med htop

På en Linux server er htop et af de mest effektive værktøjer til at spotte scripts, der overforbruger CPU og RAM i realtid. Med htop kan du hurtigt identificere hvilke PHP, Python, Node.js, cron jobs, databaseprocesser eller systemtjenester, der presser serveren, ved at studere kolonnerne CPU%, MEM%, PID, USER, TIME+ og COMMAND. Herefter kan du tjekke ejeren, filstien og formålet med processen og gribe sikkert ind efter behov.

Uanset om du kører delt hosting, VPS, VDS eller dedikeret server, skyldes mange pludselige nedbremsninger scripts, der kører ukontrolleret. Fejlbehæftede WordPress plugins, PHP-filer i uendelige loops, overbelastede cron jobs, dårligt optimerede database queries eller kompromitterede webfiler kan på få minutter bringe CPU-forbruget op mod 100%. Når RAM-forbruget stiger, kan tjenester hænge, MySQL forbindelser falde ud, websider give 503-fejl, eller Linux OOM Killer kan afslutte processer automatisk.

Guiden her hjælper dig trin for trin: Fra installation af htop, til hvordan du læser skærmen, skelner scripts der tærer på CPU og RAM, finder filstien via PID, og griber sikkert ind. Vi kommer også ind på sikkerhedsadvarsler, cron kontrol, loganalyse og konkrete optimeringsråd for at undgå gentagelser. Oplever du ofte resource problemer på din server, så tjek VPS serverpakker og Højtydende web hosting for at vurdere om infrastrukturen matcher behovet.

Hvad er htop – og hvorfor er det bedre end top?

htop er et interaktivt terminalværktøj til at overvåge processer på Linux. Det minder om det klassiske top-kommando, men byder på mere overskuelig interface, farvekodede ressourceindikatorer, nem sortering, søgning, filtrering og avanceret processtyring. Derfor er htop ofte førstevalg for systemadministratorer, når serveren skal diagnosticeres hurtigt.

Med htop kan du løbende se:

• CPU-forbrug for hver enkelt proces
• RAM-forbrug og mængde for hver proces
• PID (proces-id)
• Hvilken bruger processen kører under
• Kommandolinje/scriptnavn
• Køretid og prioritet
• Load average, samlet RAM, swap og CPU kernebrug

Især på hosting-miljøer med flere sites og brugere på samme server er det ikke nok at se totalforbruget. Du skal hurtigt kunne lokalisere, om problemet skyldes en bestemt bruger, webside, cron job eller scriptfil. htop gør den indledende fejlsøgning meget lettere.

Installering af htop: Kommandoer efter distribution

htop følger ikke nødvendigvis med alle Linux-distributioner. Hvis du har root eller sudo-rettigheder, kan du installere det på få sekunder. Det er en god idé først at opdatere pakkelisten – især på nyinstallerede servere – for at undgå fejl.

Installering af htop på Ubuntu og Debian servere

På Ubuntu eller Debian baserede systemer:

sudo apt update

sudo apt install htop -y

Efter installationen kan du starte htop med kommandoen htop. Har du ikke sudo-adgang, må du kontakte dit hostingfirma. På en administreret VPS er root normalt tilgængelig.

Installering på AlmaLinux, Rocky Linux, CentOS og RHEL

På RHEL-systemer bruges dnf eller yum, afhængig af version:

sudo dnf install htop -y

På ældre CentOS kan du først aktivere EPEL-repository:

sudo yum install epel-release -y

sudo yum install htop -y

Hvis installationen er succesfuld, åbner den farvede overvågningsskærm, når du skriver htop i terminalen. Er du ny indenfor serveradministration, giver Guide til Linux kommandoer en god basis for de vigtigste Linux kommandoer.

Sådan læser du htop: Hvad betyder kolonnerne?

Øverst på htop-skærmen ser du CPU kerner, RAM, swap, antal tasks, threads, load average og uptime. Nederst listes de aktive processer. Her er de mest brugte kolonner:

Bemærk: En kortvarig CPU-spike er ikke altid et problem. Backup, billedoptimering, cache-clear eller trafikspikes kan give midlertidigt højt CPU-forbrug. Problemet opstår, hvis samme proces ligger højt i flere minutter, load average overstiger kerneantal markant, og webtjenester ikke svarer.

Sådan finder du CPU-hungrende scripts med htop

For at spotte scripts der bruger for meget CPU, sorter processerne i htop efter CPU% (F6 eller klik på CPU% hvis musestøtte er aktiveret). De øverste processer er dem, der i øjeblikket sluger mest CPU.

Trin 1: Sortér efter CPU%

Sortér processerne efter CPU-forbrug. Hvis du ser php-fpm, php, python3, node, java, mysqld eller bash ligge stabilt i toppen, så noter processen. På en single-core server er 100% CPU typisk max, på multi-core systemer kan en proces vise f.eks. 200% eller 400% – hvilket betyder den bruger flere kerner.

Trin 2: Notér PID og USER

Notér PID og USER for den mistænkte proces. Hvis PID fx er 24819, USER er siteuser, og COMMAND viser php /home/siteuser/public_html/wp-cron.php, så er det sandsynligt, at problemet skyldes et cron job eller WordPress-funktion på det site. Hvis kommandoen er kort, kan du vælge at vise hele kommandolinjen i htop eller bruge ps for detaljer.

Trin 3: Vis den fulde kommando

For at se præcis hvad processen kører, brug:

ps -fp PID

Eksempel:

ps -fp 24819

Output viser typisk hvilken fil/script der kører. Hvis det er php /home/kunde/public_html/index.php, kan det skyldes webtrafik. Hvis det er php /home/kunde/public_html/wp-content/plugins/mystisk-plugin/task.php, kan det være et plugin-problem.

Trin 4: Tjek filstier og åbne filer

For at se hvilke filer processen bruger, er lsof uundværlig:

lsof -p PID

Dette viser alle åbne filer, biblioteker, logs og netværksforbindelser. I hosting-miljøer kan du hurtigt se hvilket site eller mappe processen stammer fra. Hvis du ser en mærkelig PHP-fil i /home/eksempel/public_html/wp-content/uploads, kan det indikere et sikkerhedsbrud. Her skal du ikke kun afslutte processen – men også rydde op, ændre adgangskoder, opdatere plugins og køre sikkerhedsscanning. For SSL og sikre opsætninger, se løsninger til SSL certifikat.

Sådan finder du RAM-hungrende scripts med htop

RAM-problemer udvikler sig ofte mere snigende end CPU-tunge scripts. Når CPU stiger, mærkes det straks. RAM-mangel kan få tjenester til at stoppe uventet, swap bruges mere, og serveren bliver langsom generelt. Sortér i htop efter MEM% for at se hvilke processer bruger mest RAM.

Forstå MEM%, RES og Swap

htop viser MEM%. Nogle opsætninger har også VIRT, RES og SHR kolonner. RES er vigtigst, da den viser processens reelle forbrug af fysisk RAM. VIRT er ikke altid udtryk for ægte RAM-forbrug, og kan være vildledende.

På en VPS med 4 GB RAM er det ikke normalt, hvis én PHP-proces bruger 900 MB RES. Hvis en Node.js-app går fra 200 MB til 1,5 GB, kan det være tegn på memory leak. For database-processer som MySQL/MariaDB er højt RAM-forbrug ofte normalt pga. cache – men vurder det sammen med query performance, buffer settings og samlet systemmemory.

Typiske årsager til højt RAM-forbrug

• Uendelige loops i PHP, Python eller Node.js
• Store CSV, XML eller JSON-filer indlæst på én gang
• Ikke-optimerede WordPress plugins og tema-funktioner
• Billedbehandling, PDF-generering eller videokonvertering
• Manglende cache, så tunge queries gentages
• Bottrafik eller angreb, hvor samme script startes mange gange
• Memory leaks i long-running background services

At afslutte processen med kill hjælper kun midlertidigt. Du bør også analysere hvad scriptet laver, hvordan det trigges, og hvorfor det ikke frigiver memory.

Søgning, filtrering og trævisning i htop

Har du hundredvis af processer, kan manuel søgning være uoverskuelig. htop har smarte shortcuts: F3 for søgning, F4 for filter, F5 for trævisning (parent-child relationer). Trævisning er nyttig, hvis du vil se fx php-fpm childprocesser under nginx/Apache, cron-udløste scripts eller Node.js services under supervisor.

Praktiske filter-eksempler

• Skriv php for kun at se PHP-processer
• Skriv python for kun at se Python scripts
• Skriv wp-cron for at kontrollere WordPress cron
• Skriv node for at se Node.js apps
• Filtrér på brugernavn for at se én hosting-kontos processer

Filtrene sparer tid, især på servere med mange sites. Hvis du hoster 30 forskellige domæner, kan du hurtigt se hvilke processer der tilhører hvilken bruger eller projekt. Vil du forenkle domæneadministrationen, så tjek Domæneforespørgsel og registrering.

Sikker indgriben på mistænkelig PID

Det er fristende at bruge kill -9 straks på resource-hungrende processer, men det kan føre til datatab, ufuldstændige writes eller ustabile services. Følg en mere sikker procedure.

1. Dokumentér processen

Notér PID, USER, COMMAND, CPU%, MEM% og tid. Tag evt. screenshot af htop. Det hjælper hvis problemet gentages eller skal forklares til kunder.

2. Verificér filstien

Brug ps -fp PID og lsof -p PID til at tjekke filstien. Hvis filen ligger i webroden, undersøg applikationslogs. For WordPress: wp-content/debug.log, for server: access/error log, for PHP-FPM: slow log.

3. Forsøg først en blid afslutning

Send standard kill-signal:

kill PID

Vent et par sekunder og tjek om processen afsluttes i htop. Hvis ikke, og systemet er truet, brug:

kill -9 PID

Bemærk: kill -9 afslutter uden at processen får ryddet op. Brug ikke dette på database- eller backup-processer uden omtanke.

4. Finder processen sted igen, så find triggeren

Starter processen hurtigt igen, skyldes det ofte cron, systemd service, supervisor, webtrafik eller botangreb. Tjek crontab -l, systemctl status service, og access logs. For WordPress, tjek om wp-cron trigges af AJAX eller bots – overvej system cron og cache.

Kombinér htop fund med logs

htop viser hvad der bruger ressourcer – logs viser hvorfor. Kombiner disse for fuld diagnose. Eksempel: htop viser php-fpm bruger 180% CPU, men uden access log ved du ikke, om det skyldes et plugin, bot eller en fejl.

Typiske logs at tjekke:

• Webserver access log: Hvilke URLs får flest hits
• Webserver error log: PHP-fejl, filrettigheder, 500-fejl
• PHP-FPM slow log: Hvilke PHP-filer/funktioner er langsomme
• MySQL slow query log: Tunge SQL queries
• Auth log/secure log: Mistænkelige loginforsøg
• Cron log: Hvornår jobs køres

Hvis PID’en, der bruger meget CPU i htop, samtidig får tusindvis af hits på /wp-admin/admin-ajax.php i access log, skyldes det sandsynligvis et plugin, bot eller dårligt AJAX-design. Overvej WAF, rate limiting, cache og plugin-optimering. For bred performance-tjek, se websted hastighedsoptimering.

Hvordan skelner du mellem normal og kritisk resourceforbrug?

Ikke alt højt resourceforbrug er kritisk. Tag hensyn til hardware, trafik, applikationstype og vedligeholdelse. På en VPS med 2 kerner er load average på 6-8 i længere tid kritisk. På en 16-core dedikeret server kan samme load være normalt. Load average skal altid ses i forhold til kerneantal.

Brug denne sammenligning til at undgå unødig panik og fokusere på reelle performance-problemer. Især på shops under kampagner, betalingsintegrationer og lageropdateringer kan resourceforbrug stige midlertidigt – men hvis det påvirker brugeroplevelsen, bør du optimere både kode og serverkapacitet.

Sikkerhedsadvarsler: Kan resource-hungrende scripts være malware?

Scripts der bruger meget CPU/RAM er ikke altid blot fejl. Kompromitterede websites kan køre spam, cryptomining, proxy, DDoS bots eller bagdørscripts. htop kan afsløre mistænkelige processer under uventede brugere, mærkelige filnavne, binære filer fra /tmp eller PHP-filer i uploads – det bør tages alvorligt.

Tegn på kompromittering

• COMMAND med mærkelige eller tilfældige filnavne
• Processer fra /tmp, /dev/shm eller uploads
• Perl, python, bash scripts der normalt ikke bør køre
• Processer med mange eksterne netværksforbindelser
• Samme bruger starter mange processer hurtigt
• Webfiler med uautoriserede ændringer

Inden du afslutter processen, tag gerne output som dokumentation. Tjek filrettigheder, isolér malware, skift alle panel/CMS passwords, opdatér plugins og temaer, og kør sikkerhedsscanning. Brug 2-faktor login på adminpaneler og fjern unødige skrive-rettigheder for at minimere risikoen fremover.

Bedste praksis for at undgå gentagne performance-problemer

Det er vigtigt at finde problemprocessen med htop – men endnu vigtigere at sikre, det ikke gentager sig. Disse tips kan reducere CPU/RAM relaterede driftsstop markant:

• Tilpas memory_limit, max_execution_time og pm.max_children efter serverkapacitet
• Brug cache i WordPress, Joomla eller custom software
• Fjern unødige plugins, temaer, moduler
• Optimer tunge SQL-queries med MySQL slow query log
• Fordel cron jobs over tid, undgå at køre alt samtidigt
• Bekæmp bottrafik med rate limiting, robots.txt og firewall
• Rotér logs regelmæssigt – store logfiler kan spise disk/RAM
• Monitorér server-metrics kontinuerligt – ikke kun ved krise

Hvis ressourceforbruget stadig er højt efter optimering, skyldes det måske vækst i trafik eller applikation, eller hosting-pakken er utilstrækkelig. Her giver det mening at opgradere til en skalerbar VPS, mere RAM, hurtigere NVMe-disk eller dedikeret server med isolerede ressourcer. Overvej mulighederne på Hostingpakker og Virksomheds server løsninger.

Eksempelscenarie: CPU-krise på WordPress-site

Lad os tage et realistisk eksempel: Du har en VPS med 4 kerner og 8 GB RAM, hvor flere WordPress-sites kører. Brugere rapporterer langsomme sider og 502-fejl. Du åbner htop: load average ligger på 12, alle CPU-kerner er maxet ud, og du ser mange php-fpm processer for samme bruger i toppen.

Med F4 filtrerer du på brugernavn. Du noterer PID for den CPU-tunge proces. ps -fp PID viser php-fpm worker, lsof -p PID afslører adgang til /home/site/public_html/wp-content/plugins/example-importer/import.php. I access log ses gentagne AJAX requests og administrator-udløste importer på samme tidspunkt.

Løsningen: Stop importen, deaktiver pluginets scheduled job, del datamængden op, justér PHP max_execution_time, og brug system cron fremfor wp-cron. Load average falder fra 12 til 1,8, CPU normaliseres, og websvaret forbedres markant. Eksemplet viser at htop sammen med ps, lsof og loganalyse er meget effektivt.

Almindelige fejl ved brug af htop

• Kun at afslutte den øverste proces uden at undersøge årsagen
• At tro VIRT viser reelt RAM-forbrug
• At antage MySQL’s RAM-forbrug er et problem, når det blot er cache
• At bruge kill -9 som førstevalg
• At skyde skylden på applikation eller bruger uden loganalyse
• At tolke load average uden at kende kerneantal
• Ikke at kontrollere fil-integritet ved mistanke om sikkerhedsbrud

Ved at undgå disse fejl, minimerer du downtime og risiko for datatab. Den rigtige diagnose er ofte mere værd end hurtig indgriben.

Ofte stillede spørgsmål

Hvad kan htop på en Linux-server?

htop viser CPU, RAM, bruger, PID og kommando i realtid for alle processer. Det gør det let at spotte scripts, der overforbruger ressourcer.

Hvordan finder jeg CPU-tunge scripts med htop?

Sortér efter CPU% i htop, notér PID og USER for den langvarige top-proces, og brug ps -fp PID og lsof -p PID til at tjekke filstien og hvad der køres.

Skal jeg kigge på MEM% eller VIRT for RAM-analyse?

MEM% og især RES er mest relevante. VIRT viser allokeret virtuel memory, og er ikke nødvendigvis fysisk RAM-forbrug.

Er det korrekt straks at bruge kill -9 på resource-tunge processer?

Nej, det er bedre først at dokumentere processen, tjekke filstien, og forsøge standard kill PID. kill -9 bør kun bruges hvis processen ikke afsluttes og truer serverens stabilitet.

Er høj CPU-brug altid tegn på angreb i htop?

Nej, backup, import, cache eller trafikspikes kan også give højt CPU. Men mærkelige filnavne, processer fra /tmp/uploads og uventede brugere bør undersøges for sikkerhedsbrud.

Opsummeret: htop er et hurtigt og effektivt værktøj til at finde CPU- og RAM-hungrende scripts på Linux-servere. For det bedste resultat bør du kombinere htop med PID-analyse, lsof output, cron- og logkontrol. Gentagne resourceproblemer bør føre til både softwareoptimering og vurdering af serverkapacitet – og du kan sammenligne Hostragons’ hosting-, VPS- og SSL-løsninger uden købsræs for at finde den rigtige løsning til dit projekt.