Prosessoren viser hundre prosent: spørsmålet før du leser et tall

Tre ulike tall bærer samme navn: gjennomsnittet siden oppstart, den oppsamlede summen og forskjellen mellom to avlesninger. Bare det siste besvarer "akkurat nå".

AtlasPVE ·

Denne artikkelen svarer på

  • proxmox høy cpu-bruk
  • proxmox hvilken prosess bruker cpu
  • hva er load average
  • lese utdata fra top
  • proxmox cpu på 100 prosent

Du ser på panelet, og prosessoren virker hardt belastet. Før du gjør noe, finnes det ett eneste spørsmål: hvilken periode beskriver dette tallet?

For tre ulike tall bærer samme navn, og de tre sier forskjellige ting.

Tre tall med samme navn

Gjennomsnittet siden oppstart. Var maskinen travel i tre dager for to måneder siden, sitter den travelheten fortsatt i dette gjennomsnittet. Det besvarer ikke "akkurat nå".

Den oppsamlede summen. Den synker aldri. Den forteller om fortiden, ikke om i dag.

Forskjellen mellom to avlesninger. To målinger tas, og endringen mellom dem leses. Bare denne besvarer "akkurat nå".

Den klassiske fellen

Standardverktøyet som lister prosesser, viser på første skjerm gjennomsnittet siden oppstart. Ser du på den første skjermen og handler, har du grepet inn i fortiden og ikke i dagen i dag.

Riktig vei er å ta minst to avlesninger og lese den andre. Verktøyet i seg selv tar ikke feil; måten det leses på gjør det.

Den samme feilen tar samme form overalt

Den formen har vi allerede sett to ganger i denne wikien.

Om diskslitasje sa vi ikke prosenten, men stigningen: åttifem prosent igjen betyr ti år på én disk og åtte måneder på en annen.

Om tapte pakker sa vi ikke summen, men raten: en maskin som hadde én dårlig time i fjor, blir av telleren vist som skyldig livet ut.

For prosessoren gjelder ikke gjennomsnittet, men forskjellen. Tre ulike steder, én lesefeil.

Det kan skrives som en allmenn regel: et tall uten angitt tidsvindu er ingen måling. Spør, før du handler på et tall, hvilket vindu det dekker.

Når prosessoren virkelig er høyt belastet

Da trengs et andre skille: er det én maskin som er travel, eller er det tjeneren som ikke strekker til?

At en virtuell maskin bruker hele andelen den har fått, er normalt. Ga du den to kjerner og den har fylt de to kjernene, virker systemet nøyaktig som tenkt.

Problemet er øyeblikket da tjeneren mettes: gjestene slutter å få det de ber om, og alle blir tregere samtidig.

Og noe forveksles ofte: last er ikke prosessorbruk. Last teller ting som venter, og noen av dem venter ikke på prosessoren, men på disken. Det er mulig at lasten er høy mens prosessoren står stille, og det sier deg at du skal se et annet sted.

Hva Atlas gjør

Når Atlas lister tjenerens mest prosessorsultne prosesser, tar det bevisst to avlesninger og leser den andre.

Grunnen er nettopp fellen over: den første avlesningen bærer gjennomsnittet siden oppstart, og å vise den ville villede. Forskjellen er ingen bagatell; en liste sortert på den første avlesningen framstiller en prosess som var travel for måneder siden, som dagens skyldige.

Enda en liten, men ærlig detalj: resultatet av målingen lagres kort, og forespørsler som kommer samtidig, knyttes til én enkelt måling. Grunnen: mens kortet er åpent, oppdateres det med noen sekunders mellomrom, og å starte en ny måling ved hver oppdatering belaster tjeneren unødig.

Det er det samme prinsippet som i artikkelen om varme: det som iakttar, bør ikke være det som koster.

Kilder

Proxmox sin egen dokumentasjon. På engelsk, og den har siste ord i denne saken.

Relaterte artikler

Hvordan ser dette ut inne i Atlas?

Gå til produktsiden