CounterMutationStage 中的 Cassandra WriteTimeoutException 异常 - 节点最终死亡

Question

我的 cassandra 出现以下异常 system.log:

WARN  [CounterMutationStage-25] 2017-07-25 13:25:35,874 AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread Thread[CounterMutationStage-25,5,main]: {}
java.lang.RuntimeException: org.apache.cassandra.exceptions.WriteTimeoutException: Operation timed out - received only 0 responses.
    at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2490) ~[apache-cassandra-3.9.jar:3.9]
    at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[na:1.8.0_112]
    at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136) [apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) [apache-cassandra-3.9.jar:3.9]
    at java.lang.Thread.run(Unknown Source) [na:1.8.0_112]
Caused by: org.apache.cassandra.exceptions.WriteTimeoutException: Operation timed out - received only 0 responses.
    at org.apache.cassandra.db.CounterMutation.grabCounterLocks(CounterMutation.java:150) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.db.CounterMutation.applyCounterMutation(CounterMutation.java:122) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.service.StorageProxy.runMayThrow(StorageProxy.java:1473) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2486) ~[apache-cassandra-3.9.jar:3.9]
    ... 5 common frames omitted

每当发生这种情况时，CPU 会下降到 0% 一分钟左右，节点会变得无响应，但之后会恢复。但最终，节点会完全死掉（即进程保持运行，但不再响应命令，甚至关闭也不起作用，必须杀死进程）。

更多信息：

卡桑德拉 3.9
G1 垃圾收集器
Windows Server 2012 R2 上的单节点（20 核，256 GB RAM）
使用大量计数器和计数器突变

我尝试过的事情：

删除了日志中的所有其他警告。曾经有关于计数器批次太大的警告，重写了代码以完全不使用批处理。这消除了警告，但没有消除异常问题。
迁移到更大的机器，使用更大的堆和微调 GC 以确保问题不是机器压力过大。 CPU 负载 < 20%。

还有人知道还能做什么吗？我主要担心的是节点完全死亡。我不确定是不是这个异常引起的，但这是我得到的唯一提示...

更新 1：

已更新至 Cassandra 3.11，节点似乎不再死机了。但是，写入超时仍然存在，节点几分钟没有响应，但至少现在恢复了。

更新二：

解决了问题（在专业顾问的帮助下）。我们节点上的 Disc I/O 速度很糟糕，导致刷新写入器的队列越来越长。原因未知，I/O 驱动器（Raid 1 SSD）的速度测试实际上非常好。将节点从 Windows 移动到 Linux（并根据 http://docs.datastax.com/en/landing_page/doc/landing_page/recommendedSettings.html 配置它）解决了问题。

问题的真正原因未知；可能是 Windows 本身，或者只是与 RAID 设置有些不兼容。无论如何，Cassandra 仅在 Linux 上进行了真正的测试，并且更容易找到 Linux 设置的帮助。吸取教训。

Answer 1

这听起来像是一台拥有 20 核和 256GB RAM 的强大机器。 Cassandra 是一个旨在水平扩展的分布式系统。与其将负载推到单个节点，不如尝试添加更多商品硬件并横向扩展。您还可以运行在同一个框中使用 Cassandra 的多个节点。

至少尝试运行在此框中设置几个节点以从无响应状态扩展。大多数情况下 CPU 不是 Cassandra 的瓶颈。是单个节点可以执行的I/O。

检查 cassandra.yaml 中 concurrent_writes 的值，我猜根据 20 核的建议应该是 160 (20 * 8)。
如果可行，尝试将 commitlog 目录和数据目录存储驱动器分开。
扩展写入的最佳方式是添加更多的盒子（在配置中可以更小）。

CounterMutationStage 中的 Cassandra WriteTimeoutException 异常 - 节点最终死亡

Cassandra WriteTimeoutException exception in CounterMutationStage - node dies eventually

cassandra

cassandra-3.0