Quanti Switch di contesto è "normale" (in funzione dei core della CPU (o altro))?

34

Ciao Linux / UNIX Overlords,

Qualcuno di voi ha una regola empirica su quanti switch di contesto (per core del processore) è normale su un server Linux?

Il mio college qui l'ha allevato e sta vedendo 16K su una x86_64macchina a 8 core .

Ecco alcune statistiche di sarface negli ultimi giorni ...

testo alternativo http://src.autonomy.net.au/imagebin/81895e338fae67d3d205c09db44a81e6-Picture_10.png

E per vedere le statistiche di creazione del processo, ecco una vista logaritmica dello stesso grafico ...

testo alternativo http://src.autonomy.net.au/imagebin/7481f7e52bead4effc90248fc23c72fe-Picture_11.png

E gli 8 core sono annoiati a morte ...

testo alternativo http://src.autonomy.net.au/imagebin/0e94326652e977fd74edcd840f94200f-Picture_12.png

CS vs IOwait (scala x10000)

testo alternativo http://src.autonomy.net.au/imagebin/a52a2a8a120394849c0da4045933e306-Picture_13.png

Ulteriori informazioni inutili nel caso qualcuno chieda ..

La memoria su cui lavora il server è una SAN da 0,5 TB tramite FC
Ci sono 8 GB di RAM, principalmente cache - nessuno scambio.

linux performance context-switch

— Serse
fonte

1

In un periodo particolare?

— dmckee,

Puoi essere più specifico sul carico di lavoro?

— dmo

1

Come hai realizzato quel grafico? Sembra davvero carino!

— Antoine Benkemoun,

Ciao Antoine - I grafici sono fatti da sarface ( projects.autonomy.net.au/sarface )

— Serse

i collegamenti del grafico sono morti al momento. @Xerxes puoi arrivarci da qualche parte?

— törzsmókus,

25

Questo dipende molto dal tipo di applicazione che esegui. Se disponi di applicazioni che sono syscalls WRT molto felici di innescare, puoi aspettarti di vedere grandi quantità di cambio di contesto. Se la maggior parte delle applicazioni è inattiva e si riattiva solo quando si verificano problemi su un socket, è possibile che si verifichino basse velocità di commutazione del contesto.

Chiamate di sistema

Le chiamate di sistema causano cambi di contesto per loro stessa natura. Quando un processo fa una chiamata di sistema, in pratica dice al kernel di prendere il posto del momento e della memoria attuali per fare cose che il processo non ha il privilegio di fare e tornare allo stesso punto quando è fatto.

Quando guardiamo la definizione di syscall write (2) da Linux, questo diventa molto chiaro:

NOME
       write - scrive su un descrittore di file

SINOSSI
       #includere 

       ssize_t write (int fd, const void * buf, size_t count);

DESCRIZIONE
       write () scrive fino a contare i byte dal buf puntato al buffer nel file
       a cui fa riferimento il descrittore di file fd. [..]

VALORE DI RITORNO
       In caso di successo, viene restituito il numero di byte scritti (zero indica
       non è stato scritto nulla). In caso di errore, viene restituito -1 e viene impostato errno
       appropriatamente.
       [..]

Questo in sostanza dice al kernel di riprendere l'operazione dal processo, passare ai countbyte, a partire dall'indirizzo di memoria indicato dal *bufdescrittore fddi file del processo corrente e quindi tornare al processo e dirgli come è andato.

Un bell'esempio per dimostrarlo è il server di gioco dedicato per i giochi basati su Valve Source, hlds . http://nopaste.narf.at/f1b22dbc9 mostra un syscalls del valore di un secondo eseguito da una singola istanza di un server di gioco che non aveva giocatori. Questo processo richiede circa il 3% del tempo CPU su un Xeon X3220 (2.4Ghz), solo per darti un'idea di quanto sia costoso.

Multitasking

Un'altra fonte di cambio di contesto potrebbe essere i processi che non eseguono i syscall, ma devono essere spostati da una determinata CPU per fare spazio ad altri processi.

Un bel modo per visualizzarlo è cpuburn . cpuburn non fa alcun syscalls in sé, scorre solo sulla propria memoria, quindi non dovrebbe causare alcun cambio di contesto.

Prendi una macchina inattiva, avvia vmstat ed esegui un burnMMX (o qualsiasi altro test dal pacchetto cpuburn) per ogni core della CPU che ha il sistema. A quel punto dovresti avere un pieno utilizzo del sistema ma quasi nessun aumento del cambio di contesto. Quindi prova ad avviare qualche altro processo. Vedrai che la velocità di commutazione del contesto aumenta man mano che i processi iniziano a competere sui core della CPU. La quantità di commutazione dipende dal rapporto processi / core e dalla risoluzione multitasking del kernel.

Ulteriori letture

linfo.org ha una bella descrizione di quali sono gli switch di contesto e le chiamate di sistema . Wikipedia ha informazioni generiche e una bella raccolta di collegamenti sulle chiamate di sistema.

— Michael Renner
fonte

1

Questo è stato utile - mi hai dato un'ottima idea! =)

— Serse

1

La tua affermazione System calls cause context switches by their very own naturesembra sbagliata. Le chiamate di sistema causano il cambio di modalità come indicato da linfo.org/context_switch.html

— Nicolas Labrot

6

il mio server web moderatamente caricato si trova a circa 100-150 switch al secondo il più delle volte con picchi in migliaia.

Le alte percentuali di cambio di contesto non sono esse stesse un problema, ma possono indicare la strada a un problema più significativo.

modifica: i cambi di contesto sono un sintomo, non una causa. Cosa stai cercando di eseguire sul server? Se si dispone di una macchina multiprocessore, è possibile provare a impostare l'affinità della CPU per i processi del server principale.

In alternativa, se stai eseguendo X, prova a scendere in modalità console.

modifica di nuovo: a 16k cs al secondo, ogni CPU ha una media di due interruttori per millisecondo, ovvero da metà a un sesto della fascia oraria normale. Potrebbe essere in esecuzione un sacco di thread associati a IO?

modifica di nuovo post grafici: Sicuramente sembra legato a IO. il sistema trascorre la maggior parte del suo tempo in SYS quando i cambi di contesto sono alti?

modifica ancora una volta: alto iowait e sistema nell'ultimo grafico - eclissando completamente lo spazio utente. Hai problemi di I / O.
Quale carta FC stai usando?

modifica: hmmm. qualche possibilità di ottenere alcuni benchmark sull'accesso alla SAN con bonnie ++ o dbench durante i tempi morti? Sarei interessato a vedere se hanno risultati simili.

modifica: ci ho pensato durante il fine settimana e ho visto schemi di utilizzo simili quando Bonnie sta eseguendo il passaggio "scrivi un byte alla volta". Ciò potrebbe spiegare la grande quantità di commutazione in corso, poiché ogni scrittura richiederebbe una scala di sistema separata.

— jay_dubya
fonte

Non sono ancora convinto che un alto tasso di cambio di contesto non sia un problema, sto parlando di alti come in 4K a 16K, non 100-150.

— Serse

Nessuno dei nostri server esegue alcuna X. Sono d'accordo con te sul problema di attesa IO e sulla relazione tra questo e il CS. La scheda HBA non è un sospetto perché usiamo la stessa carta su altri cento server ... La conclusione è che incolpo i maledetti EVA SAN dei team SAN che cercano disperatamente di difendere continuamente. Si noti che un'alta IO-wait non è sempre motivo di allarmarsi, se la maggior parte dei processi su una macchina sono associati a IO, si prevede che il server non avrà niente di meglio per fare questi giri di inattività.

— Serse

Al secondo però, il quarto grafico allegato mostra che non è così vicino come pensavo all'inizio. Non è esattamente un'eclissi. Dico ancora la colpa alla SAN. =)

— Serse

1

Sono più propenso a preoccuparmi del tasso di occupazione della CPU dello stato del sistema. Se è vicino al 10% o più, ciò significa che il tuo sistema operativo impiega troppo tempo a fare i cambi di contesto. Anche se spostare alcuni processi su un'altra macchina è molto più lento, merita di farlo.

1

Cose come queste sono le ragioni per cui dovresti provare a mantenere le prestazioni di base per i tuoi server. In questo modo, puoi confrontare cose che noti all'improvviso con cose che hai registrato in passato.

Detto questo, ho server in esecuzione (server Oracle non molto occupati, principalmente), che sono fissi intorno a 2k con alcuni picchi di 4k. Per i miei server, questo è normale, per i server di altre persone che potrebbero essere troppo bassi o troppo alti.

Quanto lontano puoi tornare indietro nei tuoi dati?

Che tipo di informazioni sulla CPU puoi fornirci?

— wzzrd
fonte

Sono assolutamente d'accordo nel mantenere una linea di base e abbiamo dati sui nagios che risalgono a lungo - il problema con questo server è che è nuovo sangue - è in circolazione da poco tempo. Inoltre, sta eseguendo il software aziendale (leggi: merda) - Teamsite - solo per aggiungerlo all'elenco delle variabili indefinite. Preferisco ancora sar (preferenza personale), quindi lo configurerò per mantenere più del valore predefinito (2 settimane) e vedrò come va.

— Serse

L'uso di sar in combinazione con rrdtool (da cui sembra che provengano i tuoi grafici) può essere un mezzo semplice per conservare i tuoi dati (o almeno i loro abstract) per molto tempo.

— wzzrd,

0

Non esiste una regola empirica. Un interruttore di contesto è solo la CPU che passa dall'elaborazione di un thread a un altro. Se esegui molti processi (o alcuni di quelli altamente threaded) vedrai più switch. Fortunatamente, non devi preoccuparti di quanti cambi di contesto ci sono: il costo è piccolo e più o meno inevitabile.

— Alex J
fonte

6

In realtà il costo di un cambio di contesto è costoso . Questo è ancora peggio per le macchine virtuali: alcuni mesi fa abbiamo effettuato alcuni test che dimostravano che una delle principali cause delle prestazioni della VM era il cambio di contesto.

— Serse

In effetti, in qualsiasi sistema operativo moderno (multi-tasking), la minimizzazione del cambio di contesto è un compito di ottimizzazione molto significativo. Hai qualche fonte per sostenere la tua affermazione che il costo è piccolo?

— Serse

Spiacenti, stai parlando di ridurre al minimo i cambi di contesto dal punto di vista dello sviluppo del sistema operativo? Non avendo nulla a che fare con tale sviluppo, non ho alcuna opinione sui vantaggi della progettazione di un sistema per ridurre al minimo CS :) Se stai parlando di minimizzare gli switch di contesto su un server, il problema è mitigare gli switch di contesto introduce la latenza in altri luoghi. Ad esempio, ridurre il numero di processi su una macchina significa che è necessario spostare questi processi su un'altra macchina, il che significa che la comunicazione avviene su una rete, che è molto più lenta!

— Alex J,

Credo che la tua definizione di cambio di contesto sia errata; si verificano anche quando viene eseguita una chiamata di sistema, anche se ritorna allo stesso thread. Le applicazioni ottimizzano contro questo facendo vari trucchi. Ad esempio, Apache deve ottenere molto spesso l'ora di sistema; a tale scopo un thread chiama ripetutamente il localtime e memorizza il risultato nella memoria condivisa. Gli altri thread devono solo leggere dalla RAM e non comportano una commutazione di processo quando lo fanno.

— niXar,