Linux-server: met "htop" CPU- en RAM-slurpende scripts opsporen en aanpakken

Op een Linux-server is het commando htop één van de meest praktische tools om real-time scripts te ontdekken die de CPU en het RAM overmatig belasten. Door in het htop-venster de kolommen CPU%, MEM%, PID, USER, TIME+ en COMMAND te analyseren, zie je direct welke PHP-, Python-, Node.js-, cron-, database- of systeemprocessen je server zwaar belasten. Vervolgens kun je de eigenaar, bestandslocatie en het doel van het proces controleren en veilig ingrijpen.

Of je nu shared hosting, VPS, VDS of een dedicated server gebruikt: plotselinge traagheid wordt vaak veroorzaakt door scripts die ongecontroleerd resources verbruiken. Denk aan een foutieve WordPress-plugin, een PHP-bestand dat in een oneindige lus draait, een intensieve cron-job, niet-geoptimaliseerde databasequeries of gehackte webbestanden die binnen enkele minuten de CPU tot bijna 100% brengen. Bij toename van het RAM-gebruik kunnen diensten vastlopen, MySQL-verbindingen wegvallen, websites een 503-fout tonen of kan de Linux-kernel met de OOM Killer processen afsluiten.

In deze gids behandelen we stap voor stap hoe je htop installeert, het scherm leest, CPU- en RAM-slurpers herkent, het pad van een proces via de PID vindt en veilig ingrijpt. Ook bespreken we tips voor beveiliging, cron-controle, loganalyse en optimalisaties om herhaling te voorkomen. Als je regelmatig resourceproblemen hebt, kan het verstandig zijn om je hostingomgeving te herzien. Bekijk daarvoor onze VPS serverpakketten en Hoge prestaties web hosting pagina's.

Wat is htop en waarom is het handiger dan top?

htop is een interactieve terminaltool voor Linux-systemen om processen te monitoren. Het lijkt op het klassieke top-commando, maar biedt een duidelijker, kleurgecodeerd overzicht, eenvoudige sorteer-, zoek- en filterfuncties en procesbeheer. Daarom is het een favoriet hulpmiddel voor sysadmins om snel problemen op productieservers te diagnosticeren.

Met htop zie je onder andere live deze gegevens:

• CPU-gebruik per proces in procenten
• RAM-gebruik per proces in procenten en absolute hoeveelheid
• PID (proces-ID)
• De gebruiker die het proces uitvoert
• Commando of scriptnaam
• Totale looptijd en prioriteit van het proces
• Load average, totaal RAM, swap-gebruik en CPU-kerngebruik

In een hostingomgeving met meerdere websites, gebruikers en services op één server, is het niet genoeg om alleen het totaalverbruik te zien. Je moet weten welke gebruiker, website, cron-job of script de oorzaak van de problemen is. htop biedt hiervoor een snel eerste inzicht.

htop installeren: commando’s per distributie

Niet alle moderne Linux-distributies hebben htop standaard geïnstalleerd. Met root- of sudo-rechten is installatie vaak binnen enkele seconden klaar. Het bijwerken van de pakketlijst vooraf verkleint de kans op fouten, zeker bij nieuwe servers.

htop installeren op Ubuntu en Debian

Gebruik deze commando’s op Ubuntu- of Debian-servers:

sudo apt update

sudo apt install htop -y

Start htop daarna met het commando htop. Zonder sudo-rechten is het nodig om contact op te nemen met je hostingprovider. Bij een beheerde VPS heb je meestal wel roottoegang.

htop installeren op AlmaLinux, Rocky Linux, CentOS en RHEL

Op RHEL-gebaseerde systemen is de pakketbeheerder afhankelijk van de versie dnf of yum:

sudo dnf install htop -y

Voor oudere CentOS-versies moet EPEL-repository eerst toegevoegd worden:

sudo yum install epel-release -y

sudo yum install htop -y

Na succesvolle installatie opent htop een kleurenvriendelijk scherm. Als je nieuw bent met serverbeheer, helpt onze Linux commando's gids je op weg.

Het htop-scherm begrijpen: betekenis van kolommen

Bovenin het scherm zie je het gebruik van CPU-cores, RAM, swap, aantal taken, threads, load average en uptime. Daaronder staat een lijst met actieve processen. Voor troubleshooting zijn deze kolommen het belangrijkst:

Let op: een korte CPU-piek is niet per se een probleem. Acties zoals back-ups, cache-opruiming of druk verkeer kunnen tijdelijk het CPU-gebruik verhogen. Een echte storing herken je wanneer een proces minutenlang veel CPU of RAM slurpt, de load average ver boven het aantal cores komt en webservices traag of onbereikbaar worden.

CPU-slurpers opsporen met htop

Om scripts die de processor zwaar belasten te vinden, sorteer je in het htop-scherm op de CPU%-kolom. Druk op F6 om sorteeropties te openen of klik op de CPU%-titel als je muisondersteuning hebt. De bovenste processen zijn de grootste CPU-gebruikers op dat moment.

Stap 1: Sorteren op CPU%

Sorteren op CPU-gebruik geeft direct zicht op processen als php-fpm, php, python3, node, java, mysqld of bash die continu bovenaan staan. Op een single-core systeem is 100% normaal als maximum, op multi-core systemen kunnen waarden oplopen tot 200%, 400% of meer als meerdere cores gebruikt worden.

Stap 2: PID en USER noteren

Noteer het PID en de USER van verdachte processen. Bijvoorbeeld PID 24819, USER siteuser, COMMAND php /home/siteuser/public_html/wp-cron.php wijst vaak op een cron-job of WordPress-proces dat het probleem veroorzaakt. Is de COMMAND-kolom te kort? Zet dan in htop de optie aan om volledige commandoregel te tonen of gebruik het commando ps voor details.

Stap 3: Werkelijke commando opzoeken

Gebruik dit commando om de volledige commando-regel te zien:

ps -fp PID

Voorbeeld:

ps -fp 24819

Dit laat meestal zien welke scriptbestanden worden uitgevoerd. Bijvoorbeeld php /home/gebruiker/public_html/index.php is vaak een webverzoek, terwijl php /home/gebruiker/public_html/wp-content/plugins/verdacht-plugin/task.php wijst op een problematische plugin.

Stap 4: Bestandslocatie en open bestanden checken

Met lsof zie je welke bestanden het proces open heeft staan:

lsof -p PID

Dit toont onder andere bibliotheken, logbestanden en netwerkverbindingen. Zo kun je precies bepalen welke website-map actief is. Bijvoorbeeld een vreemd PHP-bestand in /home/example/public_html/wp-content/uploads kan duiden op een hack. Dan is afsluiten alleen niet genoeg: schoonmaken, wachtwoorden wijzigen, plugins updaten en een security scan uitvoeren is noodzakelijk. Voor SSL en veilige verbindingen bekijk je onze oplossingen voor SSL certificaat.

RAM-slurpers opsporen met htop

RAM-problemen zijn vaak sluimerender dan CPU-problemen. Een piek in CPU is meestal direct merkbaar, maar als RAM volloopt, kunnen services onverwacht stoppen, swap wordt intensief gebruikt en de server reageert traag. Sorteren op MEM% in htop laat je de grootste geheugenverbruikers zien.

MEM%, RES en swap begrijpen

htop toont MEM% standaard, maar je kunt ook kolommen voor VIRT, RES en SHR zien. Voor RAM-analyse is RES het belangrijkste: dit is de fysieke geheugengrootte die het proces echt gebruikt. VIRT toont virtueel geheugen en kan misleiden, omdat het ook niet-gebruikte reserveringen bevat.

Bijvoorbeeld: op een VPS met 4 GB RAM is 900 MB RES voor één PHP-proces abnormaal hoog. Een Node.js-app die groeit van 200 MB naar 1,5 GB wijst op memory leaks. Hoge RAM bij MySQL kan soms met cache te maken hebben, maar dan moet je ook query-prestaties, buffer-instellingen en totale servergeheugen meenemen in je analyse.

Typische oorzaken van hoog RAM-gebruik

• Oneindige loops in PHP-, Python- of Node.js-code
• Grote CSV-, XML- of JSON-bestanden volledig in RAM laden
• Niet-geoptimaliseerde WordPress-plugins en themafuncties
• Afbeeldingsbewerking, PDF-generatie of video-encoding
• Gebrek aan caching leidt tot herhaalde zware queries
• Veel gelijktijdige scripts door botverkeer of aanvallen
• Langdurige achtergrondservices met geheugenlekken

Alleen het proces met kill afsluiten geeft vaak tijdelijke verlichting. Voor een duurzame oplossing moet je achterhalen wat het script precies doet, welke triggers het heeft en waarom het geheugen niet vrijgeeft.

Zoeken, filteren en boomstructuur in htop

Met honderden processen wordt handmatig zoeken lastig. htop biedt handige sneltoetsen: F3 voor zoeken, F4 voor filteren en F5 voor boomweergave. De boomstructuur is handig om parent-child-relaties te zien, bijvoorbeeld php-fpm child-processen onder nginx/apache, cron-scripts of door supervisor beheerde Node.js-processen.

Handige filtervoorbeelden

• Typ php om alleen PHP-processen te zien
• Typ python voor Python-scripts
• Typ wp-cron om WordPress cron jobs te controleren
• Typ node voor Node.js-applicaties
• Filter op gebruikersnaam om processen van één hostingaccount te bekijken

Filters besparen tijd, zeker op multi-user servers met tientallen sites. Door USER en commandopad te combineren vind je snel welke account het probleem veroorzaakt. Voor domeinbeheer en registratiebevragingen zie onze Domeinsopzoeking en registratie pagina.

Veilig ingrijpen bij verdachte PID’s

Bij het vinden van een resourcevreter is het verleidelijk om direct kill -9 te gebruiken, maar dat kan dataverlies of inconsistente services veroorzaken. Een zorgvuldige aanpak is daarom belangrijk.

1. Proces documenteren

Noteer PID, USER, COMMAND, CPU%, MEM% en tijd. Maak eventueel een screenshot van htop. Dit helpt bij terugkerende problemen en is nuttig voor technische communicatie met klanten of collega’s.

2. Bestandslocatie bevestigen

Controleer met ps -fp PID en lsof -p PID het pad van het proces. Als het in de webroot staat, bekijk dan de logs van de toepassing. Voor WordPress bijvoorbeeld wp-content/debug.log, voor de webserver access- en error logs en voor PHP-FPM de slow logs.

3. Eerst netjes stoppen proberen

Stuur een standaard stop-signaal:

kill PID

Wacht enkele seconden en controleer in htop of het proces is gestopt. Blijft het hangen en schaadt het de server, gebruik dan als laatste redmiddel:

kill -9 PID

Deze harde stop geeft het proces geen kans op opruimacties en kan problemen veroorzaken bij database- of schrijfprocessen.

4. Trigger zoeken bij herstart

Start het proces binnen enkele seconden opnieuw? Dan is er waarschijnlijk een cron-job, systemd-service, supervisor, webrequest of bot die het triggert. Controleer cron met crontab -l, services met systemctl status servicenaam en webverkeer via access logs. Bij WordPress wp-cron moet je cron-instellingen en cachebeleid nalopen.

htop-resultaten combineren met logs

htop laat zien wat veel resources gebruikt, maar logs vertellen waarom. Zonder logs is de diagnose incompleet. Een proces met 180% CPU kan bijvoorbeeld veroorzaakt worden door duizenden verzoeken naar /wp-admin/admin-ajax.php in de webserver-access log, wat wijst op een plugin, bot of slecht ontworpen AJAX-call.

Belangrijke te controleren logs:

• Webserver access log: toont drukke URL’s
• Webserver error log: PHP-fouten, permissieproblemen en 500-fouten
• PHP-FPM slow log: traag werkende PHP-scripts en functies
• MySQL slow query log: zware SQL-queries
• Auth of secure log: verdachte loginpogingen
• Cron log: wanneer taken zijn uitgevoerd

Bij hoge CPU-belasting door specifieke URL’s kunnen maatregelen als WAF, rate limiting, caching en plugins optimaliseren helpen. Voor bredere optimalisatie bekijk je onze websites snelheid optimalisatie pagina.

Normale belasting versus probleem herkennen

Hoge resourceconsumptie is niet altijd een probleem. Serverhardware, verkeersvolume, applicatietype en onderhoud spelen mee. Bij een 2-core VPS is een langdurige load average van 6-8 een bottleneck, maar bij een 16-core dedicated server is dat normaal. Houd daarom bij het interpreteren van load average altijd rekening met het aantal CPU-cores.

Deze vergelijking helpt paniek te voorkomen en echte performanceproblemen te herkennen. Tijdens campagnes of piekperioden kan resourcegebruik tijdelijk stijgen, maar als dit de gebruikerservaring schaadt, moet je applicatie en servercapaciteit samen evalueren.

Beveiligingsrisico: kan een resourcevreter kwaadaardig zijn?

Een script dat CPU of RAM opslokt, hoeft geen onschuldige fout te zijn. Gehackte sites kunnen spam, cryptomining, proxyverkeer, DDoS-bots of backdoors draaien. Let op processen onder vreemde gebruikers, onlogische bestandsnamen in COMMAND, bestanden die draaien vanuit /tmp, /dev/shm of uploads-mappen. Ook ongewone Perl-, Python- of Bash-processen en processen met veel externe netwerkverkeer zijn verdacht.

Verdachte signalen

• Onbegrijpelijke of willekeurige bestandsnamen in COMMAND
• Bestanden die draaien vanuit tijdelijke of uploadmappen
• Onverwachte Perl-, Python- of Bash-processen
• Processen met hoge externe netwerkactiviteit
• Veel processen door dezelfde gebruiker in korte tijd
• Recent ongeautoriseerde wijzigingen aan webbestanden

Maak bij verdachte processen eerst screenshots en verzamel logbestanden als bewijs. Controleer bestandstoegang, isoleer verdachte bestanden, wijzig alle panel- en CMS-wachtwoorden, update plugins, thema’s en core en voer een beveiligingsscan uit. Twee-factor-authenticatie en het beperken van schrijfpermissies verkleinen toekomstige risico’s.

Beste praktijken om herhaling van performanceproblemen te voorkomen

Het opsporen van het probleem met htop is één ding; voorkomen dat het terugkomt is minstens zo belangrijk. De volgende maatregelen verminderen CPU- en RAM-gerelateerde storingen aanzienlijk op Linux-servers:

• Stel PHP-instellingen in zoals memory_limit, max_execution_time en pm.max_children passend bij servercapaciteit
• Gebruik caching in WordPress, Joomla en maatwerksoftware
• Verwijder onnodige plugins, thema’s en modules
• Optimaliseer zware queries met MySQL slow query logging
• Verspreid cron-jobs over tijd, voorkom tegelijk starten
• Beperk botverkeer met rate limiting, robots.txt en firewallregels
• Draai applicatielogs regelmatig om, voorkom gigantische bestanden
• Monitor servermetriek niet alleen bij problemen, maar structureel

Blijft resourcegebruik hoog ondanks optimalisaties, dan ligt het mogelijk aan toegenomen verkeer, groeiende applicaties of onvoldoende hostingpakket. In dat geval is een schaalbare VPS, meer RAM, snellere NVMe-schijf of een dedicated server met dedicated resources verstandig. Vergelijk opties op onze Hostingpakketten en zakelijke serveroplossingen pagina's.

Voorbeeldcase: CPU-piek bij een WordPress-website

Stel, je hebt een VPS met 4 cores en 8 GB RAM waarop meerdere WordPress-sites draaien. Gebruikers melden traagheid en sporadische 502-fouten. In htop zie je een load average van 12, alle CPU-cores maximaal belast, en veel php-fpm-processen van dezelfde gebruiker bovenaan.

Filter op de gebruikersnaam met F4 en noteer de PID van een CPU-intensief proces. Met ps -fp PID zie je een php-fpm worker, en lsof -p PID toont toegang tot /home/site/public_html/wp-content/plugins/example-importer/import.php. De access logs laten zien dat een beheerder dit bestand oproept, gevolgd door vele AJAX-aanroepen.

De oplossing is om het importproces te pauzeren, de geplande taak van de plugin uit te schakelen, grote import in stukken op te delen en de PHP max_execution_time aan te passen. Daarnaast wordt wp-cron vervangen door een systeemcronjob. Het resultaat: de load average daalt van 12 naar 1,8, de CPU-belasting normaliseert en de responstijden van de websites verbeteren duidelijk. Dit voorbeeld laat zien hoe krachtig htop kan zijn in combinatie met ps, lsof en loganalyse.

Veelgemaakte fouten bij het gebruik van htop

• Alleen het hoogste proces killen zonder de oorzaak te onderzoeken
• De VIRT-waarde verwarren met werkelijke RAM-consumptie
• MySQL-cachegebruik direct als probleem zien
• kill -9 als eerste optie gebruiken
• Logs negeren en direct de applicatie of gebruiker beschuldigen
• Load average interpreteren zonder rekening te houden met aantal CPU-cores
• Geen integriteitscontrole doen bij vermoedens van een hack

Het vermijden van deze fouten verkort downtime en voorkomt dat je onbedoeld data kwijtraakt. Een goede diagnose is vaak waardevoller dan een snelle maar ondoordachte actie.

Veelgestelde vragen

Wat doet het htop-commando op een Linux-server?

htop toont real-time informatie over processen, inclusief CPU- en RAM-gebruik, gebruikers, PID’s en commando’s. Zo kun je snel scripts vinden die je server zwaar belasten.

Hoe vind ik een CPU-intensief script met htop?

Sorteren op CPU%-kolom in htop en de PID en USER van de bovenste processen noteren. Daarna met ps -fp PID en lsof -p PID het scriptpad en details controleren.

Moet ik bij RAM-gebruik MEM% of VIRT% aanhouden?

MEM% en vooral RES geven een realistischer beeld van het werkelijke RAM-gebruik. VIRT is virtueel geheugen en kan misleiden.

Is het verstandig om een resourcevreter direct met kill -9 te beëindigen?

Meestal niet. Documenteer eerst het proces, controleer het pad en probeer eerst een normale kill PID. Gebruik kill -9 alleen als laatste redmiddel bij niet-reagerende processen die de server ernstig verstoren.

Is hoge CPU in htop altijd een teken van een aanval?

Nee. Back-ups, importtaken, cache-opbouw of druk verkeer kunnen de CPU tijdelijk verhogen. Maar vreemde bestandsnamen, scripts uit tijdelijke mappen en processen onder ongebruikelijke gebruikers kunnen een beveiligingsprobleem betekenen.

Samengevat is htop een snelle, praktische en effectieve eerste stap om CPU- en RAM-intensieve scripts op Linux-servers te vinden. Voor een volledige diagnose combineer je htop met PID-analyse, lsof, cron-controle en logbestanden. Bij terugkerende problemen is het slim om zowel software-optimalisaties als hostingcapaciteit te evalueren. Zo kies je zonder verkoopdruk via Hostragons hosting-, VPS- en SSL-oplossingen die perfect bij jouw project passen.