我们有一个4核CPU生产系统，它执行很多cronjobs，具有恒定的proc队列和通常的〜1.5负载。
在晚上，我们使用postgres做一些IO密集型工作。我们生成了一个显示负载/内存使用情况的图表（rrd-updates.sh）。这有时在高IO负载情况下“失败”。它几乎每天晚上都在发生，但并不是在每个高IO情况下都发生。
我的“正常”解决方案将是使postgres内容好看，使之离子化并增加图形生成的优先级。但是，这仍然失败。图形生成是带有群的半线程证明。我确实记录了执行时间，并且在高IO负载下，图形生成最多需要5分钟，这似乎导致图形丢失最多需要4分钟。
时间范围与postgres活动完全匹配（有时也会在一天中发生，尽管并不经常发生）进行实时Prio（C1 N6 graph_cron与C2 N3 postgres）之间的联系，在postgres上方进行联系（-5 graph_cron vs 10 postgres） ）没有解决问题。
假设没有收集数据，另一个问题是ionice / nice仍然无法正常工作。
即使有90％的IOwait和100的负载，我仍然能够免费使用数据生成命令，而不会有超过5秒的延迟（至少在测试中）。
可悲的是，我无法在测试中准确地再现这一点（只有虚拟化的开发系统）
版本：
内核2.6.32-5-686-bigmem
Debian Squeeze rrdtool 1.4.3
硬件：硬件LSAS的SAS 15K RPM HDD，硬件RAID1
挂载选项：ext3，带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
似乎有一个与Oetiker先生在github上有关rrdcache的臭名昭著的可能的错误：https :
//github.com/oetiker/rrdtool-1.x/issues/326
这实际上可能是我的问题（并发写入），但不能解释cronjob不会失败。假设我实际上有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}')
我想念什么或在哪里可以进一步检查？
切记：高效的系统，因此没有开发人员，没有堆栈跟踪或类似的可用或可安装的。
cron可以在任何地方捕获STDERR吗？在FreeBSD上，我通常在以下环境下运行它们，periodic every5并且我/var/log/periodic.every5通常会捕获任何错误。我还将错开这三个脚本，并可能旋转顺序以查看某个脚本是否挂起。我在RRDTool上的大部分经验都是使用cricket它自己的日志记录。该cricket日志是优秀查找的麻烦。您真的在收集每一分钟吗？（* * * * *代替* / 5 * * * *）图形的粒度是多少？RRD默认为5分钟间隔。