使用Mule3.2在重负载下GC太频繁答案

【问题标题】：GC too frequency under heavy load with Mule3.2使用Mule3.2在重负载下GC太频繁
【发布时间】：2012-05-28 19:41:42
【问题描述】：

在Mule 3.2的重负载下（100个线程并发发送请求），通过jprofiler，我可以看到创建了很多对象实例（大约每秒500mb），并且占据了堆年轻区域90％以上的空间，这导致 jvm 每 2 秒触发一次 gc。

为什么？这正常吗？或者它是一个错误

jvm 参数：

-Xms=2048m -Xmx=2048m -Xmn=768m -XX:PermSize=256m -XX:MaxPermSize=512m -Xss256k -XX:+UseConcMarkSweepGC

谢谢

【问题讨论】：

【解决方案1】：

对于 Mule 收到的每个请求，都会创建大量对象（会话、事件、消息、在许多地方充当闭包的匿名类）。

此外，某些传输可能会创建更多对象，而其他传输则更少，具体取决于它们的技术需求（例如，HTTP 将创建额外的对象来存储标头、cookie...）。

所以这不是一个错误，但我也不能说它是一个功能。而且我认为减少每个请求创建的对象数量对于 Mule 来说是一个很好的举措......

【讨论】：

您能否详细介绍一下为什么 Mule 会创建数百个短寿命对象？
但是每秒 500MB 有点太多了...... mule config 或 java service wrapper 的任何转折点？
每秒发送多少个请求？了解这一点将有助于我们计算出#objects/request 比率。你能展示你的骡子配置吗？使用 jProfiler，您发现创建最多的对象是什么？它们不是 MuleSessions、MuleEvents、MuleMessages 和许多匿名类吗？

【解决方案2】：

您不应该使用 jProfiler 来测量应用程序的分配率。 jPRfiler 会影响应用程序的性能并且会产生巨大的开销。

您应该使用 gc-logging/jmap/jstat 或其他工具来观察和计算应用程序的真实内存统计信息。

然后，您可以在工作负载适中的应用上使用 jProfiler 来分析和研究堆分配。

【讨论】：