压缩导致内存不足错误并关闭 Cassandra 进程

Compaction cause out of memory error and shutdown the Cassandra process

在生产中使用具有 18 个节点和 32 GB 内存的 Cassandra 3.11,每周压缩作业在 system.log 和 debug.log 中抛出以下错误,然后 Cassandra 进程终止,我必须启动 Cassandra .

ERROR [ReadStage-4] JVMStabilityInspector.java:142 - JVM state determined to be unstable.  Exiting forcefully due to: java.lang.OutOfMemoryError: Direct buffer memory

ERROR [ReadStage-5] JVMStabilityInspector.java:142 - JVM state determined to be unstable.  Exiting forcefully due to: java.lang.OutOfMemoryError: Direct buffer memory

DEBUG [ReadRepairStage:29517] ReadCallback.java:242 - Digest mismatch:
org.apache.cassandra.service.DigestMismatchException: Mismatch for key DecoratedKey(-3787568997731881233, 0000000004ca5c48) (2b912cd2000e6bb5b481fa849e438ae4 vs 962e899380ce22ac970c6be0014707de)

Java 堆大小为 8 GB

/opt/apache-cassandra-3.11.0/conf/jvm.options
-Xms8G
-Xmx8G

是否有任何其他解决方法而不是增加堆大小来防止压缩期间出现内存不足问题?

就其本身而言,您发布的错误并没有向我表明它们与压缩有关。相反,线程 ID (ReadStage-*) 表明它们是读取请求的结果。

如果有的话,DigestMismatchException 更能说明问题,因为它表明您的副本不同步。如果您在日志中看到丢失的突变,则清楚地表明节点已过载。该症状更符合您所看到的 OOM,我认为这是您的集群无法跟上应用程序流量的结果。

对于 32GB RAM 系统,我们建议将生产系统的堆内存增加到 16GB。我知道你不想这样做,但这是一个适当的行动,如果我管理集群,我会这样做。

我还要确保 data/commitlog/ 位于不同的 disks/volumes 上,这样它们就不会竞争相同的 IO(除非你有直接连接的 SSD) .如果您仍然看到大量丢弃的突变,请考虑通过添加更多节点来增加集群的容量。干杯!