Vad är normal Load average?

Har en VN maskin som ibland har en Load average på 42.. Enligt htop så ligger alla CPU på 100%, men maskinen känns dock inte slö..

Load average bör inte överskrida antalet fysiska CPU-kärnor (räkna alltså inte virtuella cores, t ex via hyperthreading) över tid.

Om du har mindre än 42 fysiska cores så är din VM rejält överbelastad.

Load average presenteras med tre värden.
Den första är medel för senaste minuten
Den andre är medel för de senaste 5 minutrarna.
Den tredje är medel för de senaste 15 minutrarna.

Varje heltal är hur många kärnor som varit belastade.
Så en loadavg på 1.0 när man har två kärnor/trådar i en maskin betyder att man nyttjar 50% av sin cpu kraft.
En loadavg på 1.0 när man har en 12 kärnor/trådar betyder att man har en belastning på ca 8%
(du kan kolla antal trådar i en maskin med kommandot *nproc*)

htop som du nämner presenterar i realtid. dvs vad den gör för sekunden.

Säger htop att du kör 100% på alla kärnorna så rekommenderar jag att du kollar loadavg.
ligger loadavg på en bra nivå så betyder det att det är en temporär cpu spik, det kan vara att en tjänst håller på att starta.

Men om loadavg (alla 3 värdena 1min,5min,15min) samtliga ligger på samma värde som antal trådar du har i datorn så kan det betyda att du har en process som hängt sig i en infinite loop eller att du har ett aldeles för klen server för vad du gör.


Angående att servern inte känns slö beror nog sannorlikt på att schemaläggaren gör sitt job.
Den märker att det är någon process som försöker ta alla resurser men väljer att sortera ut resurserna till alla processer som körs.


Sen angående att din loadavg ligger på 42.. - du råkar inte vara så att du glömde nollan och punkten innan? 0.42 låter mer rimligt än en 42.0 (så vidare du inte har 42+ trådar i maskinen)

I sammanhanget bör man tänka på att hyperthreading (i Intel-fallet) presenteras som ”riktiga” CPU-kärnor för operativsystemet, trots att det är en teknologi för att utnyttja pipelinen effektivare.

Intel själva säger att detta ger mellan 15-30% av kapaciteten hos en fysisk CPU-kärna.

Om den totala CPU-belastningen ligger över 70% över en längre tid så är risken stor att det inte finns någon ledig kapacitet över, trots att det ser ut som om att 30% är tillgängligt.

Det finns så många sätt att mäta CPU-load på att det är lite knepigt att jämföra siffrorna.
Ännu mera knepigt är det om det är virtuella maskiner som ska jämföras.

Varje tråd och/eller process behöver inte vara tidskritisk till sin natur.
Device drivers behöver dock oftast designas utifrån tidskritikalitetens natur.

Servrar kan ofta köras på uppåt 90 -97 % av sin kapacitet om de tex har 16 kärnor.
Då finns det nästan alltid tillräckligt med CPU-cykler kvar ändå för operativsystemets kärnverksamheter att den inte känns seg och laggar.

Det måste också finnas tillräckligt med diskprestanda för att de ska klara av de uppgifter man sätter på den.

Servrar är ju förutsägbara om vad de ska klara av vad gäller söktider, svarstider osv.
Och oftast körs ju enbart dessa serverprogramvaror på dessa maskiner.
En server är alltså långtifrån lika dynamisk vad gäller belastningen som tex en PC har.
Och förstås att nätverksanslutningen blir oftast den viktigaste flaskhalsen.
Den kan ju inte designen påverka, utan man får hoppas att det ligger inom ramen för vad man kan tolerera.

Redan en relativt lågt belastad Windows 10 maskin har > 50 trådar igång, men ganska många av dem är i "sleep mode", och som bara väntar på input.

Det är ett ganska knepigt problem att konstruera jämförelsemallar som är rättvisande tyvärr.
Man får sätta sig in vad det är som man vill mäta, och vilka metoder man vill använda.

Inget går dock upp mot äkta testkörningar, men dessa kan ju göras utefter så många parametrar numera att man blir lite vilsen.

Those are rookie numbers.

Har haft 96 load average på 12 fysiska kärnor.

Vill du ha en hög load average så gör något som går snabbt att göra och inte går mot disk.

https://serverfault.com/questions/1091220/load-average-greater-than-number-of-cpus

Den VM har haft en LA på över 100... Men den känns aldrig långsam, förutom via apache då. Men det är inte som när man kör direkt på hårdvaran, att man få vänta flera minuter på respons på ett kommando via ssh. Maskinen i sej är ganska snabb den har 16 Cores med 32 trådar

Ett tag låg denna VM konstant på 100% när man kollade den på övervaknings sidan. Det är MySQL som dra iväg, många SQL förfrågningar. Men lyfte bort den webbplasten som hade många SQL frågor , då blev det bättre.

Dessa siffror är egentligen bara ett slags hypotetiska mätvärden. Eftersom det inte finns så många vedertagna sätt att mäta en maskins prestanda på. Eller ja man kan konstruera många sådana sätt att mäta på, men då behöver man nog många olika kärror att testa på.
Det är rena djungeln det där med optimering osv.


Ähum, det verkar ju som att din VM är felkonfigurerad i grund och botten.
Eller så är mätvärdet beräknat på fel sätt, typ ?
Prova att tilldela mera RAM och fler kärnor. Minst fyra kärnor bör du ha.

Har du mycket diskaktivitet så lönar det sig att stoppa in en disk till.
Det brukar hjälpa en hel del.

Men tittar du från hostens (värdens) sida, i dess taskmanager så ska det se ut som att din VM-process tar upp allt som den tilldelats.
Det är också det som menas med en VM, eller hur ?
Att VM-en tar upp 100 % av vad den tilldelats alltså.
Vilket annat OS som helst tar ju upp alla resurser i sin fysiska maskin.

Det är dock en mycket intressant fråga därför att virtualiserade miljöer är värdefulla att köra simuleringar på. Man kan tex ta fram en ny CPU-modell, men då bara som en simulerad CPU. Med sådana simulerade CPU-er och med lite trix på styrspakarna så kan man få en uppfattning om hur mycket prestanda en sådan kommer att få.
Ifall man väljer att låta den gå till tillverkning alltså.

Utifrån hostens (värdens) sida så är din VM precis som vilket annat program som helst, och i hostens Task Manager så ser du vanligen inte att den tar 100 % av din host.
I så fall lär det straxt gå trögt som sirap.
Inträffar detta, så kan man sätta ner "execution cap" till under 90 %, det brukar hjälpa.
Med "execution cap" menas alltså ett tak på hur andelen av hur många CPU-cykler din VM får lägga beslag på.

Man kan också begränsa bandbredden på nätverket som din VM utnyttjar.
Ja, det är krångligt det här, men tyvärr mycket att lära sig och
man blir aldrig fullärd på detta.

Tilldelar du mera RAM till din VM än vad som finns fysiskt i din host då lär det snabbt bli stora problem, så snart du kör ett minneshungrigt program i din VM. Och din host kommer att swappa vid nästan varje minnesaccess som din VM vill göra.
VMen tänker utifrån sin horisont att den har tex 32 GB ram och då kommer hela VM att anta att alla dessa GBs finns som fysiskt RAM.
Det finns mycket beskrivet om do´s and don´ts när det gäller VMs.
Vet dock ej så noga vilka bra sammanfattande skrifter det finns om hur man ska designa host och guest. Väldigt mycket onödigt jobb kan undvikas då.

Alltså lita inte på load average i komplexa miljöer.

Om läsarna här inte förstår det ovanstående beskrivna så är det precis så som det ska vara - det är inte så lätt att teoretiskt lära ut dessa basics.
Blir ju lite lättare med praktiska försök.

VM har 12 kärnor tilldelade av 16 möjligt.. Jag antar man inte skall använda HT. Man kan dock Virtualsering miljön ställa in om den skall använda socket eller core, men det gör väl ingen skillnad? SMP som SMP?

Minnet har den gott om , slå aldrig i taket. Men htop 100% ibland.

Jag vet ju inte vilken maskin TS kör och vad den är tänkt att göra. TS skriver VN maskin men menar antagligen en VM.
Om det är Virtual Box du kör så har den väl inte så mycket maskinvaruacceleration som
man skulle önska. VM Ware har flera sådana möjligheter.

HT avslagen eller påslagen, tja, det är väl hugget som stucket. Låt HT stå påslagen, dina program är väl redan optimerade för HT ändå ?

Och det beror på moderkortet om det är ett dual socket eller inte, det är ju en viss skillnad mellan kommunikationen mellan CPUerna på en dual socket jämfört med att kärnorna kommunicerar med varandra.

Jag vet inte vad du vill åstadkomma, men det är bara att prova sig fram.

Och htop visar väl då och då 100 %. Ja om man ska vara petig så om man inkluderar idle processes, så bör (ska) den visa 100 % hela tiden. Tex då i Windows så om man inkluderar waitforevent processen eller vad den heter så blir alltid belastningen 100 %.
Men sätts tex en kärna i sleep mode så visst då kan man kalla det att belastningen är mindre än 100 % då.
Det blir lite hårklyverier om vad som kan kallas resursutnyttjande ändå.

Jag tror att du får leta vidare. Och prova dig fram. Men det verkar helt överdrivet att tilldela 12 virtuella kärnor i din VM.
Du vet ju inte hur din virtualiseringsprogramvara kommer att tilldela maskinresurserna ändå.
Det blir ju gott om förlorade CPU-cykler i all virtualisering som det förstås blir.

Och för lite med bara 4 fysiska kärnor för hosten.

Om htop finns mycket att läsa vad den kan lämna för värdefull information.

Det är alltid ett träsk av möjliga konfigurationer. De flesta lägger inte ner ett större jobb på att optimera annat än att man är nöjd med det.

BUMP ! - Inte vet jag hur långt TS kommit med sitt testande, men här kommer några idéer.
Du får sätta in snabbare diskar för det är väl antagligen där det brister. Om du inte är nöjd med svarstiderna.

Mera RAM brukar ju också hjälpa men svårt att veta vad det är för maskin.


Den VM som du kör ser väl antagligen inte att du har HT påslagen ändå, så för din VM spelar det väl ingen roll. Men ha HT påslagen alltid det är ju en fiffig metod.
Har du 4 kärnor för hosten kvar bör den väl kunna klara allt viktigt ändå, om du inte kör ytterligare en massa (onödiga) program så att du får problem med att allokera minne, eller diskprestandan blir lidande.

Kanske någon här är bättre på htop/Linux och om du kan posta en skärmbild så någon här på FB kan kolla att det ser helt normalt ut ?

Teorin om operativssystemen ger att ett OS alltid lägger beslag på all kapacitet, dvs ett OS tar alltid 100% sammanlagt.
Och att det är OSet som tilldelar slices till de program som ska köras via taskschedulern som lägger processerna i kö.

Detta är mycket lättare att se på riktigt långsamma maskiner, men tyvärr är det väl inte många datanördar som har sådana kvar.

70 % i load på en enkärnig maskin är ingen panik, det ska den klara. Förutsatt att fläktkylningen är helt okej och fri från damm.
På mångkärniga maskiner kan load gå upp till typ 95-97 % och maskinen känns ändå snabb på att svara på user input.

Det stycket fick mig att minnas Pentium4 samt CoreDuo -tiden.
Skillnaden när man gick från en singel kärna till en med dubbla kärnor/trådar.

Det var helt underbart att kunna stänga ett program som hade låst sig.