la generazione del rrdgraph non riesce con un elevato carico di I / O

Abbiamo un sistema di produzione di CPU a 4 core che fa un sacco di cronjobs, con una coda di elaborazione costante e un carico normale di ~ 1,5.

Durante la notte facciamo alcune cose ad alta intensità di IO con Postgres. Generiamo un grafico che mostra l'utilizzo di carico / memoria (rrd-updates.sh) Questo "errore" a volte in situazioni di carico IO elevato. Succede quasi ogni notte, ma non in ogni situazione di I / O alta.

La mia soluzione "normale" sarebbe quella di rendere piacevole e ionizzare le cose di Postgres e aumentare il prio della generazione del grafico. Tuttavia, ciò non riesce ancora. La generazione del grafico è semi-thread-proof con flock. Registro i tempi di esecuzione e per la generazione del grafico è fino a 5 minuti durante un elevato carico di I / O, apparentemente con un grafico mancante per un massimo di 4 minuti.
Il tempo è esattamente corrispondente all'attività di postgres (questo a volte succede anche durante il giorno, anche se non così spesso) Ionicing fino a prio in tempo reale (C1 N6 graph_cron vs C2 N3 postgres), nicing molto al di sopra dei postgres (-5 graph_cron vs 10 postgres ) non ha risolto il problema.

Supponendo che i dati non vengano raccolti, il problema aggiuntivo è che ionice / nice in qualche modo non funziona ancora.
Anche con il 90% di IOwait e un carico di 100 ero ancora in grado di utilizzare il comando di generazione dei dati gratuitamente senza più di forse 5 secondi di ritardo (almeno sui test).

Purtroppo non sono stato in grado di riprodurlo esattamente durante i test (avendo solo un sistema di sviluppo virtualizzato)

versioni:

Kernel 2.6.32-5-686-bigmem
Debian Squeeze rrdtool 1.4.3 Hardware: HDD SAS 15K RPM con LVM in hardware
Opzioni di montaggio RAID1 : ext3 con rw, errori = remount-ro
Scheduler: CFQ
crontab:

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

Sembra che ci sia un BUG in qualche modo correlato da Mr Oetiker su github per rrdcache:
https://github.com/oetiker/rrdtool-1.x/issues/326

Questo in realtà potrebbe essere il mio problema (scritture simultanee) ma non spiega al cronjob di non fallire. Nell'ipotesi in realtà ho 2 scritture simultanee flock -nrestituirei il codice di uscita 1 (per pagina man, confermato in fase di test) Dato che non ricevo neanche un'e-mail con l'output e l'osservazione che il cronjob funziona davvero bene tutte le altre volte che lo sono in qualche modo perso.

Esempio di output: grafico di carico della CPU con righe mancanti

Sulla base del commento ho aggiunto la fonte importante dello script di aggiornamento.

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

Cosa mi manca o dove posso controllare ulteriormente?

Ricorda: sistema produttivo quindi nessun dev, nessun stacktrace o simile disponibile o installabile.

— Dennis Nolte
fonte

Molto tempo fa quando MRTG fu sostituito da RRDgraph. Uno dei meravigliosi cambiamenti dal vecchio al nuovo era che RRDgraph in realtà genera le immagini solo quando c'è una richiesta di visualizzazione. Il vecchio MRTG generava grafici completamente nuovi per ogni punto dati ogni cinque minuti. Il tuo problema è con la raccolta dei dati, non con il rendering del grafico.

— Ericx,

@ericx grazie per il tuo commento. Ho aggiunto la fonte per la generazione dei dati. Pensi ancora che il problema sia il comando vmstat invece che IOnice / nice in qualche modo non funziona correttamente? Se è così, perché la pensi così?

— Dennis Nolte,

La tua croncattura STDERR è ovunque? Su FreeBSD di solito li eseguo sotto periodic every5e ho un /var/log/periodic.every5che generalmente cattura eventuali errori. Vorrei anche scaglionare i tre script e possibilmente ruotare l'ordine per vedere se uno in particolare si blocca. La maggior parte della mia esperienza RRDTool è stata con cricketcui ho avuto la propria registrazione. I cricketregistri erano eccellenti per trovare problemi. Stai davvero collezionando ogni minuto? (* * * * * invece di * / 5 * * * *) Qual è la granularità del grafico? RRD è impostato automaticamente su intervalli di 5 minuti.

— Ericx,

questo è il comando che è stato utilizzato inizialmente per crearli: create cpu.rrd --step 300 DS: sys: GAUGE: 70: U: U DS: user: GAUGE: 70: U: U RRA: MEDIA: 0.01: 1: 6351 quindi questo significa che hai appena trovato un altro bug, grazie. ho riscritto STDOUT e STDERR per quello script per i test, non è stato registrato nulla che mi ha aiutato a tornare quando ho provato la prima volta. aggiungerò l'output domani

— Dennis Nolte,

In termini di undestanding del "fallimento", il display di rrdtool si basa su un ciclo di polling di 5 minuti. Se non si completa l'elaborazione di un ciclo prima dell'inizio di quello successivo e se la raccolta di dati e la produzione di grafici fanno parte della stessa operazione di elaborazione, si otterrà un punto dati mancante.

— MC0e

Immagino che non sia il rrdtool che non può aggiornare il grafico, ma piuttosto i dati non possono essere misurati a questo punto. A proposito, il tuo metodo di misurazione delle statistiche della CPU e della memoria è semplicemente sbagliato, perché ti dà un risultato immediato. Il carico della CPU e della memoria può cambiare drasticamente nell'intervallo di 60 secondi, ma prenderai solo un valore. Dovresti davvero prendere in considerazione la raccolta di dati SNMP, che forniscono dati medi su un intervallo. Inoltre, l'intera pipa sembra essere più costosa e lenta di una chiamata snmpget. Potrebbe essere il motivo principale delle lacune.

— drookie
fonte

proprio come seguito, è stato questo. Una volta che siamo riusciti a spostare alcuni processi affamati di risorse su un altro server, i grafici vengono generati correttamente.

— Dennis Nolte,