设定：
我们有3个节点Cassandra集群，每个节点上的数据大约为850G，我们为Cassandra数据目录设置LVM（目前包含3个驱动器800G + 100G + 100G），并为cassandra_logs提供单独的卷（非LVM）
版本：
卡桑德拉v2.0.14.425
DSE v4.6.6-1
问题：
在每个节点上的LVM中添加第三个（100G）卷之后，所有节点的磁盘I / O都非常高，并且它们经常停机，服务器也变得无法访问，我们需要重新启动服务器，服务器不需要。 t稳定，我们需要每隔10-15分钟重新启动。
其他信息：
我们在所有节点上配置了DSE推荐的服务器设置（vm.max_map_count，文件描述符）
每个节点上的RAM：24G
每个节点上的CPU：6核/ 2600MHz
每个节点上的磁盘：1000G（数据目录）/ 8G（日志）
答案 0 :(得分：8)
我怀疑，您的磁盘上存在吞吐量问题。这是我看到的为您提供背景信息的内容。三个节点的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。我还没有看到Cassandra在Ceph上的成功部署。它将保持一段时间，然后继续顺序加载。短期内最简单的解决方案是添加更多节点以分散负载。中期是找到一些方法来为顺序磁盘加载优化堆栈，但最终会失败。长期是在真实磁盘和共享存储上获取数据。
我已经告诉过这个问题，在使用Cassandra时，多年来一直在咨询客户＆＃34;如果你的存储有一个以太网插头，那么你做错了＃34;好的经验法则。