Cassandra 压缩任务卡住

我在由 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% 的任务并没有消失，是的，我们已经等了几个小时才让它们消失，但它们不会消失。 t;我们发现解决此问题的唯一方法是重新启动节点。

Edit:

这是来自的输出nodetool compactionstats

Edit 2:

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

Edit 3:

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

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

Edit 4:

输出来自iostat在压缩卡住的节点上，看到高“iowait”

天蓝色存储

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

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

查看具体信息here https://academy.datastax.com/demos/enterprise-deployment-microsoft-azure-cloud