Laden Sie durchschnittliche Verrücktheit unter Linux Ubuntu

In den letzten Tagen habe ich versucht, die Verrücktheit zu verstehen, die in unserer Infrastruktur vor sich geht, aber ich konnte es nicht herausfinden, also wende ich mich an euch, um mir einige Hinweise zu geben.

Ich habe in Graphite Spikes in load_avg bemerkt, die ungefähr alle 2 Stunden mit tödlicher Regelmäßigkeit auftreten - es sind nicht genau 2 Stunden, aber es ist sehr regelmäßig. Ich füge einen Screenshot davon bei, den ich von Graphite genommen habe

Ich habe mich nicht weiter damit befasst - die Regelmäßigkeit hat mich zu dem Gedanken gebracht, dass es sich um eine Art Cron-Job oder ähnliches handelt, aber auf diesen Servern werden KEINE Cronjobs ausgeführt - tatsächlich handelt es sich um VMs, die in der Rackspace-Cloud ausgeführt werden. Was ich suche, ist ein Hinweis darauf, dass diese Probleme verursacht werden könnten und wie dies weiter untersucht werden kann.

Die Server sind ziemlich inaktiv - dies ist eine Staging-Umgebung, sodass fast kein Datenverkehr eingeht / sie nicht belastet werden sollten. Dies sind alles 4 VMs mit virtuellen Kernen. Was ich mit Sicherheit weiß, ist, dass wir ungefähr alle 10 Sekunden eine Reihe von Graphitproben entnehmen, aber wenn dies die Ursache für die Belastung ist, würde ich erwarten, dass sie konstant hoch ist, anstatt alle 2 Stunden in Wellen auf verschiedenen Servern zu auftreten.

Jede Hilfe, um dies zu untersuchen, wäre sehr dankbar!

Hier sind einige Daten von sar für app01 - das ist die erste blaue Spitze auf dem Bild oben - ich konnte aus den Daten keine Schlussfolgerungen ziehen. Auch nicht, dass die Bytes, die alle halbe Stunde (NICHT ALLE 2 STUNDEN) geschrieben werden, darauf zurückzuführen sind, dass der Chef-Client alle 30 Minuten ausgeführt wird. Ich werde versuchen, mehr Daten zu sammeln, obwohl ich das bereits getan habe, aber auch daraus keine Schlussfolgerungen ziehen konnte.

BELASTUNG

09:55:01 PM   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15   blocked
10:05:01 PM         0       125      1.28      1.26      0.86         0
10:15:01 PM         0       125      0.71      1.08      0.98         0
10:25:01 PM         0       125      4.10      3.59      2.23         0
10:35:01 PM         0       125      0.43      0.94      1.46         3
10:45:01 PM         0       125      0.25      0.45      0.96         0
10:55:01 PM         0       125      0.15      0.27      0.63         0
11:05:01 PM         0       125      0.48      0.33      0.47         0
11:15:01 PM         0       125      0.07      0.28      0.40         0
11:25:01 PM         0       125      0.46      0.32      0.34         0
11:35:01 PM         2       130      0.38      0.47      0.42         0
11:45:01 PM         2       131      0.29      0.40      0.38         0
11:55:01 PM         2       131      0.47      0.53      0.46         0
11:59:01 PM         2       131      0.66      0.70      0.55         0
12:00:01 AM         2       131      0.81      0.74      0.57         0

Zentralprozessor

09:55:01 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
10:05:01 PM     all      5.68      0.00      3.07      0.04      0.11     91.10
10:15:01 PM     all      5.01      0.00      1.70      0.01      0.07     93.21
10:25:01 PM     all      5.06      0.00      1.74      0.02      0.08     93.11
10:35:01 PM     all      5.74      0.00      2.95      0.06      0.13     91.12
10:45:01 PM     all      5.05      0.00      1.76      0.02      0.06     93.10
10:55:01 PM     all      5.02      0.00      1.73      0.02      0.09     93.13
11:05:01 PM     all      5.52      0.00      2.74      0.05      0.08     91.61
11:15:01 PM     all      4.98      0.00      1.76      0.01      0.08     93.17
11:25:01 PM     all      4.99      0.00      1.75      0.01      0.06     93.19
11:35:01 PM     all      5.45      0.00      2.70      0.04      0.05     91.76
11:45:01 PM     all      5.00      0.00      1.71      0.01      0.05     93.23
11:55:01 PM     all      5.02      0.00      1.72      0.01      0.06     93.19
11:59:01 PM     all      5.03      0.00      1.74      0.01      0.06     93.16
12:00:01 AM     all      4.91      0.00      1.68      0.01      0.08     93.33

09:55:01 PM       tps      rtps      wtps   bread/s   bwrtn/s
10:05:01 PM      8.88      0.15      8.72      1.21    422.38
10:15:01 PM      1.49      0.00      1.49      0.00     28.48
10:25:01 PM      1.54      0.00      1.54      0.03     29.61
10:35:01 PM      8.35      0.04      8.31      0.32    411.71
10:45:01 PM      1.58      0.00      1.58      0.00     30.04
10:55:01 PM      1.52      0.00      1.52      0.00     28.36
11:05:01 PM      8.32      0.01      8.31      0.08    410.30
11:15:01 PM      1.54      0.01      1.52      0.43     29.07
11:25:01 PM      1.47      0.00      1.47      0.00     28.39
11:35:01 PM      8.28      0.00      8.28      0.00    410.97
11:45:01 PM      1.49      0.00      1.49      0.00     28.35
11:55:01 PM      1.46      0.00      1.46      0.00     27.93
11:59:01 PM      1.35      0.00      1.35      0.00     26.83
12:00:01 AM      1.60      0.00      1.60      0.00     29.87

NETZWERK:

10:25:01 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
10:35:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
10:35:01 PM      eth1      7.07      4.77      5.24      2.42      0.00      0.00      0.00
10:35:01 PM      eth0      2.30      1.99      0.24      0.51      0.00      0.00      0.00
10:45:01 PM        lo      8.35      8.35      2.18      2.18      0.00      0.00      0.00
10:45:01 PM      eth1      3.69      3.45      0.65      2.22      0.00      0.00      0.00
10:45:01 PM      eth0      1.50      1.33      0.15      0.36      0.00      0.00      0.00
10:55:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
10:55:01 PM      eth1      3.66      3.40      0.64      2.19      0.00      0.00      0.00
10:55:01 PM      eth0      0.79      0.87      0.08      0.29      0.00      0.00      0.00
11:05:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
11:05:01 PM      eth1      7.29      4.73      5.25      2.41      0.00      0.00      0.00
11:05:01 PM      eth0      0.82      0.89      0.09      0.29      0.00      0.00      0.00
11:15:01 PM        lo      8.34      8.34      2.18      2.18      0.00      0.00      0.00
11:15:01 PM      eth1      3.67      3.30      0.64      2.19      0.00      0.00      0.00
11:15:01 PM      eth0      1.27      1.21      0.11      0.34      0.00      0.00      0.00
11:25:01 PM        lo      8.32      8.32      2.18      2.18      0.00      0.00      0.00
11:25:01 PM      eth1      3.43      3.35      0.63      2.20      0.00      0.00      0.00
11:25:01 PM      eth0      1.13      1.09      0.10      0.32      0.00      0.00      0.00
11:35:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
11:35:01 PM      eth1      7.16      4.68      5.25      2.40      0.00      0.00      0.00
11:35:01 PM      eth0      1.15      1.12      0.11      0.32      0.00      0.00      0.00
11:45:01 PM        lo      8.37      8.37      2.18      2.18      0.00      0.00      0.00
11:45:01 PM      eth1      3.71      3.51      0.65      2.20      0.00      0.00      0.00
11:45:01 PM      eth0      0.75      0.86      0.08      0.29      0.00      0.00      0.00
11:55:01 PM        lo      8.30      8.30      2.18      2.18      0.00      0.00      0.00
11:55:01 PM      eth1      3.65      3.37      0.64      2.20      0.00      0.00      0.00
11:55:01 PM      eth0      0.74      0.84      0.08      0.28      0.00      0.00      0.00

Für Leute, die neugierig auf Cronjobs sind. Hier ist die Zusammenfassung aller auf dem Server eingerichteten Cronjobs (ich habe app01 ausgewählt, aber dies geschieht auch auf einigen anderen Servern mit denselben eingerichteten Cronjobs).

$ ls -ltr /etc/cron*
-rw-r--r-- 1 root root  722 Apr  2  2012 /etc/crontab

/etc/cron.monthly:
total 0

/etc/cron.hourly:
total 0

/etc/cron.weekly:
total 8
-rwxr-xr-x 1 root root 730 Dec 31  2011 apt-xapian-index
-rwxr-xr-x 1 root root 907 Mar 31  2012 man-db

/etc/cron.daily:
total 68
-rwxr-xr-x 1 root root  2417 Jul  1  2011 popularity-contest
-rwxr-xr-x 1 root root   606 Aug 17  2011 mlocate
-rwxr-xr-x 1 root root   372 Oct  4  2011 logrotate
-rwxr-xr-x 1 root root   469 Dec 16  2011 sysstat
-rwxr-xr-x 1 root root   314 Mar 30  2012 aptitude
-rwxr-xr-x 1 root root   502 Mar 31  2012 bsdmainutils
-rwxr-xr-x 1 root root  1365 Mar 31  2012 man-db
-rwxr-xr-x 1 root root  2947 Apr  2  2012 standard
-rwxr-xr-x 1 root root   249 Apr  9  2012 passwd
-rwxr-xr-x 1 root root   219 Apr 10  2012 apport
-rwxr-xr-x 1 root root   256 Apr 12  2012 dpkg
-rwxr-xr-x 1 root root   214 Apr 20  2012 update-notifier-common
-rwxr-xr-x 1 root root 15399 Apr 20  2012 apt
-rwxr-xr-x 1 root root  1154 Jun  5  2012 ntp

/etc/cron.d:
total 4
-rw-r--r-- 1 root root 395 Jan  6 18:27 sysstat
$ sudo ls -ltr /var/spool/cron/crontabs 
total 0
$

Wie Sie sehen können, gibt es keine STUNDEN Cronjobs. Nur täglich / wöchentlich etc.

Ich habe eine Reihe von Statistiken gesammelt (vmstat, mpstat, iostat) - so sehr ich mich auch bemühe, ich kann keine Leads sehen, die auf ein schlechtes Verhalten einer VM-Komponente hindeuten ... Ich neige dazu, mich potenziellen Problemen bei Hypervisor zuzuwenden. Fühlen Sie sich frei, einen Blick auf die Statistiken zu werfen. Das Wesentliche beginnt mit der Ausgabe von sar -q um die "beleidigende" Zeit und dann können Sie vm, mp und iostats sehen ....

Im Grunde ist es mir immer noch ein Rätsel ...

— milosgajdos
quelle

Haben Sie interaktive Daten, die Sie zur weiteren Untersuchung freigeben können (dh was werden "top", "htop" und "iotop" während der wiederkehrenden Lastspitzen angezeigt)? Haben Sie auch Ihre Anwendungsprotokolle während der fraglichen Zeiten überprüft, um festzustellen, ob sie ein merkwürdiges Verhalten aufweisen? Haben Sie außerdem Hosts mit ähnlichen Konfigurationen, die nicht in der öffentlichen Cloud-Infrastruktur gehostet werden, und wenn ja, zeigen sie ein ähnliches Verhalten?

— Esquireofoz

In Bezug auf App-Protokolle passiert nichts. Die einzigen darin enthaltenen Protokolleinträge sind Überprüfungen der Überwachung, die jede Minute durchgeführt werden - im Grunde trifft das Überwachungssystem die Hauptwebsite und meldet den Ergebniscode - abgesehen davon, dass die Protokolle vollständig leer sind. Wie Sie sehen können, gibt es oben eine Vielzahl von Hosts - dies geschieht auf allen (Redis, App-Server, Chef-Server usw.)

— Milosgajdos

Haben Sie versucht, es mit psacct einzugrenzen ?

— HTTP500

Sie gehen von Regelmäßigkeit aus, aber die von Ihnen angezeigten Daten zeigen keine regelmäßig auftretenden Spitzen. Bitte geben Sie genauer an, in welchem Zeitraum Regelmäßigkeit angezeigt wird (über mehrere Tage hinweg? Auf dem Bild gibt es keine Regelmäßigkeit.) Führen Sie etwa alle 1 Minute eine "top -n 1" aus und speichern Sie sie in einer Datei. Dies könnte dazu beitragen, festzustellen, welche anderen Prozesse gleichzeitig mit dem Auftreten einer Spitze um die CPU konkurrieren. Wenn App1 eine App mit Internetanschluss ist, ist es vielleicht nur jemand, der Zugriff darauf erhält und dieses Verhalten erzwingt? Fügen Sie auch eine reguläre "netstat -an" -Protokollierung hinzu (jede Minute?)

— Olivier Dulac

Hast du den angehängten Screenshot gesehen? Wenn das nicht regelmäßig zeigt, weiß ich nicht was. Ich habe jetzt die Probenahmezeit für sar verlängert, also probiere ich alle 5 Minuten. Die Regelmäßigkeit auf dem Bild ist mehr als offensichtlich - es passiert alle zwei Stunden. Dies ist eine Staging-Umgebung ohne jeglichen Datenverkehr - wie Sie sicherlich aus den obigen Sar-Ausgaben für Netzwerkstatistiken ersehen können.

— Milosgajdos

Interessant.

Erstens können Sie die Häufigkeit der Sar-Protokollierung erhöhen. Versuchen Sie statt 10 Minuten, jede Minute zu protokollieren. Der sysstat cronjob ist konfigurierbar.

Versuchen Sie als Nächstes, die folgenden Befehle zu skripten.

ps auxf > /tmp/ps.out
vmstat 1 50 > /tmp/vm.out
mpstat -P ALL 1 50 > /tmp/mp.out
iostat -xdk 1 50 > /tmp/io.out
cat /proc/meminfo > /tmp/meminfo.out

Sammeln Sie diesen Datensatz entweder bei jeder Iteration, wenn der Lastdurchschnitt manuell oder über cron ansteigt. Es wäre gut, Daten von mindestens einem vollen Arbeitstag zu haben.

Jetzt verstehe ich, dass die Server inaktiv sind, aber noch einige Anwendungen ausgeführt werden müssen. Was sind Sie?

Ist es möglich, dass Sie ein Profiling-Tool wie perf oder oprofile ausführen können?

Wurde eine Serverhardwarekomponente geändert? Sogar etwas so Unschädliches wie ein Firmware-Upgrade oder ein Software-Upgrade.

Hey, eine Frage. Was ist der Scheduler, den Sie ausführen? Ich glaube, es ist cfq, jede Chance, die Sie in noop ändern können. Geben Sie elevator=noopden Kernel-Befehlszeilenparameter ein, starten Sie das System neu und prüfen Sie, ob es verbessert wird.

— Soham Chakraborty
quelle

Ich habe eine kleine Änderung über Scheduler hinzugefügt. Bitte sehen Sie das Ergebnis.

— Soham Chakraborty

Top-Prozesse protokollieren

Da das Auftreten sehr regelmäßig ist, richten Sie einen Cron-Job ein, um die wichtigsten Prozesse während dieses Zeitraums zu überwachen

#app01
20-59 0/2 * * * root /usr/bin/top -b -n 1 | /usr/bin/head -n 15 >> /var/log/top.log

Durch Ändern 20-59in *wird die gesamte Stunde für jede gerade Anzahl von Stunden protokolliert. Der Cron-Job wird in beiden Fällen einmal pro Minute ausgeführt.

Möglicherweise möchten Sie die Datei top.log zur Protokollrotation hinzufügen, damit nicht der gesamte Speicherplatz belegt wird, falls Sie vergessen, sie zu deaktivieren.

Überprüfen Sie die Protokolldatei

Suchen Sie nach Protokolldateieinträgen mit hoher Ladezeit

Nehmen Sie als Beispiel den folgenden Ladeeintrag

10:25:01 PM         0       125      4.10      3.59      2.23         0

Machen

grep ' 22:2' /var/log/*
grep ' 22:2' /var/log/apache2/*

Das zeigt alle Protokolleinträge für 22:2x:xx. Möglicherweise müssen andere Protokollverzeichnisse enthalten sein.

So Jan 6 21:00:07 2013: xvda w_await spike

xvda Chart - Die w_await-Spitze ist am 6. Januar 2013 um 21:00:07 Uhr Geben Sie hier die Bildbeschreibung ein

— John Siu
quelle

Eines würde ich auf jeden Fall überprüfen:

vSphere-Diagramme für dasselbe Muster, möglicherweise verbraucht eine andere VM auf demselben Host die CPUs (daher steigt die Belastung Ihrer VM, da die Verarbeitung derselben Datenmenge mit konstantem Datenfluss länger dauert, da weniger CPU-Zeit zur Verfügung steht Ihre VM).

Bearbeiten: Beim ersten Mal nicht erhalten :) Sie laufen auf Rackspace, daher keine Kontrolle über den Hypervisor. Es kann jedoch sinnvoll sein, Rackspace zu fragen, ob sie überprüfen können, ob dieses Muster auf anderen VMs auf demselben Host üblich ist .

— Martino Dino
quelle

Ich bin auch misstrauisch - es wäre nicht das erste Mal, dass die Rackspace-Wolke eine Art Wahnsinn verursacht. Ich bezweifle, dass sie einen ihrer Hypervisor-Server überwachen - ich meine in Bezug auf schlechtes Verhalten von VMs, aber ich möchte alle "internen" Möglichkeiten ausschließen, bevor ich mich dem letzten Ausweg zuwende - der Rackspace-Unterstützung.

— Milosgajdos

Würde sich die Hypervisor-Leistung auf den selbstverständlichen Lastdurchschnitt einer VM auswirken? Dies lässt mich darüber nachdenken, wie der Lastdurchschnitt berechnet wird. Könnte dies möglicherweise ein Effekt der grünen / stromsparenden Funktion sein, die die Arbeit regelmäßig auf weniger Kerne verlagert, ohne dass das Betriebssystem dies weiß? Oder wie wäre es mit einer dynamischen Änderung der Taktrate, basierend auf z. B. Umgebungseingaben?

— trp

Der Lastdurchschnitt wird vom Planungsalgorithmus in einfachen Worten berechnet. Wenn Sie 100 Aufgaben in Ihrer Verarbeitungswarteschlange haben und der Hypervisor 10 Aufgaben pro 1 Sekunde zu 100% effizient ausführt, benötigen Sie 10 Sekunden, um 100 Aufgaben auszuführen, wenn Ihr Hypervisor ist nur zu 50% effizient (möglicherweise CPU-Überprovisionierung). Es dauert 20 Sekunden, um die gleiche Anzahl von Aufgaben auszuführen, was zu einer erhöhten Last führt. Vollständige Erklärung: blog.scoutapp.com/articles/2009/07/31/…

— Martino Dino