Cassandra 在大量插入时内存不足答案

【问题标题】：Out of memory in Cassandra on massive insertsCassandra 在大量插入时内存不足
【发布时间】：2012-04-12 20:08:29
【问题描述】：

我正在尝试插入具有大列值 (1-25Mb) 的数据，几秒钟后，我的一个节点因抛出 OOM 或陷入无休止的 GC 循环而死亡。

它通常会尝试刷新 CF，但随后会显示 由于没有脏列族，因此无法减少堆使用量。

由于日志建议我减少内存表/缓存大小，我试图找出是什么耗尽了所有这些内存以调整我的设置，所以我运行了nodetool flush / invalidaterowcache / invalidatekeycache，然后通过 jconsole 触发了 GC。

不幸的是，即使服务器处于空闲状态，我的内存使用率仍然很高 (>60%)。

所以，我的问题是为什么插入大值时服务器内存不足？还有，为什么服务器不回馈一些内存？

编辑

我做了一个heapdump，堆满了byte[]，主要是org.apache.cassandra.io.sstable.IndexSummary$KeyPosition的引用。

我不明白这是怎么可能的，因为一切都应该被刷新。

【问题讨论】：

你的 JVM 在 Linux 机器上是如何设置的？（堆大小、垃圾收集设置等）另外，您如何配置 Cassandra？您是否在列族上使用二级索引？我要检查的第一个地方是确保您的 linux 机器上有足够大的堆。服务器不会释放内存，因为它要么具有对数据的活动引用（您刚刚放入的所有内容），要么您正在使用不经常收集的天真的停止世界 GC，并且当它停止时一切。

标签： c# cassandra

【解决方案1】：

在我看来，您遇到了infamous memory fragmentation 问题。我不确定 Cassandra 是否消除了一些碎片问题，但通常，在 .NET 和可能的任何 Windows 程序中，都可能遇到这种情况。

当您选择任何超过 85000 字节（是的，奇数，但就是这样）时，对象将存储在大对象堆中。 LOH 仅作为第 2 代进行 GC，但更糟糕的是，它从不压缩。部分原因是the way the OS is implemented造成的。

结果：当您存储 2MB、5MB、3MB、2MB、3MB 的对象并且 2MB 的对象被 GC 处理时，您可能有 4MB 可用空间。但是，如果您随后尝试创建一个 3MB 的新对象，则由于碎片（2MB 的 2 个孔）而无法将其放置在那里并移动到堆的顶部。最终，这用完了空间。所以：可能有足够的可用内存，但无论如何你都会得到 OOM，因为这种碎片化。

此问题主要出现在 64 位 (WOW64) 和 32 位 Windows 上的 32 位 x86 应用程序上。 64 位应用程序也存在碎片问题，但由于虚拟内存要大得多，因此在遇到实际碎片问题之前，您首先要对内存进行分页（变得非常慢）。

如果这确实是问题（您可以使用VMMap 和WinDbg 直观地检查碎片），您可以通过创建一个大型字节池并重用您自己的池来解决它，从而防止碎片。

【讨论】：

不幸的是我的问题是在 Cassandra 方面，所以是 Java / Linux。此外，我刚刚做了一个堆转储，它实际上已经满了。
@alprema：碎片不是 .NET 特定的，甚至不是操作系统特定的。如果你调查 heapdump 并没有发现差距，那么 Cassandra 实际上是真的内存不足。卡桑德拉虫？你试过这些comments.gmane.org/gmane.comp.db.cassandra.user/22595吗？

【解决方案2】：

我用 MAT 调查了堆转储，结果发现 OutOfMemory 发生是因为 Thrift 使用了很多内存。

由于我必须为我的列值传输大量数据，我将这些设置更改为 128，以“安全”：

thrift_framed_transport_size_in_mb
thrift_max_message_length_in_mb

但事实证明，Thrift 为每个接收线程分配了一个byte[2 * thrift_max_message_length_in_mb]，而我有其中的三个。所以我只使用 768Mb 作为接收缓冲区...

将设置更改为 32 解决了我的问题。

【讨论】：