在生产中设置-XX：+ DisableExplicitGC：会出现什么问题？ [英] Setting -XX:+DisableExplicitGC in production: what could go wrong?

问题描述

我们刚刚举行了一次会议来解决用于计算保险费率的Web应用程序中的一些性能问题。计算是在C / C ++模块中实现的，该模块也用于其他软件包。为了使它成为web服务，实现了一个Java包装，它公开了一个基于XML的接口，并通过JNI调用C / C ++模块。

测量结果显示，几秒钟花费在Java部分的每个计算中。所以我第一次推荐是在VM中启用垃圾收集日志记录。我们可以立即看到许多停止世界的完整GC。谈到这一点，Java部分的开发人员告诉我们他们曾多次做过一个 System.gc（），以确保内存在使用后释放。 b
$ b

好吧，我不会详细说明这个声明......; - ）

然后我们添加上面提到的 -XX：+ DisableExplicitGC 也是VMs参数并重新测试。由于我们无法通过剥离所有这些 System.gc（）
< >调用，在我们的发布过程中，我们正在考虑在生产中添加 -XX：+ DisableExplicitGC ，直到可以创建新的Jar。

现在的问题是：这样做有没有风险？关于我能想到的唯一的事情是在重新部署时内部使用 System.gc（）的tomcat，但这只是一个猜测。是否还有其他危险？

解决方案

通过设置 -XX：+ DisableExplicitGC 标志。不幸的是（尽管有文档中的免责声明），许多开发人员决定他们比JVM更了解何时收集内存并准确介绍这类问题。

I注意到 -XX：+ DisableExplicitGC 改善了生产环境的许多实例，以及零实例存在任何负面影响。

安全的做法是在负载下运行当前的生产代码，并在压力测试环境中设置该标志并执行正常的QA循环。

如果你不能这样做，我会建议设置标志的风险低于大多数情况下不设置它的成本。

we just had a meeting to address some performance issues in a web application that is used to calculate insurance rates. The calculations are implemented in a C/C++-module, that is used in other software packages as well. To make it available as a webservice, a Java wrapper was implemented that exposes an XML based interface and calls the C/C++-module via JNI.

Measurements showed that several seconds were spent on each calculation inside the Java part. So my first recomodation was to enable garbage collection logging in the VM. We could see at once that many stop-the-world full GCs were made. Talking about that, the developper of the java part told us they did a System.gc() on several occasions "to make sure the memory is released after use".

OK, I won't elaborate on that statement any further... ;-)

We then added abovementioned -XX:+DisableExplicitGC too the VMs arguments and reran the tests. This gained about 5 seconds per calculation.

Since we cannot change the code by stripping all those System.gc() calls at this point in our release process, we are thinking about adding -XX:+DisableExplicitGC in production until a new Jar can be created.

Now the question is: could there be any risk in doing so? About the only thing I can think of is tomcat using System.gc() internally when redeploying, but that's just a guess. Are there any other hazards ahead?

解决方案

You are not alone in fixing stop-the-world GC events by setting the -XX:+DisableExplicitGC flag. Unfortunately (and in spite of the disclaimers in the documentation), many developers decide they know better than the JVM when to collect memory and introduce exactly this type of issue.

I'm aware of many instances where the -XX:+DisableExplicitGC improved the production environment and zero instances where there were any negative side effects.

The safe thing to do is to run your current production code, under load, with that flag set in a stress test environment and perform a normal QA cycle.

If you cannot do that, I would suggest that the risk of setting the flag is less than the cost of not setting it in most cases.

这篇关于在生产中设置-XX：+ DisableExplicitGC：会出现什么问题？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！