Ferramentas para monitorar o tempo de roubo (st)

Estamos rodando em um servidor virtual "dedicado", o que deve, em teoria, significar que somos os únicos caras no servidor. Na prática ... estou pensando que talvez não.

insira a descrição da imagem aqui

Observe que, embora pareça que estamos matando nossa máquina, "Steal time" é de 71%

Estou fazendo estatísticas de carga e fiquei desapontado por esse status não aparecer nos meus gráficos. Existem ferramentas para monitorar isso que possam ajudar?

Informação adicional:

Estamos executando 4 núcleos, modelo:

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

xen top virtualization

— mgjk
fonte

Virtual dedicado? No caso do XEN, eles precisariam fixar núcleos dedicados para uso dedicado em sua VM. Parece que seu provedor reservou em excesso as CPUs por um valor injusto. O que ele diz sobre isso?

— Nils

Em quantos vCPUs você possui e em que tipo de CPU é relatada grep "model name" /proc/cpuinfo|sort -u? Se esse servidor é realmente dedicado, há algo que consome tempo de CPU no Dom0. OU eles forneceram mais vCPUs do que o disponível no Dom0.

— Nils

A menos que isso seja momentâneo, parece que o seu provedor de serviços de Internet está mentindo para você e eles estão, de fato, executando outros vms pesados da CPU nesta máquina ou há algo configurado muito errado que está causando o dom0 a consumir muito tempo da CPU .

— Psusi

O SuSE recomenda reservar dois núcleos exclusivamente para o Dom0, para que ele possa fazer todo o processamento de E / S sem incomodar outras VMs. A meu ver, isso seria necessário apenas para sistemas com tempo roubado nas DomUs e tráfego pesado de E / S. Eu queria saber se o seu provedor atribuiu mais vCPUs do que núcleos lógicos - como atribuir 4 vCPUs enquanto apenas duas CPUs lógicas estão disponíveis no Dom0 - isso explicaria também "roubado" (e é uma ideia bastante interessante - mas possível no XEN) .

— Nils

A causa raiz deste foi o fato de o ISP ter a VM configurada incorretamente. Foi dito ao hóspede que tinha mais núcleos do que realmente tinha. Isso pareceu causar estragos no agendamento. O ISP não pôde fornecer suporte técnico inteligente, mas conseguimos "provar" o problema desativando núcleos ímpares em / proc. Nunca mais um problema.

— mgjk

Respostas:

Sua pergunta está bem definida, mas você não está fornecendo muitas informações sobre seu ambiente, como está monitorando atualmente ou quais ferramentas gráficas está usando. No entanto, como o SNMP é usado praticamente universalmente, presumo que você o esteja usando e tenha pelo menos alguma familiaridade com ele.

Embora (até onde eu saiba) o tempo de roubo de CPU não esteja disponível no snmpd, você pode estendê-lo pessoalmente com o UCD-SNMP-MIB::extOutputobjeto e os execcomandos.

A maneira mais fácil (que eu encontrei) de obter o tempo de roubo é iostat. Usando a seguinte construção, podemos obter apenas o tempo de roubo:

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

Portanto, acrescente o seguinte ao seu snmpd.conf:

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

(Como alternativa, você pode colocar o comando em um script de wrapper e chamar o wrapper de dentro snmpd.conf.)

Cada execchamada snmpd.confé indexada a partir de 1. Portanto, se você tiver apenas uma única instrução exec, será necessário pesquisar UCD-SNMP-MIB::extOutput.1. Se esta é a quinta declaração execut, então poll UCD-SNMP-MIB::extOutput.5, etc.

O OID numérico para UCD-SNMP-MIB::extOutputé, .1.3.6.1.4.1.2021.8.1.101portanto, se você estiver no índice 1 .1.3.6.1.4.1.2021.8.1.101.1, e no índice 5 .1.3.6.1.4.1.2021.8.1.101.5, etc.

Em seguida, você cria um gráfico pesquisando o SNMPD OID do medidor de tipo, variando de 0 a 100. Isso deve fornecer alguns gráficos bonitos.

— bahamat
fonte

Ótima resposta. Com que frequência essas estatísticas serão coletadas? Apenas durante a pesquisa, ou existe uma maneira como no RMON-MIB que registrará valores sem pesquisa externa?

— Nils

Eu acredito que seria puxar isso cada vez que snmpdé consultado para esse OID.

— bahamat

Se o iostat não estiver instalado: top -bn1 | sed NR '3s /.*,// gp'

— Davide

sar -upode ser útil no seu caso. sar normalmente faz parte do pacote sysstat .

— Nils
fonte

Eu gostaria de poder definir mais de uma resposta como resposta aceita. Ambas as respostas foram muito úteis :-) Obrigado!

— mgjk

A resposta mais votada é ótima, mas, no momento, ela não está funcionando totalmente: o net-snmp perde o cachê na execchamada, portanto, isso deve ficar assim

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

E o resultado será visível em 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

onde 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