Outils pour surveiller le temps de vol (st)

Nous fonctionnons sur un serveur virtuel "dédié", ce qui devrait, en théorie, signifier que nous sommes les seuls sur le serveur. En pratique ... Je pense que nous ne le serions peut-être pas.

entrez la description de l'image ici

Notez que bien qu'il semble que nous tuions notre machine, le "temps de vol" est à 71%

Je prends des statistiques sur la charge et j'ai été déçu que cette statistique n'apparaisse pas dans mes graphiques. Existe-t-il des outils de surveillance qui pourraient être utiles?

Information additionnelle:

Nous exécutons 4 cœurs, modèle:

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

xen top virtualization

— mgjk
source

Virtuel dédié? Dans le cas de XEN, ils devraient épingler des cœurs dédiés pour une utilisation dédiée dans votre machine virtuelle. On dirait que votre fournisseur a surréservé les processeurs par un montant injuste. Que dit-il à cela?

— Nils

Combien de vCPU possédez-vous et dans quel type de CPU est signalé grep "model name" /proc/cpuinfo|sort -u? S'il s'agit vraiment d'un serveur dédié, il y a quelque chose qui consomme du temps CPU sur le Dom0. OU ils vous ont donné plus de processeurs virtuels que ceux disponibles dans Dom0.

— Nils

À moins qu'il ne s'agisse d'une valeur aberrante momentanée, il semble que votre FAI vous ment et qu'ils exécutent en fait d'autres vms lourds de processeur sur cette machine, ou qu'il y a quelque chose de très mal configuré qui fait que dom0 monopolise beaucoup de temps de processeur .

— psusi

SuSE recommande de réserver deux cœurs uniquement pour Dom0 afin qu'il puisse effectuer toutes les opérations d'E / S sans déranger les autres VM. À mes yeux, cela ne serait nécessaire que pour les systèmes avec du temps volé dans les DomU ET un trafic d'E / S important. Je voulais savoir si votre fournisseur avait attribué plus de processeurs virtuels que de cœurs logiques - comme attribuer 4 processeurs virtuels alors que seulement 2 processeurs logiques sont disponibles dans le Dom0 - cela expliquerait aussi le «vol» (et c'est une idée assez audacieuse - mais possible dans XEN) .

— Nils

La cause première de celui-ci s'est avérée être que le FAI avait la VM mal configurée. On a dit à l'invité qu'il y avait plus de cœurs qu'il n'en avait réellement. Cela a semblé causer des ravages avec le calendrier. Le FAI n'a pas pu fournir un support technique intelligent, mais nous avons pu «prouver» le problème en désactivant les cœurs impairs dans / proc. Jamais de problème depuis.

— mgjk

Réponses:

Votre question est bien définie, mais vous ne donnez pas beaucoup d'informations sur votre environnement, la façon dont vous surveillez actuellement ou les outils graphiques que vous utilisez. Cependant, étant donné que SNMP est utilisé à peu près universellement pour cela, je suppose que vous l'utilisez et que vous le connaissez au moins.

Bien que (pour autant que je sache) le temps de vol de CPU n'est pas actuellement disponible à partir de snmpd, vous pouvez l'étendre vous-même avec l' UCD-SNMP-MIB::extOutputobjet et les execcommandes.

Le moyen le plus simple (que j'ai trouvé) pour obtenir le temps de vol est de iostat. En utilisant la construction suivante, nous pouvons obtenir juste le temps de vol:

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

Par conséquent, ajoutez ce qui suit à votre snmpd.conf:

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

(Alternativement, vous pouvez placer la commande dans un script wrapper et appeler le wrapper de l'intérieur snmpd.conf.)

Chaque execappel snmpd.confentrant est indexé à partir de 1. Donc, si vous n'avez qu'une seule instruction exec, vous voudrez interroger UCD-SNMP-MIB::extOutput.1. S'il s'agit de la 5e instruction exec, interrogez UCD-SNMP-MIB::extOutput.5, etc.

L'OID numérique pour UCD-SNMP-MIB::extOutputest .1.3.6.1.4.1.2021.8.1.101donc si vous êtes à l'index 1 ce serait .1.3.6.1.4.1.2021.8.1.101.1, et l'index 5 serait .1.3.6.1.4.1.2021.8.1.101.5, etc.

Vous créez ensuite un sondage de graphe qui SNMPD OID de type jauge, allant de 0 à 100. Cela devrait vous donner de jolis graphiques.

— bahamat
source

Très bonne réponse. À quelle fréquence ces statistiques seront-elles recueillies? Juste pendant le sondage, ou existe-t-il un moyen comme dans le RMON-MIB qui enregistrera les valeurs sans sondage externe?

— Nils

Je crois qu'il tirerait cela à chaque fois que l' snmpdon demande cet OID.

— bahamat

Si iostat n'est pas installé: top -bn1 | sed -nr '3s /.*,// gp'

— davide

sar -upourrait être utile dans votre cas. sar fait normalement partie du paquet sysstat .

— Nils
source

J'aimerais pouvoir définir plus d'une réponse comme réponse acceptée. Les deux réponses ont été très utiles :-) Merci!

— mgjk

La réponse la plus votée est excellente, mais pour le moment elle ne fonctionne pas pleinement: net-snmp perd le tuyau en execappel, donc cela devrait ressembler à ceci

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

Et le résultat sera visible sous 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

où nsExtendOutput1Lineoid est .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
source