Soluzione 1:
Non sicuramente, ma soprattutto il 1.00*n_cpu .
Il carico significa quanto segue:se ci sono più processi su un sistema a singola CPU, stanno funzionando apparentemente in parallelo. Ma non è vero. Cosa succede praticamente:il kernel concede 1/100 di secondo a un processo, quindi ne interrompe l'esecuzione con un interrupt. E assegna il centesimo di secondo successivo a un altro processo.
Praticamente la domanda "quale processo dovrebbe ottenere il nostro prossimo intervallo di 1/100 di secondo?", sarà decisa da una complessa euristica. Si chiama task programmazione .
Naturalmente, i processi che sono bloccati, ad esempio stanno aspettando i loro dati che stanno leggendo dal disco, sono esenti da questa pianificazione delle attività.
Cosa dice il carico:quanti processi stanno attualmente aspettando il loro prossimo intervallo di tempo di 1/100 di secondo. Ovviamente è un valore medio. Questo perché puoi vedere più numeri in un cat /proc/loadavg .
La situazione in un sistema multi-cpu è un po' più complessa. Esistono più cpu, i cui tempi possono essere assegnati a più processi. Ciò rende la pianificazione delle attività un po' più complessa, ma non troppo. Ma la situazione è la stessa.
Il kernel è intelligente, cerca di condividere le risorse di sistema per l'efficienza ottimale, ed è vicino a questo (ci sono cose di ottimizzazione minori, ad esempio è meglio se un processo verrà eseguito il più a lungo possibile sullo stesso cpu a causa di considerazioni sulla memorizzazione nella cache, ma non hanno importanza lì). Questo perché se abbiamo il carico 8, ciò significa:in realtà ci sono 8 processi in attesa della loro prossima fascia oraria. Se abbiamo 8 cpu, possiamo assegnare questi intervalli di tempo alla cpu uno a uno, e quindi il nostro sistema verrà utilizzato in modo ottimale.
Se vedi un top , puoi vedere che il numero dei processi attualmente in esecuzione è sorprendentemente basso:sono i processi contrassegnati da R là. Anche su un sistema non proprio hardcore è spesso inferiore a 5. Ciò è in parte dovuto al fatto che anche i processi in attesa dei propri dati dai dischi o dalla rete sono sospesi (contrassegnati con S in alto). Il carico mostra solo l'utilizzo della cpu.
Esistono anche strumenti per misurare il carico del disco, secondo me dovrebbero essere almeno importanti quanto il monitoraggio dell'utilizzo della cpu, ma in qualche modo non è così noto qui nel nostro mondo professionale di amministratori di sistema.
Gli strumenti di Windows spesso dividono il carico con il numero effettivo di CPU. Ciò fa sì che alcuni amministratori di sistema Windows professionisti utilizzino il carico di sistema in questo senso diviso per CPU. Non hanno ragione e saranno probabilmente più felici dopo che glielo spiegherai.
Le CPU multicore sono praticamente più CPU sullo stesso chip di silicio. Non c'è differenza.
Nel caso di CPU hyperthreaded c'è un interessante effetto collaterale:il caricamento di una cpu rende le sue coppie hyperthreaded più lente. Ma questo accade a un livello più profondo di ciò che gestisce la normale pianificazione delle attività, sebbene possa (e dovrebbe) influenzare le decisioni di spostamento del processo dello scheduler.
Ma dal nostro attuale punto di vista - ciò che determina il carico del sistema - non ha importanza.
Soluzione 2:
La media del carico non significa ciò che pensi significhi. Non si tratta dell'utilizzo istantaneo della CPU, ma piuttosto di quanti processi sono in attesa di essere eseguiti. Di solito questo perché molte cose richiedono CPU, ma non sempre. Un colpevole comune è un processo in attesa di IO - disco o rete.
Prova a eseguire ps -e v e alla ricerca di flag di stato del processo.
state The state is given by a sequence of characters, for example, "RWNA". The first character indicates the run state of the process:
D Marks a process in disk (or other short term, uninterruptible) wait.
I Marks a process that is idle (sleeping for longer than about 20 seconds).
L Marks a process that is waiting to acquire a lock.
R Marks a runnable process.
S Marks a process that is sleeping for less than about 20 seconds.
T Marks a stopped process.
W Marks an idle interrupt thread.
Z Marks a dead process (a "zombie").
Questo è dal ps manpage, quindi puoi trovare maggiori dettagli lì - R e D processi sono probabilmente di particolare interesse.
Puoi finire con "picchi" medi di carico per tutti i tipi di motivi, quindi non sono davvero una buona misura di qualcosa di diverso da "questo sistema è occupato". Impantanarsi nella mappatura della media del carico sui core della CPU non ti farà bene.
Soluzione 3:
Poiché l'hyperthreading non è in realtà un secondo core, non porterà mai un core al 200%, ma lo porterà oltre il 100% per determinati carichi di lavoro.
Quindi il tuo carico massimo è da qualche parte sconosciuto tra circa 4 e 6
(ovviamente questo può salire più in alto quando è sovraccarico perché in realtà conta i processi eseguibili, in particolare quando sono in attesa di IO)
Soluzione 4:
Su un sistema Linux non solo i processi nella coda eseguibile vengono conteggiati per calcolare il carico, ma anche quelli in stati di sospensione ininterrotti, wikipedia, causando picchi di carico quando si hanno molti processi in attesa del disco.
Soluzione 5:
Ho fatto alcuni esperimenti sul nostro sistema Xeon a 24 core (2 socket x 12 core). Il carico massimo è 48.0 in questo caso a causa del modo in cui Linux imposta l'hyperthreading.
Tuttavia, non ottieni l'equivalente di 48 core di throughput. Quello che ho osservato è che ottieni circa il 90% del throughput nei primi 24 processori logici, ovvero se il carico viene eseguito a 24.0. Quindi ottieni un throughput aggiuntivo di circa il 10% per i restanti 24 processori logici (il carico viene eseguito a 48,0). Un altro modo di pensarci è che se esegui 48 thread sui 24 core, otterrai un aumento di circa il 10-20% se abiliti l'hyperthreading anziché no. Non è una spinta del 100% come vorrebbero dire i ragazzi del marketing.
Ad esempio, un modo per testare questa osservazione è disporre di un processo che esegue 48 thread (ad esempio utilizzando TBB o modello di threading gestito a mano), quindi eseguire
time numactl --physcpubind=0-23 ./myprocess
e poi esegui
time numactl --physcpubind=0-47 ./myprocess
Quest'ultimo dovrebbe funzionare in circa il 10-20% in meno di tempo. Se il tuo processo è fortemente I/O bloccato, il risultato potrebbe essere diverso.
Il primo disabiliterà l'hyperthreading consentendo l'esecuzione dei thread solo su un singolo processore logico (di ciascun core), mentre il secondo abiliterà l'hyperthreading consentendo l'esecuzione dei thread su 2 processori logici (di ciascun core).
Il carico in entrambi i casi dovrebbe essere riportato come 48.0 ... che come puoi vedere è molto fuorviante.