rrdgraph falha em alta carga de IO

Question

Temos um sistema de produção de CPU de 4 núcleos que faz muitos cronjobs, com fila de procs constantes e uma carga normal de ~ 1.5.

Durante a noite, fazemos algumas coisas intensivas em IO com postgres. Nós geramos um gráfico mostrando o uso de carga / memória (rrd-updates.sh) Isso "falha" às vezes em situações de carga de IO alto. Está acontecendo quase todas as noites, mas não em todas as situações de IO.

Minha solução "normal" seria agradável e ionizar o material do postgres e aumentar o prio da geração de gráficos. No entanto, isso ainda falha. A geração de gráficos é à prova de semi-thread com floco. Registro os tempos de execução e, para a geração do gráfico, é de até 5 min durante a alta carga de I / O, aparentemente resultando em um gráfico ausente por até 4 min.
O período de tempo é exatamente compatível com a atividade do postgres (isso às vezes acontece durante o dia também, embora não com frequência) Ionicing até o prio em tempo real (C1 N6 graph_cron versus C2 N3 postgres), muito acima do postgres (-5 graph_cron vs 10 postgres) não resolveu o problema.

Assumindo que os dados não são coletados, a questão adicional é a ionização / nice de alguma forma ainda não funciona.
Mesmo com 90% de IOwait e uma carga de 100, eu ainda era capaz de usar o comando de geração de dados sem mais do que talvez 5 segundos de atraso (no teste, pelo menos).

Infelizmente, não consegui reproduzir isso exatamente no teste (tendo apenas um sistema de desenvolvimento virtualizado)

Versões:

Kernel 2.6.32-5-686-bigmem
Debian Squeeze rrdtool 1.4.3 Hardware: SAS 15K RPM HDD com LVM em hardware RAID1
opções de montagem: ext3 com rw, errors = remount-ro
Agendador: CFQ
crontab:

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

Parece haver um BUG possivelmente relacionado ao som de Mr Oetiker no github para rrdcache: link

Isso, na verdade, pode ser meu problema (gravações simultâneas), mas não explica o cronjob para não falhar. Na suposição eu realmente tenho 2 gravações simultâneas flock -n retornaria o código de saída 1 (por página man, confirmada no teste) Como eu não recebo um e-mail com a saída e a observação de que o cronjob realmente funciona bem todas as outras vezes, estou de alguma forma perdido.

Exemplo de saída:

Combasenocomentário,adicioneiafonteimportantedoscriptdeatualização.

rrdtoolupdate/var/rrd/cpu.rrd$(vmstat52|tail-n1|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}')

O que eu sinto falta ou onde posso verificar mais?

Lembre-se: sistema produtivo, de modo que nenhum desenvolvedor, nenhum stacktrace ou similar disponível ou instalável.

    

Answer 1

Eu acho que não é o rrdtool que não pode atualizar o gráfico, mas os dados não podem ser medidos neste momento. By the way, seu método de medição de estatísticas de CPU e memória é apenas errado, porque lhe dá resultado instantâneo. A carga da CPU e da memória pode mudar drasticamente ao longo do intervalo de 60 segundos, mas você terá apenas um valor. Você deve realmente considerar dados SNMP, que fornecem dados médios em um intervalo. Além disso, o tubo inteiro parece ser mais caro e lento que uma chamada snmpget. Pode ser o principal motivo das lacunas.