Apache Servicemix - 堆空间问题 - 如何解决？

Question

我们在生产中有一个 apache servicemix 实例（版本 3.3.1），它运行我们的 bpel 流（使用 apache ode 1.3.5 ）和一些骆驼代码（用于路由）。问题是，servicemix 进程的已用堆空间不断增加。最终它耗尽空间并崩溃。因此，我们必须每 7-8 天重新启动一次流程。 （这很烦人）

目前进程的jvm内存配置如下
-Xms512M -Xmx2048M -XX:PermSize=512m -XX:MaxPermSize=1024m

我们有另一个 servicemix 实例，它具有相同的内存配置，但运行在稍小的负载下，运行大约 20-22 天，然后才超过分配的堆空间。显然，这个负载较小有助于它延长运行时间。

我的问题

1. 有没有人在使用上述版本的 apache servicemix 时遇到过同样的问题？
   （最初我想确定是容器相关的泄漏还是应用程序相关的问题）

2. 你如何解决这个问题？有没有我可以申请找出问题的方法？如果是这样，任何人都可以列出相同的步骤吗？
   （网络上的内存泄漏解决文章似乎更多地强调导致内存泄漏的理论，而不是应该采取的解决步骤）

需要您对此的想法、建议和意见。

谢谢，
阿伦乔利

Answer 1

通常当我们遇到这个问题时，我们会生成一个堆转储文件，堆转储是Java进程在某个时间点的内存快照。保存这些数据有不同的格式，根据格式的不同，它可能包含不同的信息，但一般来说，快照包含有关触发快照时堆中的 java 对象和类的信息。

生成堆转储文件的方法有很多，但在您的情况下，您可以添加此参数以在发生OutOfMemoryError 时自动生成堆转储文件：

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=[HeapDirPath]

所以这个文件可以让你找出填满整个空间的对象是什么，然后你会很容易地找出导致内存泄漏的代码。

您可以使用Eclipse memory Analyzer来分析此类转储文件。

Answer 2

根据我的经验，ServiceMix 3 的这种类型的内存问题通常表明 MEP 处理流程中的组件或端点之一存在问题。一些 JBI 组件、端点和服务保留一个待处理交换的列表，因此如果其中一些消息交换模式未能正确终止，这些交换将永远不会从列表中删除。

解决此问题的最佳方法是进行堆转储（例如使用 jmap），然后查看其中的 MessageExchange 实现实例。您可能会发现一堆非常相似的 MessageExchange 被保存在内存中。一旦你有了这些，你就可以查看交换属性来找出导致问题的端点/组件。

在后来的 ServiceMix 3.x 版本中还修复了一些可能是导致此问题的问题。请务必试一试 3.4.1 版本或查看更新版本的发行说明。