La génération de rrdgraph échoue sur une charge d'E / S élevée

8

Nous avons un système de production de processeur à 4 cœurs qui fait beaucoup de tâches cron, ayant une file d'attente de proc constante et une charge habituelle de ~ 1,5.

Pendant la nuit, nous faisons des trucs intensifs IO avec des postgres. Nous générons un graphique montrant l'utilisation de la charge / mémoire (rrd-updates.sh) Cela "échoue" parfois dans des situations de charge d'E / S élevées. Cela se produit presque tous les soirs, mais pas dans toutes les situations d'E / S élevées.

Ma solution "normale" consisterait à gentil et à ioniser les trucs postgres et à augmenter le prio de la génération du graphe. Mais cela échoue toujours. La génération du graphique est semi-thread-proof avec flock. Je enregistre les temps d'exécution et pour la génération de graphique, il peut aller jusqu'à 5 minutes pendant une charge d'E / S élevée, ce qui entraîne apparemment un graphique manquant jusqu'à 4 minutes.
Le calendrier correspond exactement à l'activité postgres (cela se produit parfois pendant la journée, mais pas si souvent). ) n'a pas résolu le problème.

En supposant que les données ne sont pas collectées, le problème supplémentaire est que l'ionice / nice ne fonctionne toujours pas.
Même avec 90% IOwait et une charge de 100, j'ai toujours pu utiliser la commande de génération de données gratuitement sans plus de peut-être 5 secondes de retard (lors des tests au moins).

Malheureusement, je n'ai pas pu reproduire cela exactement lors des tests (n'ayant qu'un système de développement virtualisé)

Versions:

Kernel 2.6.32-5-686-bigmem
Debian Squeeze rrdtool 1.4.3 Matériel: disque dur SAS 15 000 tr / min avec LVM dans les
options de montage matériel RAID1 : ext3 avec rw, erreurs = remount-ro
Scheduler: CFQ
crontab:

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

Il semble y avoir un BUG éventuellement lié à Mr Oetiker sur github pour rrdcache:
https://github.com/oetiker/rrdtool-1.x/issues/326

Cela pourrait en fait être mon problème (écritures simultanées) mais cela n'explique pas l'échec du cronjob. Dans l'hypothèse que j'ai en fait 2 écritures simultanées, flock -nje retournerais le code de sortie 1 (par page de manuel, confirmé dans les tests) Comme je n'ai pas non plus d'e-mail avec la sortie et l'observation que le cronjob fonctionne réellement bien toutes les autres fois que je suis en quelque sorte perdu.

Exemple de sortie: graphique de charge du processeur avec lignes manquantes

Sur la base du commentaire, j'ai ajouté la source importante du script de mise à jour.

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}')

Que manque-t-il ou où puis-je vérifier davantage?

Rappelez-vous: système productif donc pas de dev, pas de stacktrace ou similaire disponible ou installable.

Dennis Nolte
la source
1
Il y a longtemps quand MRTG a été remplacé par RRDgraph. L'un des merveilleux changements de l'ancien au nouveau est que RRDgraph ne génère les images qu'en cas de demande de vue. L'ancien MRTG a généré de nouveaux graphiques pour chaque point de données toutes les cinq minutes. Votre problème concerne la collecte de données, pas le rendu du graphique.
ericx
@ericx merci pour votre commentaire. J'ai ajouté la source pour la génération de données. Pensez-vous toujours que le problème est que la commande vmstat au lieu de IOnice / nice ne fonctionne pas correctement? Si oui, pourquoi pensez-vous de cette façon?
Dennis Nolte
Votre croncapture STDERR quelque part? Sur FreeBSD, je les utilise généralement sous periodic every5et j'en ai un /var/log/periodic.every5qui capture généralement toutes les erreurs. Je voudrais également échelonner les trois scripts et éventuellement faire pivoter la commande pour voir si l'un en particulier se bloque. La plupart de mon expérience RRDTool était avec cricketqui avait sa propre journalisation. Les cricketjournaux étaient excellents pour trouver des problèmes. Collectez-vous vraiment chaque minute? (* * * * * au lieu de * / 5 * * * *) Quelle est la granularité du graphique? RRD par défaut à 5 minutes d'intervalle.
ericx
c'est la commande qui a été utilisée pour les créer initialement: create cpu.rrd --step 300 DS: sys: GAUGE: 70: U: U DS: user: GAUGE: 70: U: U RRA: MOYENNE: 0.01: 1: 6351 donc cela signifie que vous venez de trouver un autre bug, merci. j'ai réécrit STDOUT et STDERR pour ce script pour le test, rien ne s'est enregistré ce qui m'a aidé à revenir lorsque j'ai essayé la première fois. j'ajouterai la sortie demain
Dennis Nolte
1
En termes de compréhension de la "panne", l'affichage de rrdtool est basé sur un cycle d'interrogation de 5 minutes. Si vous ne terminez pas le traitement d'un cycle avant le début du suivant et si votre collecte de données et la production de graphiques font partie de la même opération de traitement, vous obtiendrez un point de données manquant.
mc0e

Réponses:

2

Je suppose que ce n'est pas le rrdtool qui ne peut pas mettre à jour le graphique, mais plutôt les données ne peuvent pas être mesurées à ce stade. Soit dit en passant, votre méthode de mesure des statistiques du processeur et de la mémoire est tout simplement erronée, car elle vous donne un résultat instantané. La charge du processeur et de la mémoire peut changer considérablement le long de l'intervalle de 60 secondes, mais vous ne prendrez qu'une seule valeur. Vous devriez vraiment envisager de prendre des données SNMP, ce qui donne des données moyennes sur un intervalle. De plus, le tuyau entier semble être plus cher et plus lent qu'un appel snmpget. Cela pourrait être la principale raison des lacunes.

drookie
la source
juste comme suivi, c'était ça. Une fois que nous avons pu déplacer certains processus gourmands en ressources vers un autre serveur, les graphiques sont bien générés.
Dennis Nolte