旧垃圾收集被填满并且无法清理，可能是因为索引

Question

最近，我尝试使用 Hibernate Search 索引，我正在努力为生产环境找到一个稳定的解决方案。该案例在 Wildfly 10 中，因为我正在使用 HibernateOGM PersistenceContext 进行索引。这会自动将数据添加到索引（Infinispan 文件缓存存储）。

问题是我有一个 MDB 使用来自 JMS 队列的数据，我需要调用这个函数（onMessage，一个队列条目包含大约 100 万个实体 - 大请求）来持久化大约 100 万个实体并发布它们通过无状态 EJB 到另一个 AMQP 队列。

在持久化和发布时，我注意到在特定时间后，major gc 不会发生，并且在 old gen 被填满后，伊甸园空间也变大，并且持久化和发布消息的速率大大降低。

我的想法是 onMessage 函数需要一个事务，并且在它完成之前它将所有数据保留在内存中或其他东西（索引或持久数据）中，并且不能只清理旧的 gen 以便能够回滚。

我提供一些监控图片。您可以很容易地看到，在两个内存空间（旧 gen 和 eden）都已满并试图清空之后，将消息发布到另一个队列的速度会急剧下降（就像我从作为来自 jms 的请求的列表，我将它们持久化并在 for 循环中将它们发布到 rabbitmq 队列）。如果是这种情况，有什么方法可以使用 infinispan 将索引始终保存在磁盘上？已经在驱逐、小块大小等方面尝试了最小值。效果不佳。还尝试更改 GC 算法，但我最终总是处于相同的情况。也许另一个 infinispan 持久文件存储实现？我现在使用单文件缓存存储，之前使用软索引缓存存储。有什么建议吗？

谢谢

休眠搜索 5.6.1、Infinispan 8.2.4、休眠 OGM 5.1、Wildfly 10

VisualGC from visualVM

VisualVM

RabbitMQ

JMS Threads

Hibernate Search Sync Thread

Answer 1

最新版本的 Infinispan (9.2) 能够“堆外”存储数据，所以简短的回答是可以。但在选择这样做之前请考虑大局，并非所有场景都能从堆外存储中受益，因为这取决于许多因素。

根据定义，Infinispan 旨在缓冲内存中最热的数据，默认情况下“在堆上”，因为当它只是 Java 对象时，这将有助于您的整体性能，因为您可以跳过（反）序列化开销；您需要调整堆大小以适应您计划的负载，它不能自动执行此操作。最简单的策略是在启用非常大的堆大小时使用类似的工具在负载下观察它，然后将其修剪到您知道适合您的负载的合理大小。

因此，在怀疑存在泄漏或无限增长之前，请先尝试验证您的堆是否太小，无法满足其峰值操作要求。如果确实存在实际泄漏，您可能首先要尝试升级，因为这些版本已经很旧了——很多问题已经得到修复。