Cassandra Compaction占用所有资源并导致节点失败。

Question

我在测试卡桑德拉的时候遇到了非常奇怪的问题。我有一个非常简单的列族，它存储视频数据(键指向时间段，只有一个列包含~2MB视频)。

用例

我开始使用Hector (循环)将数据加载到6个空节点(Cassandra为8GB RAM )--加载在4个线程中运行，每个线程每秒增加4行。

过了一段时间(运行负载约小时)，接近100-200 GB的节点被添加到节点(取决于复制因子)，然后一个或多个节点变得不可访问。(没有点击，只需重新启动就可以了)

为什么紧实

我确实使用了分层压缩和监视系统(Debian)，我可以看到它实际上并不是写而是压缩，它占用了几乎所有的资源(磁盘、内存)，并导致服务器拒绝写，而不是失败。

经过30到40分钟的测试压缩后，任务就不能被处理和排队了。有趣的是，没有删除和更新-所以压缩只是一次又一次地读/写数据，而没有给我带来实际价值(就像晚上可以压缩一次)。

当我放慢速度--即运行2个线程，延迟1秒时，事情会变得更好，但是当节点上有20 GB而不是100 GB时，它是否仍然工作。

卡桑德拉是否对此类工作负载进行了优化？资源如何在压缩和读/写之间正常分布？

网络驱动程序的更新更新解决了不可访问集群的问题

谢了谢尔盖。

Answer 1

卡桑德拉将使用in_memory_compaction_limit_in_mb内存进行压缩。在同时进行读和写的同时运行压缩是例行的。同样正常的是，如果您继续以尽可能快的速度对其进行写操作，则压缩可能会落后；如果您的读取工作负载要求紧实操作是最新的或随时接近它，那么您将需要一个更大的集群来将负载分散到更多的机器上。

对于在线查询，每个节点推荐的磁盘数量最多可达500 if，如果您正在推送它，则可能是1TB。请记住，如果节点失败，则必须重新构建此数据量。典型的Cassandra工作负载是CPU绑定或iops绑定的，而不是磁盘空间绑定，所以无论如何您都不能很好地利用这个空间。

(还可以对Cassandra进行批处理分析，我们使用的是Cassandra文件系统，在这种情况下，需要更高的磁盘:cpu比是可取的，但我们也使用了定制的压缩策略。)

从您的报告中还不清楚为什么服务器会变得不可访问。这确实是一个操作系统级别的问题。(你们在交换吗？禁用交换将是很好的第一步。)