Herramientas para monitorear el tiempo de robo (st)

Nos estamos ejecutando en un servidor virtual "dedicado", lo que, en teoría, debería significar que somos los únicos en el servidor. En la práctica ... Estoy pensando que podríamos no estarlo.

ingrese la descripción de la imagen aquí

Tenga en cuenta que aunque parece que estamos matando nuestra máquina, el "tiempo de robo" es del 71%

Estoy tomando estadísticas sobre la carga y me decepcionó que esta estadística no apareciera en mis gráficos. ¿Hay alguna herramienta que monitoree esto que pueda ayudar?

Información Adicional:

Estamos ejecutando 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
fuente

Virtual dedicado? En el caso de XEN, tendrían que fijar núcleos dedicados para un uso dedicado en su VM. Parece que su proveedor ha sobrevendido CPU por una cantidad injusta. ¿Qué le dice a esto?

— Nils

¿Cuántas vCPU tiene y en qué tipo de CPU se informa grep "model name" /proc/cpuinfo|sort -u? Si este es realmente un servidor dedicado, entonces hay algo que consume tiempo de CPU en el Dom0. O le dieron más vCPU de las que están disponibles en Dom0.

— Nils

A menos que esto sea un valor atípico momentáneo, parece que su ISP le está mintiendo y, de hecho, está ejecutando otros vms pesados de CPU en esta máquina, o hay algo configurado muy mal que está causando que dom0 acapare mucho tiempo de CPU .

— psusi

SuSE recomienda reservar dos núcleos únicamente para el Dom0 para que pueda hacer todo el manejo de E / S sin molestar a otras máquinas virtuales. En mi opinión, eso solo sería necesario para sistemas con tiempo robado en DomUs y tráfico pesado de IO. Quería saber si su proveedor asignó más vCPU que núcleos lógicos, como asignar 4 vCPU mientras solo 2 CPU lógicas están disponibles en Dom0, eso también explicaría "robado" (y es una idea bastante descabellada, pero posible en XEN) .

— Nils

La causa raíz de este resultó ser que el ISP tenía la VM configurada incorrectamente. Al huésped se le dijo que tenía más núcleos de los que realmente tenía. Esto pareció causar estragos en la programación. El ISP no pudo proporcionar soporte técnico inteligente, pero pudimos "probar" el problema al deshabilitar núcleos impares en / proc. Nunca un problema desde entonces.

— mgjk

Respuestas:

Su pregunta está bien definida, pero no está dando mucha información sobre su entorno, cómo está monitoreando actualmente o qué herramientas gráficas está utilizando. Sin embargo, dado que SNMP se usa de manera bastante universal, supongo que lo está usando y al menos estoy familiarizado con él.

Aunque (por lo que puedo decir) el tiempo de robo de la CPU no está disponible actualmente desde snmpd, puede extenderlo usted mismo con el UCD-SNMP-MIB::extOutputobjeto y los execcomandos.

La forma más fácil (que he encontrado) de obtener el tiempo de robo es iostat. Usando la siguiente construcción podemos obtener solo el tiempo de robo:

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

Por lo tanto, agregue lo siguiente a su snmpd.conf:

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

(Alternativamente, puede poner el comando en un script de contenedor y llamar al contenedor desde adentro snmpd.conf).

Cada execllamada snmpd.confse indexa a partir de 1. Por lo tanto, si solo tiene una única declaración ejecutiva, entonces querrá sondear UCD-SNMP-MIB::extOutput.1. Si esta es la quinta declaración ejecutiva, entonces sondee UCD-SNMP-MIB::extOutput.5, etc.

El OID numérico para UCD-SNMP-MIB::extOutputes .1.3.6.1.4.1.2021.8.1.101así que si estás en el índice 1 sería .1.3.6.1.4.1.2021.8.1.101.1, y el índice 5 sería .1.3.6.1.4.1.2021.8.1.101.5, etc.

Luego crea un sondeo de gráfico que OMP SNMPD de tipo indicador, que va de 0 a 100. Esto debería darte algunos gráficos bonitos.

— bahamat
fuente

Gran respuesta. ¿Con qué frecuencia se recopilarán estas estadísticas? Solo durante la encuesta, ¿o hay alguna forma como en el RMON-MIB que registrará los valores sin una encuesta externa?

— Nils

Creo que sacaría esto cada vez que snmpdse consultara ese OID.

— bahamat

Si iostat no está instalado: top -bn1 | sed -nr '3s /.*,// gp'

— davide

sar -upodría ser útil en su caso. sar normalmente es parte del paquete sysstat .

— Nils
fuente

Desearía poder establecer más de una respuesta como la respuesta aceptada. Ambas respuestas han sido muy útiles :-) ¡Gracias!

— mgjk

La respuesta más votada es excelente, pero en este momento no está funcionando completamente: net-snmp pierde la tubería en la execllamada, por lo que debería verse así

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

Y el resultado será visible en 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

donde nsExtendOutput1Lineoid es .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

— drogadicto
fuente