Werkzeuge zum Überwachen der Diebstahlzeit (st)

Wir arbeiten auf einem virtuellen "dedizierten" Server, was theoretisch bedeuten sollte, dass wir die einzigen auf dem Server sind. In der Praxis .... ich denke, wir könnten nicht sein.

Bildbeschreibung hier eingeben

Beachten Sie, dass "Zeit stehlen" bei 71% liegt, obwohl es so aussieht, als würden wir unsere Maschine töten.

Ich nehme Statistiken zum Ladevorgang auf und war enttäuscht, dass diese Statistik in meinen Grafiken nicht angezeigt wurde. Gibt es Tools, die dies überwachen und möglicherweise Abhilfe schaffen?

Zusätzliche Information:

Wir betreiben 4 Kerne, Modell:

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

xen top virtualization

— mgjk
quelle

Virtuell engagiert? Im Falle von XEN müssten sie dedizierte Kerne für die dedizierte Verwendung in Ihrer VM anpinnen. Ihr Provider hat anscheinend die CPUs durch eine unfaire Summe überbucht. Was sagt er dazu?

— Nils

Wie viele vCPUs haben Sie und in welchem CPU-Typ wird berichtet grep "model name" /proc/cpuinfo|sort -u? Wenn dies wirklich ein dedizierter Server ist, dann frisst etwas CPU-Zeit auf dem Dom0. ODER Sie haben Ihnen mehr vCPUs gegeben, als in Dom0 verfügbar sind.

— Nils

Es sei denn, dies ist ein vorübergehender Ausreißer, es sieht so aus, als ob Ihr ISP Sie anlügt und tatsächlich andere CPU-schwere VMs auf diesem Computer laufen lässt, oder es ist etwas sehr falsch konfiguriert, was dazu führt, dass dom0 viel CPU-Zeit verschlingt .

— Psusi

SuSE empfiehlt, zwei Kerne ausschließlich für Dom0 zu reservieren, damit alle E / A-Vorgänge ausgeführt werden können, ohne andere VMs zu belasten. In meinen Augen wäre das nur für Systeme mit gestohlener Zeit in den DomUs UND starkem IO-Verkehr notwendig. Ich wollte wissen, ob Ihr Provider mehr vCPUs als logische Kerne zugewiesen hat - wie zum Beispiel 4 vCPUs zuweisen, während nur 2 logische CPUs in Dom0 verfügbar sind - das würde auch "gestohlen" erklären (und ist eine ziemlich knifflige Idee - aber in XEN möglich). .

— Nils

Die Hauptursache für dieses Problem war, dass der ISP die VM falsch konfiguriert hatte. Dem Gast wurde gesagt, es habe mehr Kerne als tatsächlich. Dies schien Chaos bei der Planung zu verursachen. Der ISP konnte keinen intelligenten technischen Support bieten, aber wir konnten das Problem "beweisen", indem wir ungeradzahlige Kerne in / proc deaktivierten. Niemals ein Problem seit.

— mgjk

Antworten:

Ihre Frage ist klar definiert, aber Sie geben nicht viele Informationen über Ihre Umgebung, die Art und Weise, wie Sie sie aktuell überwachen oder welche Grafiktools Sie verwenden. Da SNMP jedoch so ziemlich universell verwendet wird, gehe ich davon aus, dass Sie es verwenden und zumindest ein wenig damit vertraut sind.

Obwohl (soweit ich das beurteilen kann) die CPU-Steal-Zeit derzeit nicht in snmpd verfügbar ist, können Sie sie mit dem UCD-SNMP-MIB::extOutputObjekt und den execBefehlen selbst erweitern.

Der einfachste Weg (den ich gefunden habe), um die Zeit zu stehlen, ist von iostat. Mit dem folgenden Konstrukt können wir nur die Zeit für den Diebstahl ermitteln:

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

Hängen Sie daher Folgendes an Ihre snmpd.conf an:

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

(Alternativ können Sie den Befehl in ein Wrapper-Skript einfügen und den Wrapper von innen aufrufen snmpd.conf.)

Jeder execAufruf snmpd.confwird ab 1 indiziert. Wenn Sie also nur eine einzige exec-Anweisung haben, möchten Sie eine Abfrage durchführen UCD-SNMP-MIB::extOutput.1. Wenn dies die 5. exec-Anweisung ist, dann poll UCD-SNMP-MIB::extOutput.5usw.

Die numerische OID für UCD-SNMP-MIB::extOutputlautet wie folgt: .1.3.6.1.4.1.2021.8.1.101Wenn Sie sich bei Index 1 befinden, ist dies der Fall .1.3.6.1.4.1.2021.8.1.101.1, und Index 5 ist der Fall .1.3.6.1.4.1.2021.8.1.101.5, usw.

Anschließend erstellen Sie ein Diagramm, das die SNMPD-OID der Typanzeige im Bereich von 0 bis 100 abfragt. Dies sollte Ihnen einige hübsche Grafiken geben.

— Bahamat
quelle

Gute Antwort. Wie oft werden diese statischen Daten erfasst? Nur während der Abfrage, oder gibt es einen Weg wie in der RMON-MIB, der Werte ohne externe Abfrage aufzeichnet?

— Nils

Ich glaube, es würde dies jedes Mal ziehen, wenn die snmpdfür diese OID abgefragt wird.

— Bahamat

Wenn iostat nicht installiert ist: top -bn1 | sed -nr '3s /.* ,// gp'

— davide

sar -ukönnte in Ihrem Fall hilfreich sein. sar ist normalerweise Teil des sysstat -Pakets .

— Nils
quelle

Ich wünschte, ich könnte mehr als eine Antwort als akzeptierte Antwort festlegen. Beide Antworten waren sehr nützlich :-) Danke!

— mgjk

Die am häufigsten gewählte Antwort ist großartig, aber zu diesem Zeitpunkt funktioniert sie noch nicht vollständig: net-snmp verliert die Pipe im execAnruf, daher sollte dies so aussehen

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

Und das Ergebnis wird sichtbar unter 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

wobei nsExtendOutput1Lineoid .1.3.6.1.4.1.8072.1.3.2.3.1.1 ist:

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
quelle