Cassandra 压缩任务卡住了

Question

我在由 3 个节点组成的集群中运行 Datastax Enterprise。它们都在相同的硬件下运行：2 核 Intel Xeon 2.2 Ghz、7 GB RAM、4 TB Raid-0

这应该足以运行一个轻负载的集群，存储少于 1 GB 的数据。

大多数情况下，一切都很好，但似乎有时 OpsCenter 中与修复服务相关的运行任务有时会卡住；这会导致该节点不稳定并增加负载。

但是，如果节点重新启动，卡住的任务不会出现，负载又回到正常水平。

由于我们的集群中没有太多数据，我们使用opscenterd.conf 中定义的min_repair_time 参数来延迟修复服务，使其不会过于频繁地完成。

标记为“完成”并显示 100% 进度的任务并没有消失，这确实有点奇怪，是的，我们已经等了好几个小时才让它们消失，但是他们不会；我们发现解决此问题的唯一方法是重新启动节点。

编辑：

这是nodetool compactionstats的输出

编辑 2：

我在 Datastax Enterprise v. 4.6.0 和 Cassandra v. 2.0.11.83 下运行

编辑 3：

这是来自运行正常的节点上的dstat 的输出

这是来自 dstat 的输出，在一个带有卡住压缩的节点上

编辑 4：

来自iostat 节点上的输出，在压缩压缩时，请参阅高“iowait”

Answer 1

天蓝色存储

Azure 在单个用户帐户下的存储帐户之间分配磁盘资源。单个用户帐户中可以有多个存储帐户。

为了运行 DSE [或 cassandra]，请务必注意，如果 DSE [或 cassandra] 的配置类似于脚本中的示例，则不应在两个以上节点之间共享单个存储帐户这个文件。本文档将每个节点配置为 16 个磁盘。每个磁盘的 IOPS 限制为 500。在 RAID-0 中配置时，这会产生 8000 IOPS。因此，两个节点将达到 16,000 IOPS，三个节点将超过限制。

查看详情here

Answer 2

所以，这个问题已经被调查了很长时间，我们已经找到了解决方案，但是，我们不确定导致问题的潜在问题是什么，但我们得到了线索即便如此，也无法证实。

我们所做的基本上是设置一个 RAID-0，也称为条带化，由四个磁盘组成，每个磁盘大小为 1 TB。使用 Stripe 时，我们应该在某处看到 4 倍的单磁盘 IOPS，但我们没有，所以 RAID 的设置显然有问题。

当我们对自己说节点“卡住”时，我们使用了多个实用程序来确认 CPU 大部分时间都在等待 IO 响应。很明显，IO 和很可能是我们的 RAID 设置导致了这种情况。我们尝试了 MDADM 设置等方面的一些差异，但无法使用 RAID 设置解决问题。

我们开始调查 Azure 高级存储（仍处于预览阶段）。这可以将磁盘附加到其底层物理存储实际上是 SSD 的 VM。所以我们说，好吧，SSD => 更多 IOPS，所以让我们试一试。我们没有使用 SSD 设置任何 RAID。每个虚拟机只使用一个 SSD 磁盘。

我们已经运行集群将近 3 天了，我们已经对其进行了很多压力测试，但无法重现问题。

我想我们并没有找到真正的原因，但结论是以下一些一定是我们问题的根本原因。

• 磁盘太慢（写入 > IOPS）
• RAID 设置不正确导致磁盘无法正常运行

这两个问题密切相关，很可能是我们基本上只是以错误的方式设置磁盘。但是，SSD = 给人们更多的权力，所以我们一定会继续使用 SSD。

如果有人遇到与我们在 Azure 上在大磁盘上使用 RAID-0 时遇到的相同问题，请不要犹豫，在此处添加。

Answer 3

您遇到的部分问题是您在这些系统上没有大量内存，而且即使每个节点只有 1GB 的数据，您的节点也可能会遇到 GC 压力。检查system.log 中的错误和警告，因为这将为您的集群上发生的事情提供线索。

Answer 4

OpsCenter 架构中的 rollups_60 表包含所有 Cassandra、操作系统和 DSE 指标的最低（分钟级别）时间序列数据。无论您是否在仪表板中为它们构建图表，都会收集这些指标，以便您可以在需要时获取历史视图。可能是这个表超出了你的小硬件。

您可以尝试调整 OpsCenter 以避免此类问题。以下是 opscenterd.conf 文件中的一些配置选项：

1. 将键空间（例如 opsc 键空间）添加到您的 ignored_keyspaces 设置
2. 您还可以通过调整 1min_ttlsetting 来减少此表的 TTL

来源： Opscenter ConfigDataStax 文档 Metrics ConfigDataStax 文档