Videre til indhold 
Gennemsnitlig belastning viser, hvor mange processer der kører eller venter på CPU-tid – ikke hvor høj CPU-udnyttelsen er i procent. Hvis man læser værdien uden kontekst, reagerer man ofte med panik eller foretager forkerte opgraderinger. Jeg forklarer, hvordan jeg fortolker værdien korrekt og træffer fornuftige hostingbeslutninger på baggrund heraf.
Centrale punkter
- Ingen CPU%: Load tæller processer i køen.
- Pr. kerne Tænk: Del belastningen med kerneantallet.
- I/O-ventetid belastningen ofte større end CPU'en.
- 1/5/15-Minutters gennemsnit udjævner spidserne.
- Sammenhæng Før handlinger: Tidspunkt, job, trafik.
Hvad load average egentlig måler
Jeg læser værdien som det gennemsnitlige antal Processer, der kører aktivt i 1, 5 og 15 minutter eller venter i køen. Mange forveksler det med CPU-belastning i procent, men måleren kender kun køer, ikke regnetid. En belastning på 1,0 betyder vedvarende fuld udnyttelse på et enkeltkernet system, mens den samme værdi forbliver afslappet på fire kerner. Derfor sammenligner jeg altid belastningen relativt i forhold til kerneantal og vurder først derefter, om der er tale om en reel overbelastning. Det 15-minutters gennemsnit viser tendenser og hjælper mig med at skelne mellem kortvarige spidsbelastninger og vedvarende belastninger.
Hvorfor høje værdier ofte viser I/O-problemer
Der kan opstå en høj belastning, selvom CPU'en næsten ikke arbejder – I/O-køer blokerer da Tråde. Jeg kontrollerer andelen %wa (I/O-Wait) med top eller htop og ser med iotop, hvilke processer der bremser lageret. Ofte er langsomt reagerende databaser, backup-jobs eller overbelastede netværksdrev årsagen. Hvis %wa stiger, hjælper en CPU-opgradering ikke meget; hurtigere storage, caching og færre sync-flushes har større effekt. Artiklen giver en god uddybning af emnet. Forstå I/O-ventetid, som jeg bruger, når ventetiden er lang.
Misforståelse: Load er det samme som CPU-udnyttelse
Jeg skelner strengt mellem procentværdier for CPU og load average som kømetrik. En load på 8 på en 8-core server kan være normal, hvis alle kerner arbejder og intet venter. Det bliver kritisk, når belastningen ligger betydeligt over antallet af kerner, og samtidig stiger 15-minutters-kurven. For at se sammenhænge lægger jeg CPU%, I/O-ventetid, scheduler-tider og proceslister ved siden af hinanden. Først samspillet mellem disse signaler forklarer mig, om maskinen beregner, blokerer eller blot behandler mange kortvarige jobs.
Placer spidserne korrekt i stedet for at slå alarm
Korte belastningsspidser fra Cron, logrotation eller sikkerhedskopieringer er en del af hverdagen og betyder ikke automatisk Fejlfunktion. Jeg vurderer altid tidspunktet på dagen, varigheden og 15-minutters-grænsen, før jeg udløser alarmer eller tilføjer kapacitet. Jeg skalerer tærskler med kerneantallet, f.eks. alarm først ved belastning > 2× kerner i flere minutter. Uregelmæssige spidsbelastninger i content management-systemer tjekker jeg desuden for baggrundsopgaver; til WordPress passer følgende bemærkning WP-Cronjobs og belastning. På den måde undgår jeg blinde reaktioner og prioriterer foranstaltninger, der har en nytteværdi.
Læs Load Average i den daglige hosting
Jeg starter med uptime for at få et hurtigt overblik og åbner derefter htop, for at se processer, CPU-fordeling, RAM og I/O. Hvis belastningen i løbet af 15 minutter forbliver høj, søger jeg efter syndere med iotop eller pidstat. Ved databasebelastede arbejdsbelastninger kontrollerer jeg forespørgselsforsinkelser, indekser og cache-hits. På webservere ser jeg, om der er for mange samtidige PHP-arbejdere, der venter, eller om OpCache griber ind, hvis det er nødvendigt. Denne rutine adskiller symptomer fra årsager og sparer mig for dyre, ineffektive hardwareopgraderinger.
| Metrikker | Hverdagsliv | Advarselssignal (4 kerner) | Næste skridt |
|---|---|---|---|
| Indlæs 1 min | <4 | >8 over 3–5 min | Kontroller de vigtigste processer |
| Indlæsning 15 min. | <3 | >6 stigende | Planlæg kapacitet/arkitektur |
| CPU% | <80% | >95% permanent | Optimer kode/arbejder |
| I/O-ventetid | <10% | >20% Spidser | Kontroller opbevaring/caching |
Værktøjer til ren hostingovervågning
Jeg kombinerer Metrikker fra agenter med logfiler og spor for at finde årsagerne hurtigere. Til tidsserier bruger jeg Prometheus eller alternative indsamlere, visualiseret i Grafana. Infrastrukturmæssigt hjælper Zabbix mig med kontroller og fleksible alarmregler samt SaaS-tjenester til hurtige dashboards. Det er vigtigt at have et ensartet overblik over belastning, CPU%, RAM, swap, disk-latens og netværk. Uden en fælles tidslinje forbliver fortolkningen af belastningsværdier fragmentarisk.
| Kategori | Eksempel | Styrker |
|---|---|---|
| Åben kilde | Zabbix | Kontroller, agent, alarmlogik |
| Tidsserier | Prometheus | Pull-model, PromQL |
| visualisering | Grafana | Dashboards, alarmer |
| SaaS | Datadog | Integrationer, APM |
Optimering ved vedvarende høj belastning
Jeg begynder med den største smerte: langsom Forespørgsler, blokerende I/O-stier eller for mange samtidige arbejdere. Databaseindekser, forbindelsespuljer og forespørgselscacher som Redis eller Memcached reducerer ventetiden mærkbart. På applikationsniveau aflaster jeg kilden: caching af sider, fragmenter og objekter samt ren købehandling. På systemet indstiller jeg vm.swappiness passende, tjekker Huge Pages og sætter fornuftige grænser for tjenester. Først når softwaresiden er udtømt, skalerer jeg vertikalt (mere RAM/CPU) eller horisontalt (flere instanser med Load Balancer).
Load Average på multi-core-systemer
Jeg beregner altid belastningen i forhold til Kerner: Load 16 kan være okay på 16 fysiske kerner. Hyper-Threading fordobler de logiske CPU'er, men den reelle ydeevne følger ikke altid lineært; derfor vurderer jeg også latenstiderne. I containere eller VM'er spiller CPU-andele, CFS-kvoter og begrænsninger ind, hvilket tilsyneladende forvrænger „normale“ værdier. Et kig på CPU-throttling og scheduler-ventetider adskiller hårde begrænsninger fra reelle kapacitetsproblemer. For at træffe klare beslutninger hjælper 15-minutters-kurven mig som trendanker.
Shared hosting, naboer og skjulte flaskehalse
I delte miljøer har indflydelsen fra naboer ofte stærkere end din egen app. Derfor overvåger jeg også CPU-steal, ready-tider og storage-contention for at opdage ekstern belastning. Hvis kerner bliver „stjålet“, stiger belastningen trods dine egne optimeringer. Som beslutningsgrundlag bruger jeg vejledningen til CPU-stjålet tid og planlægger dedikerede ressourcer efter behov. På den måde sikrer jeg planerbar ydeevne i stedet for at blive hængende i en flaskehals.
Indstil trends, tærskler og alarmer korrekt
Jeg kalibrerer tærskler pr. Kerne og indstiller hysterese, så alarmer ikke udløses ved hver eneste spidsbelastning. For 4 kerner starter jeg alarmer ved en belastning på > 8 over flere minutter og bekræfter med en 15-minutters tendens. Vedligeholdelsesvinduer og batch-tider udelader jeg fra vurderingen, så diagrammerne ikke fortæller forkerte historier. Derudover bruger jeg afvigelsesdetektering i forhold til vores egen historiske median i stedet for at fastsætte faste værdier. På den måde reagerer jeg tidligt på reelle ændringer uden at trætte teamet med falske alarmer.
Hvordan Linux virkelig tæller belastningen
Jeg kigger under hætten, hvis det er nødvendigt: Kernen beregner længden af køen og tæller ikke kun aktivt kørende tråde (tilstand „R“), men også dem i uafbrudt søvn („D“, oftest I/O-ventetilstand). Det er netop dette, der forklarer høje belastningsværdier ved lav CPU-udnyttelse: mange tråde blokerer i kernen på langsomme diske, netværks- eller NFS-adgange. I /proc/loadavg Jeg ser de tre gennemsnit og derudover „kørende/samlede“ tråde samt den sidste PID. Zombier spiller ingen rolle her, men kernel-tråde og bruger-tråde indgår i lige høj grad. På systemer med mange kortvarige opgaver (builds, worker) svinger 1-minutsværdien naturligvis mere, mens 15-minutsværdien forbliver min stabilitetsanker.
For mig er det vigtigt at oversætte „belastning“ til „ventetid“: Hvis belastningen ligger betydeligt over kerneværdien, dannes der køer. Det behøver ikke være dårligt, hvis det drejer sig om kortvarige opgaver, men hvis ventetiden for forespørgsler samtidig stiger, går systemet i overbelastning. Derfor betragter jeg altid belastning sammen med Runtime-metrikker (Req-Latency, ttfb) for at evaluere køer ikke kun ud fra tal, men også ud fra effekt.
Hukommelsespres, swap og skjulte blokeringer
Jeg ser ofte konstant høje belastningsværdier ved hukommelsestryk. Når sidecachen krymper eller kswapd flytter sider, går processer i ventetilstand. Swapping genererer I/O og bremser alt. Jeg tjekker vmstat (si/so), Major Page Faults, /proc/meminfo (Cached, Dirty, Writeback) og observer, om I/O-latenserne stiger samtidig. Høj belastning ved moderat CPU% og stigende disk-„await“ er for mig et klart tegn på, at der mangler RAM, eller at datasættet ikke passer i cachen.
Jeg reagerer i flere trin: først identificerer jeg RAM-hotspots (f.eks. store sorteringer, ikke-cachelagrede forespørgsler, enorme PHP-arrays), derefter styrker jeg caches og vm.swappiness indstilles således, at arbejdshukommelsen ikke fortrænges for tidligt. Det er sjældent klogt at slukke for swap helt – en lille, hurtig swap (NVMe) med disciplineret brug forhindrer OOM-killer-peaks. Hvis writebacks bliver en flaskehals, afbøder jeg sync-bølger (batching, journaling-optioner, asynkrone flushes) og reducerer samtidige writers.
Containere, Cgroups og CPU-throttling
I containere fortolker jeg Load med henblik på cgroups. CFS-kvoter begrænser CPU-tiden pr. periode; når grænsen nås, viser containeren fortsat høje belastningsværdier, selvom den blot begrænset bliver. Jeg tjekker cpu.max (cgroup v2) eller. cfs_quota_us/cfs_periode_us (v1) og gashåndtagstælleren (cpu.stat). Hvis „throttled_time“ stiger, er årsagen ikke manglende regnekraft, men hårde begrænsninger. I Kubernetes skelner jeg strengt mellem „Requests“ (planlægning) og „Limits“ (begrænsninger) – forkert indstillede begrænsninger skaber kunstige køer.
CPU-affinitet og NUMA påvirker også billedet: Hvis tråde fastgøres til få kerner eller parkeres på en NUMA-node, kan belastningen ophobes lokalt, mens global CPU% ser okay ud. Jeg fordeler hot-threads målrettet, kontrollerer IRQ-balancing og sørger for, at containere ikke alle presses på de samme fysiske kerner. På den måde reducerer jeg ventetider uden at opgradere hardware.
Checkliste for hurtige beslutninger
- Load i forhold til Kerner vurdere (belastning/kerner ≈ 1 god, ≫1 kritisk).
- CPU% og I/O-ventetid modsætte sig: regner kassen eller venter den?
- 15 minutter-Kontroller tendensen: vedvarende overbelastning vs. kortvarig spidsbelastning.
- Top-processer og tilstande (R/D/S/Z); mange D-tilstande = I/O-flaskehals.
- Disk-latenser, Queue Depth og %util måle; NFS/netværksstier medtjekke.
- RAM: Sidefejl, swap-aktivitet, kswapd – afhjælp hukommelsespres.
- Grænser Kontroller i containere/VM'er: kvoter, delinger, stjæling, begrænsning.
- Samtidighed begrænse: arbejdere/tråde, køer, modtryk.
- Spidsbelastning flytte: Cron, sikkerhedskopier, indekser, ETL.
- Justering, måle igen – effekt før hardware.
Konkrete eksempler på tuning fra hosting
På web-/PHP-stacks er Samtidighed den største løftestang. Jeg sætter realistiske pm.max_børn, så anmodninger ikke overbelaster databasen samtidigt. I nginx eller Apache begrænser jeg samtidige upstream-forbindelser, aktiverer Keep‑Alive på en fornuftig måde og lader statiske aktiver cache aggressivt. OpCache forhindrer warmup-storm, mens en objektcache (Redis/Memcached) reducerer query-belastningen markant.
Når det gælder databaser, begynder jeg med Indeksering og planer. I stedet for blindt at øge antallet af forbindelser bruger jeg forbindelsespuljer og begrænser samtidige dyre forespørgsler. Jeg overvåger bufferpulje-hitratioer, ventetider for låsning og temp-table-spills. Store rapporter eller migreringsopgaver kører asynkront og i batches – hellere en konstant 60%-belastning end 5 minutter med 200% og derefter stilstand.
For hukommelseskrævende processer (f.eks. billed-/videobehandling) definerer jeg en øvre grænse for samtidige jobs pr. vært. Jeg indstiller nice og ionice, så batch-processer ikke ødelægger interaktive latenstider. På hurtige NVMe-diske holder jeg scheduler-konfigurationen slank, sørger for tilstrækkelig kødybde og undgår chatty-syncs. Så forsvinder D-state-laviner, og belastningen falder uden at CPU% stiger – maskinen venter simpelthen mindre.
Kør build- og batch-workloads efter en plan
Ved kompilering eller rendering korrelerer belastningen stærkt med Job-paralleliteter. Jeg vælger -j Bevidst: Kerner × (0,8–1,2) er en god start, men jeg henviser til RAM En – hellere færre parallelle jobs, der er stabile, end swap-storme med belastningsspidser. Artefakt-caches, inkrementelle builds og dedikerede I/O-volumener forhindrer, at D-tilstande fylder køen med mange små filer.
Jeg planlægger batch-vinduer med lav belastning. Rotationer, backups, ETL og reindexing kører forskudt, ikke alt på hele timen. Arbejdsqueues får backpressure: Kun nye jobs, når der er ledige slots, i stedet for blot at „fire-and-forget“. På den måde forbliver belastning og latenstider kontrollerbare, og spidsbelastninger bliver forudsigelige.
PSI: Pressure Stall Information som et tidligt varslingssystem
Ud over den klassiske Load bruger jeg Oplysninger om trykstop (PSI) fra Linux til /proc/pressure/cpu, .../io og .../hukommelse. PSI viser, hvor lang tid opgaver tager kollektivt måtte vente – ideelt til overbelastning tidligt . Hvis CPU-presset stiger i løbet af få minutter, selvom CPU% er moderat, ved jeg, at køen er overbelastet. Ved I/O-presset kan jeg se, om lagerforsinkelser påvirker hele systemet, selvom enkelte iotop-værdier ser harmløse ud.
Jeg kombinerer PSI med 15-minutters-belastningen: Hvis begge stiger, er der reel mætning. Hvis kun belastningen stiger, men PSI forbliver stabil, kører der muligvis mange korte jobs, som brugerne ikke mærker. Dette resulterer i klarere alarmer og bedre beslutninger: Hæv grænser, udjævn jobs eller forstærk hardware målrettet dér, hvor der er målbare flaskehalse.
Kort oversigt til at tage med
Jeg læser Belastning Aldrig isoleret, men i sammenhæng med kerner, I/O-ventetid, CPU% og 15-minutterskurven. Jeg tolker høje værdier først efter at have set på lager- og netværkslatenser, da det ofte er her, den egentlige bremsen ligger. Når det gælder foranstaltninger, prioriterer jeg synlige virkemidler: forespørgsler, caching, arbejdere, begrænsninger – først derefter hardware. I delte miljøer undersøger jeg parasitære effekter som steal og planlægger dedikerede ressourcer, hvis det er nødvendigt. Med disse regler træffer jeg rolige, solide beslutninger og holder hosting-opsætninger pålidelige og hurtige.
