rrdgraph 生成在高 IO 负载下失败

Question

我们有一个 4 核 CPU 生产系统，它执行大量 cronjobs，具有恒定的 proc 队列和~1.5 的通常负载。

在夜间，我们用 postgres 做一些 IO 密集型的事情。我们生成一个图表，显示负载/内存使用情况 (rrd-updates.sh) 这有时会在高 IO 负载情况下“失败”。几乎每晚都会发生这种情况，但并非在所有高 IO 情况下都会发生。

我的“正常”解决方案是对 postgres 内容进行优化和离子化，并增加图形生成的优先级。然而这仍然失败。图生成是使用 flock 进行半线程证明的。我确实记录了执行时间，并且在高 IO 负载期间生成图形最多需要 5 分钟，这似乎导致图形丢失长达 4 分钟。
时间范围与 postgres 活动完全匹配（这有时也发生在白天，虽然不是那么频繁）离子化到实时 prio（C1 N6 graph_cron vs C2 N3 postgres），在 postgres 之上（-5 graph_cron vs 10 postgres）很好) 没有解决问题。

假设没有收集数据，额外的问题是 ionice/nice 不知何故仍然无法正常工作。
即使有 90% 的 IOwait 和 100 的负载，我仍然能够免费使用数据生成命令，而没有超过 5 秒的延迟（至少在测试中）。

遗憾的是，我无法在测试中完全重现这一点（只有一个虚拟化的开发系统）

版本：

内核2.6.32-5-686-bigmem
Debian Squeeze rrdtool1.4.3 硬件：SAS 15K RPM HDD，硬件 RAID1
挂载选项中的LVM ：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

Oetiker 先生在 github 上的 rrdcache 似乎有一个可能相关的 BUG：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}')

我错过了什么或我可以在哪里进一步检查？

请记住：生产系统，因此没有开发，没有堆栈跟踪或类似可用或可安装。

Answer 1

我猜不是rrdtool无法更新图表，而是此时无法测量数据。顺便说一句，您测量 CPU 和内存统计数据的方法是错误的，因为它会立即给出结果。CPU 和内存负载可能会在 60 秒间隔内发生巨大变化，但您只能采用一个值。您确实应该考虑获取 SNMP 数据，它给出了某个时间间隔的平均数据。另外，整个管道似乎比 snmpget 调用更昂贵且更慢。可能是差距的主要原因。