Cassandra节点上的高负载

出于某种原因,我在Cassandra节点上遇到高负载.以下是获取图片的一些信息.

当我创建一个全新的群集时,负载会持续几天低,并且会在一周之后或之后的某个时间内逐渐增加,导致我发现整个群集中的不稳定性

我正在拍摄我的一个密钥空间的快照,每4小时包含大约300-400 MB的数据并删除超过7天的密钥空间,所有这些都在OpsCenter中配置

群集正在Microsoft Azure中的条带化磁盘上运行

节点运行在2个内核和3.5 GB的RAM上,我很清楚这比推荐的硬件低,但这不应该是高负载的原因,我尝试在4核上运行7 GB的内存和看到没有区别

我敢肯定可能会有一大堆可能导致高负荷的东西,但我想有些东西比其他东西更有可能.

看来这种高负载是由OpsCenter中的Repair Service引起的.必须有一些设置来调整服务如何运行修复.

您可以通过向opscenterd.conf添加[repair_service]部分来配置修复服务.

调整的主要杠杆是:

max_parallel_repairs = 0  

你可以增加这一点,直到修复完成得足够快,以便在你需要的时间内完成(

min_repair_time = 5

如果您没有那么多数据,则修复服务可能会过快地完成并重新启动 - 从而导致不必要的开销.您可以增加此值以确保不会过于频繁地运行修复

snapshot_override

同样,如果您没有太多数据并且修复服务完成得太快,您将生成太多快照(默认情况下,修复服务会在每次修复之前拍摄快照).如果您的快照目录非常快速地填满,您可能需要将其关闭,直到您将服务调整为仅运行一次(使用raise min_repair_time drop parallel_repairs).

注意:修复服务的重点是将昂贵/资源消耗的修复过程分散到较小的作业中,这意味着您可以随时将总体CPU利用率提高5%或10%,而不是将其高峰和影响常规修复运行期间的工作量.

高级配置的详细信息