Die rrdgraph-Generierung schlägt bei hoher E / A-Last fehl

Wir haben ein 4-Kern-CPU-Produktionssystem, das viele Cronjobs ausführt, eine konstante Prozesswarteschlange und eine übliche Last von ~ 1,5 hat.

Während der Nacht machen wir einige IO-intensive Sachen mit Postgres. Wir generieren ein Diagramm, das die Lade- / Speichernutzung zeigt (rrd-updates.sh). Dies "schlägt" manchmal in Situationen mit hoher E / A-Last fehl. Es passiert fast jede Nacht, aber nicht in jeder Situation mit hohem E / A.

Meine "normale" Lösung wäre es, das Postgres-Zeug schön zu ionisieren und das Prio der Graphgenerierung zu erhöhen. Dies schlägt jedoch immer noch fehl. Die Graphgenerierung ist mit Herde halbfadensicher. Ich protokolliere die Ausführungszeiten und für die Diagrammgenerierung sind es bis zu 5 Minuten bei hoher E / A-Belastung, was anscheinend zu einem fehlenden Diagramm für bis zu 4 Minuten führt.
Der Zeitrahmen stimmt genau mit der Postgres-Aktivität überein (dies geschieht manchmal auch tagsüber, wenn auch nicht so oft). Ionisierung bis zum Echtzeit-Prio (C1 N6 graph_cron vs C2 N3 postgres), weit über den Postgres (-5 graph_cron vs 10 postgres) ) hat das Problem nicht gelöst.

Vorausgesetzt, die Daten werden nicht gesammelt, ist das zusätzliche Problem, dass das ionice / nice irgendwie immer noch nicht funktioniert.
Selbst mit 90% IOwait und einer Last von 100 konnte ich den Befehl zur Datengenerierung ohne Verzögerung von mehr als 5 Sekunden (zumindest beim Testen) kostenlos verwenden.

Leider konnte ich dies beim Testen nicht genau reproduzieren (nur mit einem virtualisierten Entwicklungssystem)

Versionen:

Kernel 2.6.32-5-686-bigmem
Debian Squeeze rrdtool 1.4.3 Hardware: SAS 15K RPM HDD mit LVM in Hardware RAID1
Mount Optionen: ext3 mit rw, Fehler = remount-ro
Scheduler: CFQ
crontab:

* * * * *               root    flock -n /var/lock/rrd-updates.sh nice -n-1 ionice -c1 -n7 /opt/bin/rrd-updates.sh

Es scheint einen möglicherweise verwandten BUG von Herrn Oetiker auf github für rrdcache zu geben:
https://github.com/oetiker/rrdtool-1.x/issues/326

Dies könnte tatsächlich mein Problem sein (gleichzeitige Schreibvorgänge), aber es erklärt nicht, dass der Cronjob nicht fehlschlägt. In der Annahme, dass ich tatsächlich 2 gleichzeitige Schreibvorgänge habe, flock -nwürde ich den Exit-Code 1 zurückgeben (pro Manpage, bestätigt beim Testen), da ich auch keine E-Mail mit der Ausgabe und der Beobachtung bekomme, dass der Cronjob die ganze Zeit über einwandfrei läuft irgendwie verloren.

Beispielausgabe: CPU-Lastdiagramm mit fehlenden Linien

Basierend auf dem Kommentar habe ich die wichtige Quelle des Update-Skripts hinzugefügt.

rrdtool update /var/rrd/cpu.rrd $(vmstat 5 2 | tail -n 1 | awk '{print "N:"$14":"$13}')
rrdtool update /var/rrd/mem.rrd $(free | grep Mem: | awk '{print "N:"$2":"$3":"$4}')
rrdtool update /var/rrd/mem_bfcach.rrd $(free | grep buffers/cache: | awk '{print "N:"$3+$4":"$3":"$4}')

Was vermisse ich oder wo kann ich weiter nachsehen?

Denken Sie daran: Produktives System, also kein Entwickler, kein Stacktrace oder ähnliches verfügbar oder installierbar.

— Dennis Nolte
quelle

Vor langer Zeit, als MRTG durch RRDgraph ersetzt wurde. Eine der wunderbaren Änderungen vom alten zum neuen war, dass RRDgraph die Bilder tatsächlich nur dann generiert, wenn eine Ansichtsanforderung vorliegt. Das alte MRTG erzeugte alle fünf Minuten für jeden Datenpunkt ganz neue Diagramme. Ihr Problem ist die Datenerfassung, nicht das Rendern von Grafiken.

— Ericx

@ericx danke für deinen Kommentar. Ich habe die Quelle für die Datengenerierung hinzugefügt. Denken Sie immer noch, dass das Problem darin besteht, dass der Befehl vmstat anstelle von IOnice / nice irgendwie nicht richtig funktioniert? Wenn ja, warum denkst du so?

— Dennis Nolte

Erfasst Ihr cronSTDERR irgendwo? Unter FreeBSD führe ich diese normalerweise unter aus periodic every5und ich habe eine /var/log/periodic.every5, die im Allgemeinen alle Fehler erfasst. Ich würde auch die drei Skripte versetzen und möglicherweise die Reihenfolge drehen, um zu sehen, ob eines besonders hängt. Der größte Teil meiner RRDTool-Erfahrung war mit cricketeiner eigenen Protokollierung. Die cricketProtokolle waren ausgezeichnet, um Probleme zu finden. Sammeln Sie wirklich jede Minute? (* * * * * statt * / 5 * * * *) Wie ist die Granularität des Diagramms? RRD ist standardmäßig auf 5-Minuten-Intervalle eingestellt.

— Ericx

Dies ist der Befehl, mit dem sie ursprünglich erstellt wurden: create cpu.rrd --step 300 DS: sys: GAUGE: 70: U: U DS: Benutzer: GAUGE: 70: U: U RRA: AVERAGE: 0.01: 1: 6351 Das heißt, Sie haben gerade einen weiteren Fehler gefunden, danke. Ich habe STDOUT und STDERR für dieses Skript zum Testen neu geschrieben. Es wurde nichts protokolliert, was mir beim ersten Versuch geholfen hat. Ich werde die Ausgabe morgen hinzufügen

— Dennis Nolte

In Bezug auf das Verstehen des "Fehlers" basiert die Anzeige von rrdtool auf einem 5-minütigen Abfragezyklus. Wenn Sie die Verarbeitung eines Zyklus nicht beenden, bevor der nächste beginnt, und wenn Ihre Datenerfassung und Diagrammproduktion Teil desselben Verarbeitungsvorgangs sind, wird ein fehlender Datenpunkt angezeigt.

— mc0e

Ich denke, es ist nicht das rrdtool, das das Diagramm nicht aktualisieren kann, sondern Daten können zu diesem Zeitpunkt nicht gemessen werden. Übrigens ist Ihre Methode zur Messung der CPU- und Speicherstatistik einfach falsch, da Sie sofort Ergebnisse erzielen. Die CPU- und Speicherlast kann sich im Abstand von 60 Sekunden drastisch ändern, Sie nehmen jedoch nur einen Wert an. Sie sollten wirklich in Betracht ziehen, SNMP-Daten zu verwenden, die durchschnittliche Daten in einem Intervall liefern. Außerdem scheint die gesamte Pipe teurer und langsamer zu sein als ein Snmpget-Aufruf. Könnte der Hauptgrund für Lücken sein.

— Drookie
quelle

Nur als Folge war es das. Sobald wir einige ressourcenhungrige Prozesse auf einen anderen Server verschieben konnten, werden die Diagramme einwandfrei generiert.

— Dennis Nolte