我在由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;我们发现解决此问题的唯一方法是重新启动节点。





编辑:

这是nodetool compactionstats的输出



编辑2:

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

编辑3:

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



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



编辑4:

结实压缩的节点上iostat的输出,请参见较高的“ iowait”

最佳答案

天蓝色存储
Azure将磁盘资源分配到单个用户帐户下的多个存储帐户中。一个用户帐户中可以有许多存储帐户。
为了运行DSE [或cassandra],必须注意,如果像本文档中的脚本示例中那样配置DSE [或cassandra],则不应在两个以上的节点之间共享一个存储帐户。本文档将每个节点配置为具有16个磁盘。每个磁盘的限制为500 IOPS。在RAID-0中进行配置时,这将产生8000 IOPS。因此,两个节点将达到16,000 IOPS,三个将超过限制。
查看详情here

07-24 09:53
查看更多