Cassandra 节点上的高磁盘 I/O

Question

设置：
我们有 3 个节点 Cassandra 集群，每个节点上的数据约为 850G，我们为 Cassandra 数据目录设置了 LVM（目前由 3 个驱动器 800G + 100G + 100G 组成），并为 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、文件描述符）
每个节点上的 RAM：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。作为完成的比例，你有很多阻塞。 flushwriter 负责将 memtables 刷新到磁盘，以防止 JVM 内存不足或产生大量 GC 问题。 memtable 是表的内存表示。随着您的节点进行更多写入，它们开始填充并需要刷新。该操作是对磁盘的长时间顺序写入。书签。我会回来的。

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

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

所以磁盘上的所有这些操作都是顺序的。不是随机 IOP。如果您的磁盘无法同时处理顺序读取和写入，IOWait 会迅速上升，请求会被阻塞，然后 Cassandra 的日子就不好过了。

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

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