我们有一个Graphite服务器来收集通过collectd，statsd，JMXTrans的数据…几天以来，我们的数据经常有漏洞。 通过挖掘我们现有的数据，我们可以看到碳caching大小（从50K到4M）有所增加。 我们看不到收集到的指标数量有所增加（metricsReceived稳定在30万左右）。 查询数量从1000个增加到1500个。
奇怪的是，当caching大小增加时，cpuUsage从100％（我们有4个CPU）略微下降到50％。
奇怪的是，如果从磁盘读取八位字节，并且写入的八位字节数量减less，我们看到数量增加。
我们的碳configuration主要是默认值：
很明显，我们的系统发生了一些变化，但我们不明白什么，也不知道如何find这个原因。
任何帮助？
这不是一个石墨堆栈的错误，而是一个IO瓶颈，很可能是因为你的存储没有足够高的IOPS。 正因为如此，队列不断积累，并以4M溢出。 那时候，你会丢失那么多排队的数据，这在稍后会反映出来，就像图中的随机“间隙”。 您的系统无法跟上接收指标的规模。 它不断充满和溢出 。
奇怪的是，当caching大小增加时，cpuUsage从100％（我们有4个CPU）略微下降到50％。
这是因为你的系统开始交换，并且由于IO等待，CPU获得很多“空闲时间”。
要添加上下文，我有500个预configuration的IOPS在aws系统上，我收到了一些40K指标。 队列稳定在50K。
其他回答者提到磁盘I / O瓶颈。 我会谈到networking瓶颈是另一个原因。
在我的环境中，我们运行一组前端UI服务器（httpd，memcached）; 另一组中继层中继（碳 – 中继执行转发和聚合）; 和一个后端层（httpd，memcached，carbon-c-relay和carbon-cache）。这些集群中的每一个都由EC2中的多个实例组成，总共每分钟处理1500万个指标。
我们遇到了一个问题，那就是我们发现由总和“求和”函数生成的指标存在差距，而且总计值也不正确（太低）。 通过在中间层重新启动碳-c继电器，问题将得到缓解，但几个小时之后差距会再次出现。
我们在中间层和后端层都进行了聚合（后端层聚合了从中间层传递给它的聚合度量）。
中间层主机不受CPU限制，不受磁盘限制，并且对内存没有限制。 这加上这个问题只会在重新启动中继过程几个小时后出现，这意味着存在networking瓶颈。 我们的解决scheme只是将更多的主机添加到中间层。 这样做会立即导致汇总的度量标准正确执行，并且不会遇到间隙。
networking堆栈中的确切位置是瓶颈？ 我无法告诉你。 它可能已经在Linux主机上; 它可能已经在亚马逊一边。