在夜间我们用postgres做一些IO密集型的东西.
我们生成一个显示负载/内存使用情况的图表(rrd-updates.sh)
在高IO负载情况下,这有时会“失败”.
它几乎每天晚上都会发生,但不会出现在每个高IO情况下.
我的“正常”解决方案是使用postgres的东西,并增加图形生成的prio.
然而,这仍然失败.
图表生成是针对flock的半线程证明.
我记录执行时间,并且对于图形生成,在高IO负载期间它最多可达5分钟,似乎导致最多4分钟的图形缺失.
时间框架与postgres活动完全匹配(这有时也会在白天发生,但不是经常发生)
Ionicing到实时prio(C1 N6 graph_cron vs C2 N3 postgres),在postgres上方的切割方式(-5 graph_cron vs 10 postgres)并没有解决问题.
假设没有收集数据,另外的问题是ionice / nice在某种程度上仍然无法正常工作.
即使有90％的IOwait和100的负载,i仍然能够使用数据生成命令,而不会超过5秒的延迟(至少在测试时).
可悲的是,我无法在测试中完全重现这一点(只有一个虚拟的开发系统)
版本：
内核2.6.32-5-686-bigmem
Debian Squeeze
rrdtool 1.4.3
硬件：带硬件RAID1 LVM的SAS 15K RPM硬盘
mount选项：ext3 with rw,errors = remount-ro
调度程序：CFQ
crontab中：
* * * * * root flock -n /var/lock/rrd-updates.sh nice -n-1 ionice -c1 -n7 /opt/bin/rrd-updates.sh
似乎有一个somhow可能与来自Oetiker先生在github上为rrdcache有关的BUG：
https://github.com/oetiker/rrdtool-1.x/issues/326
这实际上可能是我的问题(并发写入),但它没有解释cronjob没有失败.
在asumption中我实际上有2个并发写入flock -n将返回退出代码1(每个手册页,在测试中确认)
因为我没有收到关于输出的电子邮件,并且观察到cronjob确实在其他时间运行正常我不知何故丢失了.
输出示例：
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}')
我想念什么或在哪里可以进一步检查？
记住：生产系统所以没有开发,没有堆栈跟踪或类似的可用或可安装.
