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 -n
je 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:
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.
cron
capture STDERR quelque part? Sur FreeBSD, je les utilise généralement sous periodic every5
et j'en ai un /var/log/periodic.every5
qui 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 cricket
qui avait sa propre journalisation. Les cricket
journaux é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.