cassandra - Cassandra 节点上的高磁盘 I/O

Question

设置:
我们有 3 个节点的 Cassandra 集群，每个节点上的数据大约为 850G，我们为 Cassandra 数据目录(目前包含 3 个驱动器 800G + 100G + 100G)设置了 LVM，并为 cassandra_logs 设置了单独的卷(非 LVM)

版本:
Cassandra v2.0.14.425
DSE v4.6.6-1

问题:
在每个节点上的 LVM 中添加第 3 个(100G)卷后，所有节点的磁盘 I/O 都非常高，并且经常宕机，服务器也变得无法访问，我们需要重新启动服务器，服务器没有得到稳定，我们需要在每 10 - 15 分钟后重新启动。

其他信息:
我们在所有节点上都配置了 DSE 推荐的服务器设置(vm.max_map_count、文件描述符)
每个节点的内存:24G
每个节点上的 CPU : 6 核/2600MHz
每个节点上的磁盘:1000G(数据目录)/8G(日志)

Answer 1

正如我怀疑的那样，您的磁盘存在吞吐量问题。这是我为您提供的背景资料。 nodetool tpstats您的三个节点的输出有以下几行:

Pool Name                    Active   Pending      Completed   Blocked  All time blocked
FlushWriter                       0         0             22         0                 8
FlushWriter                       0         0             80         0                 6
FlushWriter                       0         0             38         0                 9 

我关心的专栏是 All Time Blocked。作为完成的比率，你有很多阻塞。刷新写入器负责将内存表刷新到磁盘，以防止 JVM 耗尽内存或产生大量 GC 问题。 memtable 是表的内存表示。随着您的节点进行更多写入，它们开始填满并需要刷新。该操作是对磁盘的长顺序写入。书签那个。我会回来的。

当flushwriters 被阻塞时，堆开始填满。如果它们保持阻塞，您将看到请求开始排队，最终节点将 OOM。

压缩也可能正在运行。压缩是将 SSTable 长时间连续读取到内存中，然后对合并排序结果进行长时间的连续刷新。更多的顺序 IO。

所以磁盘上的所有这些操作都是顺序的。不是随机的 IOP。如果您的磁盘无法同时处理顺序读写，IOWait 就会启动，请求会被阻塞，然后 Cassandra 的日子就很糟糕了。

你提到你正在使用 Ceph。我还没有看到 Cassandra 在 Ceph 上的成功部署。它会保持一段时间，然后在顺序加载时翻倒。短期内最简单的解决方案是添加更多节点以分散负载。中期是找到一些方法来优化您的堆栈以进行顺序磁盘加载，但这最终会失败。长期是将您的数据放在真实磁盘和共享存储上。

多年来，我在使用 Cassandra 时曾向咨询客户说过“如果您的存储设备有以太网插头，那您就做错了” 很好的经验法则。