我们有一个 Graphite 服务器，通过 collectd、statsd、JMXTrans 等收集数据……几天以来，我们的数据经常出现漏洞。深入研究我们仍然拥有的数据，我们可以看到 carbon 缓存大小有所增加（从 50K 增加到 4M）。我们没有看到收集的指标数量有所增加（metricsReceived 稳定在 300K 左右）。我们的查询数量平均从 1000 个增加到 1500 个。
奇怪的是，当缓存大小增加时，cpuUsage 会从 100%（我们有 4 个 CPU）略微下降到 50%。
奇怪的是，我们发现从磁盘读取的八位字节数量增加了，而写入的八位字节数量减少了。
我们的 carbon 配置大多采用默认值：
- MAX_CACHE_SIZE = inf
- 每秒最大更新次数 = 5000
- 每分钟最大创建数 = 2000
显然，我们的系统发生了一些变化，但我们不明白是什么变化，也不知道如何找到原因……
有什么帮助吗？
答案1
这不是 Graphite Stack 的 bug，而是 IO 瓶颈，很可能是因为您的存储没有足够高的 IOPS。因此，队列不断增加，并在 4M 时溢出。此时，您失去如此多的排队数据，稍后会反映为图表中的随机“间隙”。您的系统无法赶上接收指标的规模。它保持充满并溢出。
奇怪的是，当缓存大小增加时，cpuUsage 会从 100%（我们有 4 个 CPU）略微下降到 50%。
这是因为您的系统开始交换，并且由于 IO 等待，CPU 获得大量“空闲时间”。
为了补充上下文，我在 AWS 的系统上配置了 500 个 IOPS，我在该系统上收到了大约 40K 指标。队列稳定在 50K。
答案2
其他回答者提到了磁盘 I/O 瓶颈。我将讨论网络瓶颈，这是造成这种情况的另一个原因。
在我的环境中，我们运行一组前端 UI 服务器 (httpd、memcached)；另一组中间层中继 (carbon-c-relay 执行转发和聚合)；以及一个后端层 (httpd、memcached、carbon-c-relay 和 carbon-cache)。每个集群均由 EC2 中的多个实例组成，每分钟总共处理 1500 万个指标。
我们遇到了一个问题，即聚合“sum”函数生成的指标存在差距，而且聚合值不正确（太低）。通过重新启动中间层的 carbon-c-relay 可以缓解此问题，但几个小时后差距又会出现。
我们在中间层和后端层都进行了聚合（后端层聚合了从中间层传递给它的聚合指标）。
中间层主机不受 CPU 和磁盘的限制，也不受内存限制。再加上问题只会在重新启动中继进程几个小时后出现，这意味着存在网络瓶颈。我们的解决方案只是向中间层添加更多主机。这样做立即导致聚合指标正常运行并且不会出现差距。
网络堆栈中瓶颈的具体位置在哪里？我无法告诉你。它可能在 Linux 主机上；也可能在 Amazon 端。