在高IO负载下rrdgraph生成失败
我们有一个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 : …