设置：
我们有 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 都非常高，而且它们经常停机，服务器也变得无法访问，我们需要重新启动服务器，服务器不需要t 变得稳定，我们需要在每 10 - 15 分钟后重新启动。
其他信息：
我们在所有节点上配置了 DSE 推荐的服务器设置（vm.max_map_count，文件描述符）每个节点上的
RAM：每个节点上的 24G
CPU：6 核 / 2600MHz
每个节点上的磁盘：1000G（数据目录）/8G（日志)
正如我所怀疑的，您的磁盘上有吞吐量问题。这是我为您提供背景的内容。您的三个节点的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 时向咨询客户告知过“如果你的存储有以太网插头，那么你做错了” 好的经验法则。