GC在Mule3.2的重负载下频率太高

问题描述

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

为什么？这是否正常？或者它是

中的一个错误jvm参数：

lockquote

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

谢谢

解决方案

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

此外，根据技术需要，某些传输可能会创建更多的其他传输较少的对象（例如，HTTP将创建额外的对象来存储标题，Cookie ...） 。

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

Under heavy load with Mule 3.2(100 threads send requests concurrently), through jprofiler, I could see that lots of object instances are created(about 500mb every second), and occupied over 90% space of the young area of the heap, which caused the jvm to trigger gc every 2 seconds.

why? Does this normal? Or is it a bug in

jvm arguments:

thanks

解决方案

For every request that Mule receives, numerous objects are created (session, event, message, anonymous classes that act as closures in many places).

Moreover, some transports may create more objects other transports less, depending on their technical needs (for example HTTP will create extra objects for storing headers, cookies...).

So this is not a bug but I can't say it's a feature either. And I think that reducing the amount of objects created per request would be an excellent initiative for Mule...

这篇关于GC在Mule3.2的重负载下频率太高的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！