问题
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:
-Xms=2048m -Xmx=2048m -Xmn=768m -XX:PermSize=256m -XX:MaxPermSize=512m -Xss256k -XX:+UseConcMarkSweepGC
thanks
回答1:
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...
回答2:
You should not be using jProfiler to measure Allocation rate of your application. jPRofiler influences the performance of your application and has a huge overhead.
You should be using gc-logging/jmap/jstat or other tools instead to observer and compute the true memory statistics of your application.
Then, you can use jProfiler on your app with a moderate workload to profile and study the heap allocation.
来源：https://stackoverflow.com/questions/10699940/gc-too-frequency-under-heavy-load-with-mule3-2