Apache Cassandra：即使所有节点都已启动，提示也会不断创建答案

【问题标题】：Apache Cassandra : Hints are getting created continuosly even if all the nodes are upApache Cassandra：即使所有节点都已启动，提示也会不断创建
【发布时间】：2014-08-25 18:51:30
【问题描述】：

我有一个 5 节点 apache cassandra 2.0.6 集群，具有 48 GB 内存和 2 TB 数据目录和 93 GB 容量的提交日志目录。 cassandra 的 JVM 堆空间为 8 GB。我使用 JVisualVM Mbeans 插件来监控 cassandra 指标。即使所有节点都已启动，提示也会在所有节点中不断创建。并且随着在写入数据时创建提示，有时我面临墓碑压倒性异常，它正在中止查询。任何人都可以解释为什么会发生并为此提供补救措施。

【问题讨论】：

您是否在日志中看到可疑内容？
是的。我的日志每 10 分钟就充满了压倒性异常的墓碑。
错误 [HintedHandoff:1308] 2014-08-28 06:34:33,727 CassandraDaemon.java（第 196 行）线程异常 [HintedHandoff:1308,1,main] 错误 [HintedHandoff:1309] 2014-08-28 06:44:33,077 SliceQueryFilter.java（第 200 行）在 system.hints 中扫描了超过 200000 个墓碑；查询中止（请参阅 tombstone_fail_threshold）错误 [HintedHandoff:1309] 2014-08-28 06:44:33,078 CassandraDaemon.java（第 196 行）线程中的异常 Thread[HintedHandoff:1309,1,main]
嗯，这很清楚。您是否看到与“节点已关闭”相关的内容？
现在我没有收到节点关闭错误。但是一周前，我收到错误消息，指出“Gossiper 已关闭，Native thrift 已关闭”。我的旧日志已被清除，因此我无法提供确切的日志语句。

标签： cassandra mbeans hints tombstone

【解决方案1】：

提示墓碑压倒性异常的问题是已知的，并且有 Jiras 可以改善这种情况。

您的日志中是否出现了 tombstone ERROR 或 tombstone WARN？如果您遇到了墓碑错误，那么您将需要暂时增加阈值以避免错误并允许您的提示进行处理。

如果您的集群在正常操作下继续定期生成提示，那么它显然以某种方式不堪重负，需要解决该问题，以便正常操作不需要提示。最可能的原因是长时间的 GC 暂停。您是否在系统日志中看到“GC for”消息？如果是这样，停顿的平均时间（以毫秒为单位）和频率如何？ ParNew 与 ConcurrentMarkSweep 有多少？

【讨论】：

感谢您的回复。我收到墓碑错误而不是警告。我尝试将 tombstone_failure_threshold 从 100000 增加到 200000，但正如您所说，它暂时修复了错误，但在几个小时后错误开始重新出现。
关于 GC 暂停：ParNew 平均需要 300 毫秒，每分钟运行一次。ConcurrentMarkSweep 需要 250 毫秒，它随机运行，平均每 10 分钟运行一次。现在我们有 write_request_timeout_in_ms: 2000 并且我们计划将其增加到 10000 毫秒（假设由于写入失败而生成提示，因为在我的集群中写入以每天 170 GB 的速度发生）。您能否解释一下 GC 是如何导致提示触发提示的，以及我当前的 ParNew 和 ConcurrentMarkSweep 参数值是否可以，如果不是如何调整它？
我在下面提供系统日志供您参考
INFO [ScheduledTasks:1] 2014-08-27 08:56:51,354 GCInspector.java（第 116 行）ParNew 的 GC：1 个集合 304 毫秒，使用 5079302472；最大值为 8422162432 INFO [ScheduledTasks:1] 2014-08-27 08:57:20,763 GCInspector.java（第 116 行）用于 ConcurrentMarkSweep 的 GC：1 个集合 203 毫秒，使用 5366351976；最大值为 8422162432 INFO [ScheduledTasks:1] 2014-08-27 08:58:13,529 GCInspector.java（第 116 行） ParNew 的 GC：1 个集合 231 毫秒，使用 2170074400；最大值为 8422162432
长 ParNew 和 CMS 暂停将导致节点向下显示给协调器，从而存储提示。因此，改进 GC 也将改进提示和整体写入性能。您可能需要增加 cassandra-env.sh 中的 HEAP_NEWSIZE。如果现在是 800M，请尝试将其设置为 1024M 以启动并滚动重启并监控日志中的 GC 事件。