卡桑德拉压实任务陷入困境

Question

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

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

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

但是，如果节点重新启动，则卡住的任务不会显示，并且负载再次处于正常水平。

由于我们的群集中没有太多数据，我们正在使用min_repair_time中定义的opscenterd.conf参数来延迟修复服务，因此它不会经常完成

看起来有点奇怪的是，那些被标记为“完整”且显示100％进度的任务不会消失，是的，我们已经等了好几个小时让他们离开但是他们不会;我们发现解决这个问题的唯一方法就是重启节点。

修改

以下是nodetool compactionstats

的输出

编辑2：

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

编辑3：

这是dstat在行为正常的节点上的输出

这是在压缩卡住的节点上从dstat输出

编辑4：

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

Answer 1

azure storage

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

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

查看详情here

Answer 2

所以，这已成为一个长期以来一直在调查中的问题，我们已经找到了解决方案，但是，我们无法确定造成这些问题的底层问题是什么，但是我们甚至得到了一个线索，没有什么可以确认的。

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

我们使用多个实用程序来确认CPU在等待IO响应的大部分时间，当我们告诉自己该节点被卡住了＃34;时。显然，IO和最可能的RAID设置导致了这一点。我们在MDADM设置等方面尝试了一些差异，但没有设法使用RAID设置来解决问题。

我们开始调查Azure高级存储（仍在预览中）。这样可以将磁盘连接到其底层物理存储实际上是SSD的VM。所以我们说，好吧，SSDs =＆gt;更多IOPS，让我们试一试。我们没有使用SSD设置任何RAID。我们每个VM只使用一个SSD磁盘。

我们已经运行群集近三天了，我们已经对它进行了很多压力测试但是还没有能够重现这些问题。

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

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

这两个问题紧密相连，很可能是我们基本上只是以错误的方式设置磁盘。然而，SSDs对人们的影响力更大，因此我们肯定会继续使用SSD。

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

Answer 3

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

Answer 4

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

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

1. 将键空间（例如opsc键空间）添加到ignored_keyspaces设置
2. 您还可以通过调整1min_ttl设置
来降低此表格上的TTL

来源： Opscenter Config DataStax文档 Metrics Config DataStax文档