Strumenti per il monitoraggio del tempo rubato (st)

Siamo in esecuzione su un server "dedicato" virtuale, il che, in teoria, dovrebbe significare che siamo gli unici ragazzi sul server. In pratica .... Sto pensando che potremmo non esserlo.

inserisci qui la descrizione dell'immagine

Si noti che, anche se sembra che stiamo uccidendo la nostra macchina, "Ruba tempo" è al 71%

Sto prendendo statistiche sul carico e sono rimasto deluso dal fatto che questa statistica non sia stata mostrata nei miei grafici. Esistono strumenti che monitorano ciò che potrebbero essere di aiuto?

Informazioni aggiuntive:

Stiamo eseguendo 4 core, modello:

# grep "model name" /proc/cpuinfo | sort -u
model name  : Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz

xen top virtualization

— mgjk
fonte

Virtuale dedicato? In caso di XEN dovrebbero aggiungere pin dedicati per un uso dedicato nella VM. Sembra che il tuo provider abbia prenotato in eccesso le CPU da un ingiusto. Cosa dice a questo?

— Nils,

Quante vCPU hai e in che tipo di CPU è riportato grep "model name" /proc/cpuinfo|sort -u? Se questo è davvero un server dedicato, allora c'è qualcosa che consuma tempo CPU sul Dom0. OPPURE ti hanno fornito più vCPU di quelle disponibili in Dom0.

— Nils,

A meno che questo non sia un momento anomalo momentaneo, sembra che il tuo isp ti stia mentendo e che, di fatto, stiano eseguendo altri vp pesanti della CPU su questa macchina, o che ci sia qualcosa di molto sbagliato che sta causando a dom0 un periodo di tempo molto lungo .

— psusi,

SuSE consiglia di riservare due core esclusivamente per Dom0 in modo che possa eseguire tutte le operazioni di I / O senza disturbare le altre VM. Ai miei occhi ciò sarebbe necessario solo per i sistemi con tempo rubato nei domu e traffico pesante di I / O. Volevo sapere se il tuo provider ha assegnato più vCPU rispetto ai core logici - come assegnare 4 vCPU mentre nel Dom0 sono disponibili solo 2 CPU logiche - ciò spiegherebbe anche "rubato" (ed è un'idea piuttosto semplice - ma possibile in XEN) .

— Nils,

La causa principale di questa si è rivelata che l'ISP aveva la VM configurata in modo errato. All'ospite veniva detto che aveva più core di quanti ne avesse effettivamente. Ciò sembrava causare il caos con la programmazione. L'ISP non è stato in grado di fornire supporto tecnico intelligente, ma siamo stati in grado di "provare" il problema disabilitando i core con numero dispari in / proc. Da allora non è mai stato un problema.

— mgjk,

Risposte:

La tua domanda è ben definita, ma non stai fornendo molte informazioni sul tuo ambiente, su come stai attualmente monitorando o su quali strumenti grafici stai usando. Tuttavia, dato che SNMP è usato praticamente universalmente per questo, suppongo che lo stai usando e che abbia almeno una certa familiarità con esso.

Sebbene (per quanto posso dire) il tempo di furto della CPU non è attualmente disponibile da snmpd, puoi estenderlo tu stesso con l' UCD-SNMP-MIB::extOutputoggetto e i execcomandi.

Il modo più semplice (che ho trovato) per ottenere il tempo di rubare è iostat. Usando il seguente costrutto possiamo ottenere solo il tempo rubato:

$ iostat -c | awk 'NR==4 {print $5}'
0.00

Pertanto, aggiungi quanto segue al tuo snmpd.conf:

exec cpu_steal_time /usr/bin/iostat -c | /usr/bin/awk 'NR==4 {print $5}'

(In alternativa è possibile inserire il comando in uno script wrapper e chiamare il wrapper dall'interno snmpd.conf.)

Ogni execchiamata snmpd.confè indicizzata a partire da 1. Quindi, se hai una sola istruzione exec, ti consigliamo di effettuare il polling UCD-SNMP-MIB::extOutput.1. Se questa è la quinta istruzione exec, allora poll UCD-SNMP-MIB::extOutput.5, ecc.

L'OID numerico per UCD-SNMP-MIB::extOutputè .1.3.6.1.4.1.2021.8.1.101quindi se ci si trova nell'indice 1 .1.3.6.1.4.1.2021.8.1.101.1, l'indice 5 lo sarebbe .1.3.6.1.4.1.2021.8.1.101.5, ecc.

Quindi si crea un polling grafico di OID SNMPD di indicatore di tipo, che varia da 0 a 100. Questo dovrebbe darti dei bei grafici.

— bahamat
fonte

Bella risposta. Con quale frequenza verranno raccolte queste statistiche? Proprio durante il sondaggio, o c'è un modo come nel RMON-MIB che registrerà i valori senza sondaggio esterno?

— Nils,

Credo che tirerebbe questo ogni volta che snmpdviene richiesto questo OID.

— bahamat,

Se iostat non è installato: top -bn1 | sed -nr '3s /.*,// gp'

— davide

sar -upotrebbe essere utile nel tuo caso. sar fa normalmente parte del pacchetto sysstat .

— Nils
fonte

Vorrei poter impostare più di una risposta come risposta accettata. Entrambe le risposte sono state molto utili :-) Grazie!

— mgjk,

La risposta più votata è ottima, ma al momento non funziona completamente: net-snmp perde la pipe in execcall, quindi dovrebbe apparire così

extend-sh cpu_steal_time /usr/bin/iostat -c 1 1 | /usr/bin/awk '!/%user|Linux|^$/ {print $5}'

E il risultato sarà visibile sotto nsExtendOutput1Table:

# snmpwalk localhost NET-SNMP-EXTEND-MIB::nsExtendOutput1Table
NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."cpu_steal_time" = STRING: 0.60
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."cpu_steal_time" = STRING: 0.60
NET-SNMP-EXTEND-MIB::nsExtendOutNumLines."cpu_steal_time" = INTEGER: 1
NET-SNMP-EXTEND-MIB::nsExtendResult."cpu_steal_time" = INTEGER: 0

dove nsExtendOutput1Lineoid è .1.3.6.1.4.1.8072.1.3.2.3.1.1:

snmpwalk localhost .1.3.6.1.4.1.8072.1.3.2.3.1.1
NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."cpu_steal_time" = STRING: 0.60

— drookie
fonte