我们正在使用Ganglia监控亚马逊AWS上的云基础架构。 一切工作正常（指标stream动等），除了偶尔gmetad过程将segfault出于蓝色。 gmetad进程在m3.medium EC2上运行，并且正在监视大约50台服务器。 服务器被安排成组，每个组都有一个堡垒EC2，其中度量被收集。 gmetad被configuration为从这些堡垒获取指标 – 其中约10个。
一些有用的事实：
- 我们在所有的EC2上运行Debian Wheezy
- 除了段错误日志，例如“gmetad [11291]：segfault at 71 ip 000000000040547c sp 00007ff2d6572260 gmetad [400000 + e000]的错误4”，崩溃在正常操作中不创build日志。 如果我们使用debugging日志logging手动运行gmetad，那么看起来崩溃与gmetad进行清理有关。
- 当我们意识到，清理过程可能是责怪，我们做了更多的研究。 我们意识到，我们的磁盘IO太高了，并添加了rrdcached为了减less它。 磁盘IO现在要低得多，崩溃发生的次数也less，但仍然是平均每天一次左右。
- 我们有两个系统（开发和生产）。 这两个都出现这个崩溃，但是监视一个小得多的服务器组的开发系统崩溃的次数要less得多。
- 生产系统运行神经节3.3.8-1 + nmu1 / rrdtool 1.4.7-2。 我们已经将开发系统中的神经节升级为神经节3.6.0-2〜bpo70 + 1 / rrdtool 1.4.7-2。 这似乎没有帮助与崩溃。
- 我们有两个系统上运行的configuration，如果它死了重新启动gmetad。 它立即重新启动，没有问题。
有没有人遇到这种崩溃，特别是在亚马逊的硬件？ 我们正在努力寻找解决scheme！