0

我有一个 Graylog2 安装（0.11.0），与作为独立运行的乘客（3.0.21）一起提供服务。它由多个 ElasticSearch 服务器和 MongoDB 提供支持。

大约一周前，它运行的是 Passenger 3.0.18，当您尝试加载消息时，此错误开始出现在 Graylog 服务器日志中：

2013/09/13 13:47:32 [crit] 27720#0: *1451 writev() "/tmp/passenger-standalone.27619/proxy_temp/6/00/0000000006" failed (28: No space left on device) while reading upstream

检查 /tmp/，它的利用率为 8%。同时在前端，当您尝试在 Graylog 中加载“消息”页面时，除了实际消息之外，该页面都可以正常加载。我尝试将Passenger升级到3.0.21并且行为保持不变但错误发生了变化：

2013/09/17 10:16:53 [crit] 3113#0: *10 writev() "/tmp/passenger-standalone.3012/proxy_temp/3/00/0000000003" has written only 4096 of 8192 while reading upstream

接下来我检查了 ES 机器。它们以高 CPU 负载运行，因此我更改了它们从 Graylog 中保留的最大索引数量，这使它们立即回落……但行为仍然没有变化。

我对这个错误的最佳猜测是它是某种超时，但我找不到任何其他人得到这个错误的线程，而且我不明白为什么现在应该发生超时，因为 ES 机器再次在范围内. 所有其他 Graylog 网页都可以正常工作，Streams 也是如此。

4

1 回答 1

0

我最终做了一些事情来解决这个问题。

  1. 将 Graylog 的 processor_wait_strategy 更改为“阻塞”。这大大减少了 graylog-server 应用程序使用的 CPU 量。
  2. 通过减少 Graylog 的 elasticsearch_max_number_of_indices 来减少 ElasticSearch 存储的数据量。
  3. 最有帮助的是，停止 Graylog 服务器，并删除 graylog2_recent ElasticSearch 索引。然后重新启动 Graylog 服务器，它会重新创建它。一旦我这样做了，ElasticSearch 服务器上的 CPU 负载量急剧下降，消息和搜索又开始工作了。索引重新填充后，它继续正常工作。

希望这有助于其他一些可怜的人在谷歌上搜索这个错误。

于 2013-09-19T13:34:47.990 回答