Sådan overvåger du Linux-serverens ydeevne: kommandoer, målinger og værktøjer

For at overvåge en Linux-servers ydeevne skal du tjekke fire ressourcer: CPU, hukommelse, disk-I/O og netværk. Brug indbyggede kommandoer som top, vmstat, free, iostat og ss til live-fejlfinding, og et agentbaseret værktøj som Prometheus med node_exporter, Zabbix eller CloudWatch-agenten til at gemme historik og sende alarmer.

Vigtigste pointer

• Tjek udnyttelse, mætning og fejl for hver ressource (USE-metoden). Høj udnyttelse alene er ikke et problem; køer og fejl er.
• Sammenlign load average med antallet af CPU-kerner, og hold øje med %wa (I/O wait) og %st (steal time) på cloud-VM'er.
• For hukommelse skal du læse kolonnen available i free, ikke free. Linux bruger bevidst ledig hukommelse som cache.
• Pressure stall information i /proc/pressure/ viser direkte, hvor meget tid opgaver venter på CPU, hukommelse eller I/O.
• Kommandoer viser nuet. Til tendenser og alarmer har du brug for en overvågningsagent og et time series-lager.

Hvilke ydeevnemålinger i Linux er vigtige?

Start med USE-metoden af performance-ingeniøren Brendan Gregg: Tjek udnyttelse, mætning og fejl for hver ressource. Den giver dig en tjekliste i stedet for gætværk.

Hvordan tjekker du CPU-forbrug og load i Linux?

Kør top (eller htop), og læs CPU-linjen. Sammenlign derefter load average med antallet af kerner fra nproc.

top # live-visning; tryk 1 for at vise hver kerne
nproc # antal CPU-kerner
uptime # load average over 1, 5 og 15 minutter
mpstat -P ALL 1 # forbrug pr. kerne hvert sekund (sysstat-pakken)

Ifølge manualsiden proc_loadavg tæller load average de jobs, der kører eller venter på disk-I/O, som gennemsnit over 1, 5 og 15 minutter. En load på 6 på en server med 8 kerner er fin. En load på 6 på en server med 2 kerner betyder, at arbejdet står i kø. Fordi load også omfatter processer, der venter på disken, peger høj load med lavt CPU-forbrug som regel på et storage-problem.

I CPU-linjen i top er to felter vigtige på cloudservere:

• wa: tid, hvor CPU'en stod ledig og ventede på I/O. Vedvarende høje værdier peger på langsomme diske eller netværksstorage.
• st: ifølge manualsiden for top "time stolen from this vm by the hypervisor". Vedvarende steal på en cloud-VM betyder, at værten er optaget, eller at en burstable instans har brugt sine CPU-kreditter op.

Hvordan tjekker du hukommelsesforbruget i Linux?

Kør free -h, og læs kolonnen available. Manualsiden for free definerer den som et estimat af den hukommelse, der er tilgængelig til nye applikationer uden swapping, med page cache medregnet.

free -h # hukommelsesoversigt i læsbart format
vmstat 1 5 # kolonnerne si/so viser swap ind/ud pr. sekund
journalctl -k | grep -i "out of memory" # hændelser fra OOM killer

En server med lidt "free" men rigeligt "available" hukommelse er sund: Linux fylder ledig RAM med diskcache og frigiver den, når programmer har brug for den. Advarselstegn er faldende available-hukommelse over dage (en mulig lækage), konstant swap-aktivitet i vmstat og OOM killer-poster i kernel-loggen.

Hvordan tjekker du diskens ydeevne og plads?

Brug iostat -xz 1 til I/O-ydeevne og df til plads og inodes.

iostat -xz 1 # udnyttelse, kø og latens pr. enhed (sysstat)
df -h # diskplads pr. filsystem
df -i # inode-forbrug: mange små filer kan fylde dem først
du -sh /var/log/* | sort -h # find ud af, hvad der bruger pladsen

I iostat skal du holde øje med r_await og w_await (gennemsnitlige millisekunder pr. forespørgsel) og aqu-sz (køens længde). Manualsiden for iostat bemærker, at %util for enheder, der behandler forespørgsler parallelt, som RAID-arrays og moderne SSD'er, ikke afspejler deres ydelsesgrænser. Stigende latens og kølængde er bedre tegn på mætning.

Hvordan overvåger du netværkets ydeevne?

sar -n DEV 1 # gennemløb pr. interface
sar -n TCP,ETCP 1 # TCP-forbindelser og retransmissioner
ss -s # oversigt over sockets
ip -s link # fejl og tabte pakker pr. interface

Stigende retransmissioner, tabte pakker eller interface-fejl tyder på netværksproblemer, selv når gennemløbet ser normalt ud. På cloud-VM'er skal du sammenligne gennemløbet med instanstypens netværksgrænse.

Hvad er pressure stall information (PSI)?

PSI er en kernefunktion, der rapporterer, hvor meget tid opgaver bruger på at vente på CPU, hukommelse eller I/O. Kernel-dokumentationen forklarer, at hver fil i /proc/pressure/ har en "some"-linje (andelen af tiden, hvor mindst nogle opgaver er stoppet) og for hukommelse og I/O en "full"-linje (alle ikke-inaktive opgaver er stoppet på samme tid, hvilket kernen beskriver som thrashing).

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

PSI besvarer direkte, om en ressource bremser arbejdet, og det gør den til et godt alarmsignal. Hvis filerne ikke findes, er din kerne bygget eller startet uden PSI-understøttelse.

Hvilke værktøjer skal du bruge til løbende overvågning?

Kommandoer viser, hvad der sker nu. For at fange problemer om natten, se tendenser og alarmere den rette person skal du installere en overvågningsagent, der sender målinger til et time series-lager.

Hvilke alarmer skal du sætte først?

1. Diskplads og inodes over 80-85 % på ethvert filsystem, med en prognosealarm for "fuld inden for 24 timer".
2. Lav tilgængelig hukommelse i mere end 10 minutter eller enhver hændelse fra OOM killer.
3. Load average over antallet af kerner i mere end 15 minutter eller stigende CPU-pressure.
4. Disklatens eller I/O-pressure langt over serverens normale baseline.
5. Servicetjek: Applikationens port svarer, og en health-URL returnerer succes.
6. Backup og certifikatudløb, som fejler i det stille.

Disse tærskler er udgangspunkter. Tilpas dem til hver servers normale adfærd, så alarmerne forbliver brugbare. Vores guide til overvågning af serverens ydeevne dækker Windows og generel praksis, og overvågning af cloudinfrastruktur dækker managed services ud over serveren.

Sådan hjælper Opsio

Opsio overvåger og driver Linux-servere på AWS, Azure og on-premises som en del af vores managed it-services, inklusive 24/7 alarmrespons, patching og kapacitetsgennemgange, med Prometheus og Grafana eller cloud-native værktøjer. AWS-platformen, vi byggede til WorkBuster, kører for eksempel på EC2-instanser i en auto scaling-gruppe med CloudWatch-dashboards og -alarmer til den daglige drift.

Ofte stillede spørgsmål

Hvad er den bedste kommando til at tjekke en Linux-servers ydeevne?

Start med top for et live-overblik, derefter vmstat 1 for tendenser i CPU, hukommelse og swap og iostat -xz 1 for diskene. Tilsammen viser de de fleste flaskehalse på under et minut.

Hvad er en god load average for en Linux-server?

Det afhænger af antallet af CPU-kerner. En load average på eller under antallet af kerner betyder som regel, at der ikke er kø. Vedvarende load over antallet af kerner betyder, at opgaver venter på CPU eller disk.

Hvorfor viser Linux næsten ingen ledig hukommelse?

Linux bruger ubrugt RAM som diskcache og afgiver den, når applikationer har brug for den. Tjek i stedet kolonnen available i free -h; det er den hukommelse, der reelt er tilgængelig til nyt arbejde.

Hvordan ser jeg, hvilken proces der bruger mest CPU eller hukommelse?

I top trykker du på P for at sortere efter CPU og M for at sortere efter hukommelse. Fra et script kan du bruge ps aux --sort=-%cpu | head eller ps aux --sort=-%mem | head.

Hvordan overvåger jeg en Linux-server eksternt?

Installér en agent som node_exporter, Zabbix-agenten eller CloudWatch-agenten, og send målinger til en central server eller cloudtjeneste. Så får du historik, dashboards og alarmer uden at logge ind på hver maskine.