无法让 Mule 3.4.0 使用超过 4GB 的内存答案

【问题标题】：Cannot get Mule 3.4.0 to utilize more than 4GB of memory无法让 Mule 3.4.0 使用超过 4GB 的内存
【发布时间】：2014-02-27 11:21:54
【问题描述】：

我目前正在处理一个需要大量内存的项目，但我无法让 Mule 3.4.0 使用超过 4gb 的 RAM（在 RHEL 6.2 上运行）。我正在使用 Java HotSpot 64 位服务器 JVM 1.7.0_45-b18 和 Mule 的社区版。

我一直在编辑 wrapper.conf 文件，我尝试了很多设置都无济于事。

我看到 Mule JIRA 中列出了一个错误：https://www.mulesoft.org/jira/browse/MULE-7018 已针对 3.4.0 关闭，但不完整。

我最近的尝试是明确地尝试强制它立即占用 8gb 的堆空间，以下是最新的尝试：

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=8192

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=8192

我尝试将 initmemory 和 maxmemory 参数设置为零，根据这篇关于包装器的旧帖子：http://java-service-wrapper.996253.n3.nabble.com/4096MB-heap-limit-td1483.html - 但是，这会导致 mule 无法正常启动。

我还明确尝试通过包装器传递额外的 JVM 参数：

wrapper.java.additional.6=-Xmx8192
wrapper.java.additional.7=-Xms8192

执行此操作时，我可以看到两个内存设置都被发送到 JVM（即-Xmx8192 -Xms8192 首先在进程行上，然后是-Xms4096m -Xmx4096m）。但是，我的 top 命令产生的 JVM 进程占用的驻留内存不超过 4.2gb。我意识到顶部的 RES 列并不是确定 JVM 内存使用情况的 100% 明确方法，但我的印象是，如果我尝试分配 8gb 开箱即用，它肯定应该超过 4gb。机器有 60gb 物理内存。

有没有人发现为 Mule 3.4.0 获得超过 4GB 堆空间的方法？

【问题讨论】：

您运行的是 32 位 JVM 吗？
好问题，感谢您的提问，是的，我使用的是 64 位 JVM。我已对原始问题进行了进一步说明。

标签： java memory-management mule java-service-wrapper

【解决方案1】：

我相信 Anton 的回答会很好，但是我无法清楚地弄清楚 Java Service Wrapper 的许可证何时更改为 GPL，并且不想冒这种更改对我的用例产生任何负面影响的风险。

我找到了一种使用 Mule 3.4.0 中包含的当前版本的 Java Service Wrapper 来完成这项工作的方法，因此 JSW 对 GPL 的更改不会产生任何额外的许可影响。

如果您修改 wrapper.conf 以将最小和最大内存设置显式设置为 0：

wrapper.java.initmemory=0
wrapper.java.maxmemory=0

然后你可以直接通过附加属性传递内存参数，也在 wrapper.conf 中：

wrapper.java.additional.6=-Xmx8192m
wrapper.java.additional.7=-Xms4096m

随着 initmemory 和 maxmemory 显式设置为零，包装器将不再首先将其自己的内存参数传递给 JVM，从而允许您指定自己的内存参数。请注意，这不适用于 maxPermGen - 由于某种原因，JSW 仍然为此指定自己的值。

【讨论】：

【解决方案2】：

正如 Jira ticket cmets 所说，您可以下载更高版本的 Tanuki 包装器（并替换 lib/boot 下的 Mule 独立包中包含的包装器文件）以克服此限制。所以，download Tanuki 3.3.0，删除 Mule 独立 lib/boot 和子文件夹下所有名称中带有“wrapper”的文件，并将它们替换为 Tanuki 包装器中 lib 和 bin 文件夹中包含的文件。 Tanuki 可执行文件（bin/wrapper）位于 lib/boot/exec 下，.so 和 .jar 文件位于 lib/boot 下。 Mule应该可以正常启动了，可惜我现在没有合适的机器，无法测试4G+设置。

【讨论】：

我认为这会解决它 - 谢谢，这是一个很好的说法 - 我担心 Java Service Wrapper 的许可证在某些时候更改为 GPL，我不认为这意味着适合我的用例。我很难弄清楚许可证是什么时候特别更改的。我将添加一个我必须使用 mule 3.4.0 中现有 JSW 版本的答案。

【解决方案3】：

尝试增加作为 Windows 服务运行的 Mule 实例的 CompressedClassSpaceSize 无济于事。在我最终弄清楚原因之前，该值不会被拾取。

我通过添加这一行在 wrapper.conf 文件中进行了更改 wrapper.java.additional.4=-XX:CompressedClassSpaceSize=2G（顺便说一下默认1G）

但未能检查 wrapper-additional.conf 文件，其中 .4 密钥已被采用，覆盖了我的设置。我移动了我的更改并将键值修改为下一个连续数字，瞧： wrapper.java.additional.6=-XX:CompressedClassSpaceSize=2G

一些好用的命令： c:> 任务列表 | findstr java ...记下 PID... c:> jmap -heap

附言如果你曾经想在命令行（而不是服务）上单独设置这个值，那么它将是 c:> mule -start -M-XX:CompressedClassSpaceSize=2G

编码愉快！

【讨论】：