出于某种原因，我的 Cassandra 节点负载很高。这里有一些信息来获取图片。
当我创建一个全新的集群时，负载在几天内一直处于低水平，并且随着时间的推移而增加，一周后它刚刚进入空中，导致我发现整个集群不稳定
我每 4 小时拍摄一个包含大约 300-400 MB 数据的密钥空间的快照，并删除超过 7 天的密钥空间，所有这些都在 OpsCenter 中配置
集群在 Microsoft Azure 的条带磁盘上运行
节点运行在 2 个内核和 3.5 GB RAM 上，我很清楚这低于推荐的硬件，但这不应该是高负载的原因，我尝试在 4 个内核和 7 GB RAM 上运行没看到区别
我确信可能有一整盒可能导致高负载的东西，但我想某些东西比其他东西更有可能。
这种高负载似乎是由 OpsCenter 中的修复服务引起的。必须有一些设置来调整服务如何运行修复。
您可以通过将 [repair_service] 部分添加到 opscenterd.conf 来配置修复服务。
调整的主要杠杆是：
max_parallel_repairs = 0
您可以增加此值，直到您的维修完成速度足够快以至于在您需要的时间段内完成（< gc_grace_seconds）
min_repair_time = 5
如果您没有那么多数据，则修复服务可能完成得太快并重新启动 - 导致不必要的开销。您可以增加此值以确保您不会过于频繁地运行修复
snapshot_override
同样，如果您没有太多数据并且修复服务完成得太快，您将生成太多快照（默认情况下，修复服务会在每次修复之前拍摄快照）。如果您的快照目录很快就满了，您可能需要关闭它，直到您将服务调整为只运行一次（使用 raise min_repair_time drop parallel_repairs）。
注意：维修服务的重点是将昂贵/消耗资源的维修过程分散到较小的作业中，这意味着您可以随时将整体 cpu 利用率提高 5% 或 10%，而不是让它飙升并影响您在定期维修运行期间的工作量。