Een trage of niet-reagerende server diagnosticeren: stap voor stap
Kort antwoord
Loop de oorzaken in deze volgorde langs: CPU, geheugen, disk I/O, netwerk, en dan de logs. Elke laag sluit je snel uit met een of twee commando's, zodat je bij de echte oorzaak uitkomt in plaats van te gokken. Kom je na alle vijf stappen nog niet verder, dan is dat het moment om een supportticket te openen met wat je al hebt uitgesloten.
Voordat je verder zoekt: check op een bekend incident: Lijkt meer dan één dienst of server geraakt? Check dan eerst de statuspagina van het Network Operations Center. Is er een actief incident of gepland onderhoud, dan heb je meteen je antwoord en hoef je de stappen hieronder niet te doorlopen.
"De server is traag" kan van alles betekenen. Gokken kost tijd, en je neemt dan contact op met support zonder de informatie waarmee ze je sneller kunnen helpen. Deze volgorde vindt de oorzaak het snelst, omdat je elke stap snel kunt checken en die meteen een hele categorie uitsluit voordat je verdergaat.
1. Controleer eerst de CPU
Draai top of htop. Kijk naar de load average in verhouding tot je aantal cores, niet naar het losse getal: een load van 4 op een 2-core VPS is verzadigd, diezelfde load op een 16-core server valt nauwelijks op. Let op of er één proces op hol slaat, of dat de load gelijkmatig verdeeld is over meerdere processen.
Staat de CPU op zijn top: zoek het proces op en bepaal of dat verwacht is (een batchjob, een backup) of niet (iets wat niet zou moeten draaien). Is je VPS-plan echt te klein voor de workload, bekijk dan Signalen dat je uit je VPS bent gegroeid.
2. Controleer daarna het geheugen
Draai free -h. Een hoog getal bij "used" is op zich geen probleem, Linux gebruikt vrij RAM voor disk cache en geeft dat automatisch weer vrij. Waar het om gaat is swap-gebruik: als swap actief gebruikt wordt en blijft groeien, heeft de server echt te weinig geheugen, en dat alleen al kan alles traag laten aanvoelen, omdat swap veel trager is dan RAM.
Swap je zwaar, dan is een resize (meer RAM) meestal de directe oplossing. Zie Een Flexible VPS beheren voor hoe je resources aanpast.
3. Controleer de disk I/O
Draai iostat -x 2 (uit het sysstat-pakket) en let op %util en await. Een schijf die vastzit rond 100% utilisation, of await-tijden die oplopen tot tientallen milliseconden, wijst op storage als bottleneck, niet op CPU of geheugen.
Sluit eerst een defecte schijf uit voordat je uitgaat van simpele belasting: zie Een defecte schijf herkennen in Linux. Voor een dieper begrip van wat "traag" werkelijk betekent voor jouw storage tier, zie Storage benchmarken: IOPS, throughput en latency.
4. Controleer het netwerk
Zien CPU, geheugen en disk er allemaal goed uit, maar voelt de server toch traag aan om te bereiken, dan ligt het probleem misschien niet op de server zelf. Draai een traceroute vanaf de plek waar je verbinding maakt, en let op packet loss of een hop met een plotselinge sprong in latency. Zie Traceroutes & MTR's voor hoe je de output leest, en Een speedtest uitvoeren om een bandbreedteplafond uit te sluiten.
Is de server zelf onbereikbaar in plaats van alleen traag, controleer dan Netwerktopologie in Portal om te bevestigen dat de VPS of firewall waar hij achter zit ook echt in de staat is die je verwacht.
5. Lees de logs
Verklaren de eerste vier stappen niets, dan staat het antwoord meestal in een log die je nog niet hebt bekeken: het log van de applicatie zelf, dmesg voor gebeurtenissen op kernelniveau (zoals een proces dat OOM-killed is, wat een geheugenprobleem achteraf verklaart), of het access log van je webserver voor een piek in verkeer. Zie Serverlogs lezen en centraliseren voor waar je moet zoeken en hoe je logs van meerdere servers op één plek verzamelt.
Nog steeds vast? Open een ticket met wat je hebt uitgesloten
Een ticket met "server is traag" duurt langer om op te lossen dan een ticket met "CPU en geheugen zijn normaal, disk await loopt op tot 40ms op het datavolume, hier is de iostat-output." Voeg toe wat je bij elke stap hebt gevonden, zie Een supportticket aanmaken voor wat je verder nog moet meesturen en hoe je een prioriteit kiest.
Vermoed je een compromise, niet alleen traagheid?: Onverwachte CPU-piekjes, onbekende processen, of uitgaand verkeer dat je niet kunt verklaren, kunnen er ook op wijzen dat de server gecompromitteerd is in plaats van simpelweg overbelast. Lijkt iets hier verdacht in plaats van gewoon traag, stop dan en lees eerst Wat te doen als je server is gecompromitteerd voordat je verdergaat.