1

我们在 AWS 上使用 EC2Snitch 有一个具有 3 个节点和复制因子 3 的 Cassandra 集群。

实例类型为 c5.2xlarge（8 核和 16GB RAM）。

集群一直运行良好，但突然从昨天晚上开始，所有节点上的 cassandra 进程开始崩溃。它们被设置为自动重新启动，但在启动后 1 或 2 或 3 分钟内它们会因内存堆空间不足错误而崩溃。

堆配置：

MAX_HEAP_SIZE="4G"
HEAP_NEWSIZE="800M"

在此之后，我们尝试将节点大小增加到 r5.4x 或 128 GB 内存并分配 64GB 堆，但仍然发生相同的事情，无论启动所有 3 个节点还是一次仅启动一个节点。我们可以注意到，第一次垃圾收集在一段时间后发生，然后在几秒钟内连续发生，无法释放任何进一步的内存并最终崩溃。

我们不确定启动后立即将哪些内容拉入内存。

其他参数：

  • 卡桑德拉版本：2.2.13
  • 数据库大小为 250GB
  • hinted_handoff_enabled: true
  • commitlog_segment_size_in_mb: 64
  • memtable_allocation_type: offheap_buffers

任何帮助在这里，将不胜感激。

编辑： 我们发现查询时有特定的表，它会导致 casssandra 节点崩溃。

cqlsh:my_keyspace> select count(*) from my_table ;
ReadTimeout: Error from server: code=1200 [Coordinator node timed out waiting for replica nodes' responses] message="Operation timed out - received only 0 responses." info={'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}

所以我们认为，这与这个特定表中的数据损坏/巨大有关。谢谢。

4

2 回答 2

2

一些快速观察：

  • 如果您要构建新集群，请使用最新的 3.11.x 版本。在 2.2 上构建新的没有意义。
  • 根据您的设置，您似乎正在使用 CMS GC。如果您对 GC 调优不太熟悉，则可以通过切换到 G1 来获得更高的稳定性，而不是指定 a HEAP_NEWSIZE（G1 自己计算 Eden 大小）。
  • 如果您卡在 CMS 上，那么设置HEAP_NEWSIZE为 100mb x 内核的指导是错误的。为了避免 new->old gen 提升，设置HEAP_NEWSIZE为总堆大小的 40%-50% 并增加到MaxTenuringThreshold6-8 之类的东西。
  • 在带有 CMS GC 的 16GB RAM 机器上，我会使用 8GB 堆，然后翻转memtable_allocation_type: offheap_buffers回heap_buffers.
  • 设置commitlog_segment_size_in_mb回 32。通常当人们需要处理它时，它会降低它，除非你也改变了max_mutation_size_in_kb。
  • 您还没有提到崩溃发生时应用程序正在做什么。我怀疑正在发生写入繁重的负载。在这种情况下，您可能需要 3 个以上的节点，或者查看在应用程序端限制运行中写入的数量。

可帮助您的其他信息：

CASSANDRA-8150 - Cassandra 提交者关于良好 JVM 设置的讨论。

Amy's Cassandra 2.1 Tuning Guide - Amy Tobey 的管理员指南在集群配置的良好默认设置方面有很多智慧。

编辑

我们正在使用 G1 GC。

不要Xmn使用 G1设置堆新大小 ( )，这一点非常非常重要。确保被注释掉。

从 my_table 中选择 count(*) ；

是的，未绑定的查询（没有WHERE子句的查询）绝对会给节点带来过度的压力。特别是如果桌子很大。这些类型的查询是 Cassandra 做得不好的地方。找到使用/需要此结果的方法。

您可以通过将分页大小设置得更小（驱动程序端）或使用 Spark 之类的东西来设计它以使其工作。或者也许通过令牌范围查询，并在应用程序端汇总结果。但是你最好不这样做。

于 2020-08-11T18:44:57.853 回答
1

除了@aaron 的 CG 和内存调整建议之外，您还应该检查您是否对数据使用了正确的压缩策略。

https://docs.datastax.com/en/dse/5.1/dse-dev/datastax_enterprise/config/configChooseCompactStrategy.html#Whichcompactionstrategyisbest

您还应该检查损坏的 SStable，因为尝试获取损坏的数据也会以同样的方式表现出来。（例如https://docs.datastax.com/en/cassandra-oss/3.0/cassandra/tools/toolsScrub.html）

于 2020-08-14T08:41:04.823 回答