Come tutti sappiamo, un carico di 1,00 su un singolo processore significa che c'è un carico del 100% . Analogamente, un carico di 4,00 su un quad core sarebbe del 100% .
Come devo interpretare il caricamento su un processore a 4 thread a 8 core? Quando raggiungo la capacità massima della CPU? Alle 4.00 o alle 8.00 ?
Risposte:
Non sicuramente, ma soprattutto 1.00*n_cpu.
Il carico significa quanto segue: se ci sono più processi su un sistema a CPU singola, sembrano funzionare in parallelo. Ma non è vero. Cosa succede praticamente: il kernel dà 1/100 di secondo a un processo, quindi interrompe il suo funzionamento con un interrupt. E fornisce il prossimo 1/100 di secondo 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. È chiamato come pianificazione delle attività .
Naturalmente, i processi che sono bloccati, ad esempio in attesa dei loro dati, ciò che stanno leggendo dal disco, sono esenti da questa pianificazione delle attività.
Cosa dice il carico: quanti processi stanno attualmente aspettando il loro prossimo 1/100 di secondo intervallo di tempo. Certo, è un valore medio. Questo perché puoi vedere più numeri in a cat /proc/loadavg.
La situazione in un sistema multi-CPU è un po 'più complessa. Esistono più cpus, i cui intervalli di tempo 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 ciò (ci sono cose minori di ottimizzazione, ad esempio è meglio se un processo verrà eseguito il più lungo tempo possibile sullo stesso cpu a causa di considerazioni sulla cache, ma non contano lì). Questo perché se abbiamo caricato 8, ciò significa che in realtà ci sono 8 processi in attesa del prossimo intervallo di tempo. Se abbiamo 8 cpus, possiamo dare questi intervalli di tempo al cpus uno a uno, e quindi il nostro sistema verrà utilizzato in modo ottimale.
Se vedi a top, puoi vedere che il numero degli attuali processi in esecuzione è sorprendentemente basso: sono i processi contrassegnati da Rlì. Anche su un sistema non proprio hardcore è spesso inferiore a 5. Ciò è in parte dovuto al fatto che anche i processi in attesa dei loro dati dai dischi o dalla rete sono sospesi (contrassegnati con Sin alto). Il carico mostra solo l'utilizzo della cpu.
Ci sono strumenti per misurare anche il carico del disco, quindi dovrebbero essere almeno importanti come il monitoraggio dell'utilizzo della cpu, ma in qualche modo non è così noto qui nel nostro mondo dei sistemi di gestione professionale.
Gli strumenti di Windows spesso dividono il carico con il numero effettivo del cpus. Questo fa sì che alcuni amministratori di sistemi Windows professionisti utilizzino il caricamento del sistema in questo senso diviso per CPU. Non hanno ragione e probabilmente saranno più felici dopo aver spiegato loro questo.
Le CPU multicore sono praticamente più CPU sullo stesso chip di silicio. Non c'è differenza.
Nel caso di CPU hyperthreaded c'è un effetto collaterale interessante: il caricamento di una cpu rallenta le sue coppie hyperthreaded. Ma ciò 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 punto di vista attuale - ciò che determina il carico del sistema - non importa.
Dato che 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 è sconosciuto da qualche parte tra circa 4 e 6
(ovviamente questo può aumentare se sovraccaricato perché conta effettivamente i processi eseguibili, in particolare quando sono in attesa di IO)
Il carico medio 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 è a causa di molte cose che vogliono CPU, ma non sempre. Un colpevole comune è un processo in attesa di IO - disco o rete.
Prova a eseguire ps -e ve cercare 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 è dalla psmanpage, quindi puoi trovare maggiori dettagli lì - Re i Dprocessi sono probabilmente di particolare interesse.
Puoi finire con "picchi" medi di carico per una serie di motivi, quindi non sono in realtà una buona misura di qualsiasi cosa diversa da "è questo sistema occupato". Impantanarsi nella mappatura della media del carico sui core della CPU non ti farà bene.
Su un sistema Linux non vengono conteggiati solo i processi nella coda eseguibile per calcolare il carico, ma anche quelli in stato di sonno ininterrotto, wikipedia , che fanno aumentare il carico quando si hanno molti processi in attesa del disco.
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 si ottiene l'equivalente di 48 core di throughput. Quello che ho osservato è che si ottiene circa il 90% della velocità effettiva nei primi 24 processori logici, ovvero se il carico viene eseguito su 24.0. Quindi si ottiene 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 si eseguono 48 thread sui 24 core, si otterrà un aumento di circa il 10-20% se si abilita l'hyperthreading rispetto al contrario. Non è una spinta al 100% come implicherebbero i ragazzi del marketing.
Ad esempio, un modo per testare questa osservazione è avere un processo che esegue 48 thread (ad esempio utilizzando TBB o modello di threading manuale), quindi eseguire
time numactl --physcpubind=0-23 ./myprocess
e poi corri
time numactl --physcpubind=0-47 ./myprocess
Quest'ultimo dovrebbe funzionare in circa il 10-20% in meno di tempo. Se il processo è fortemente bloccato su I / O, il risultato potrebbe essere diverso.
Il primo disabiliterà l'hyperthreading consentendo ai thread di essere eseguiti solo su un singolo processore logico (di ciascun core), mentre il secondo consentirà l'hyperthreading consentendo ai thread di essere eseguiti su 2 processori logici (di ciascun core).
Il carico in entrambi i casi dovrebbe essere segnalato come 48.0 ... che come puoi vedere è molto fuorviante.