> > Can you disclose what monitoring tool you use and explain how it > impacted the measured value?
> > Interesting. What monitoring tool are you using? The monitoring tool used is Introscope from CA. You need to pay attention to the "Deep Inheritance" parameter. And, did it make a difference? Yes, if the permgen is undersized, there is a significant impact on the CPU consomption. With "parallel GC" do you mean the default stop the world collector? Indeed. Did you also try G1 GC? I'd be curios to learn how well that did with > your workload and especially how well it manages to keep GC times > within given limit via -XX:MaxGCPauseMillis. My application is running under JRE 1.6, i don't know if this mode is available with this version. The Garbage-First (G1) garbage collector is fully supported in Oracle JDK 7 > update 4 and later releases. However i think that my application has not the required profile for this GC mode : Recommended Use Cases for G1 > The first focus of G1 is to provide a solution for users running > applications that require large heaps with limited GC latency. This means > heap sizes of around 6GB or larger, and stable and predictable pause time > below 0.5 seconds. I'm interested in what that tool was doing... and why it didn't seem > to have the same effect under Websphere... The agent version used is different in Tomcat and Websphere, but the configuration is the same, especially the "Deep inhéritance" parameter. Sylvain. On Mon, May 5, 2014 at 5:02 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Sylvain, > > On 5/5/14, 9:22 AM, Sylvain Goulmy wrote: > > Thank you for your contribution to this thread. I think we we have > > made good progress on the subject, here are some elements i'd like > > to share : > > > > - The fact that the response time was increasing with the the > > number of JSP loaded was linked to our monitoring tool... This tool > > hadn't the same impact with websphere. Without monitoring the > > response time remains stable no matter how many jsp are already > > loaded in the permgen. > > Interesting. What monitoring tool are you using? > > > - There is no permgen defined in the IBM JVM running Websphere and > > i was wondering how much space the JVM was allocating to host this > > huge number of JSP. The memory footprint of the process on the > > system was quite big : Xmx : 1,5 Go, memory footprint of the JVM : > > 3,5 Go. It lets me think that Websphere allocates a large space to > > host these JSP, i increase accordingly the permgen size of my JVM > > to 1Go. > > If you aren't specifically setting the JVM's heap and perm gen sizes, > then you are getting the defaults. If you are using Websphere, then > Websphere is likely setting those defaults for you, rather than just > getting the JVMs defaults. I can't remember if IBM JVM even has a perm > gen space like HotSpot-based (Sun/Oracle) JVMs. > > > - I finally noticed that when the permgen is undersized (ie it > > cannot host all the JSP of my application and has to unload class), > > the CPU impact is much more important with the CMS garbage policy > > than with the parallel GC. > > Remember that you can configure your JVM to have different GC policies > for each heap space (e.g. permgen versus rest). > > > Our main concern so far was the CPU comsumption, we finally solved > > this by tuning our monitoring tool correctly and by increasing the > > size of the permgen. > > I'm interested in what that tool was doing... and why it didn't seem > to have the same effect under Websphere... > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJTZ6f8AAoJEBzwKT+lPKRYbxMP/R8+UJCkzEzYSZuwkT77PaIC > KgUsh98UJylm2eUdmWqMAhBW0HiHgVz+tuhKPUVUnyOKaUCM2CvFx43sV8jjDfpF > MiZP+ZdJFtbZ4/fW8zJ9Eg4v4bVJFfqDhIyfTU+wPGcRX/A88FQteyityYHdZqt7 > nqHtGDCi2UMD2CC2TucL815ITRcu1Jyrwse3SJjv5k5d0kLJXP3R4JZgtPRwYBit > ptdUq9QDuQLV3AhYak5gax9WvupVsMJrJSjHa8aw0HUR7fqJlCKYe+6IJlTAmyv1 > x8Q5Ju3dCIigoaYcXfn0y+bpb0/DF4z9RoFiTA7p0mjViNkvYSL+RH7SYDJPbfDz > Pe5QJPLdx+BxYPrq9XBAuTtgCRV2oefB5CnEMBUgm2tXqihMBmECS1ERYvo77vsh > UUFkMUDannvsB6do4jQkIWr/i0RlSf40gHlDpnsTgmRO7kJM5fg9svBEMi2a3+Jo > 4F7Ajjv7b8DYn4Dynh65P8VtwzFv3DKj14Mb5wUhXRkJFY0LpT4hUg999UGxEUq9 > cBQ+txfg3A72Rbn/ShkVefZGLWrsp0zqYzFGqhBlpV2HDYiJb2PpYcMX8B6gl4ez > nUBwt6qMHDsx6+jH6ug2EGrFcTbVAM5aidN+CZquivE9Bts20rsgupWmFZWMPeaB > wNsNG70ARwUcyeryJBC/ > =QUZb > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
