Re: Memory usage Tomcat 3.3 vs 5.5

[Jess Holle]

Hmm...

So model MBeans are not such a pancea after all :-)
They're certainly the most complex and unapproachable form of MBean, 
which Commons Modeler tries to address, of course.  I alway suspected 
that they had an overtly heavy nature at runtime, though -- and it 
appears that there is some truth to this at least in Tomcat's use case.

When I first dove into JMX, I expended an annoying amount of time just 
trying to figure out which type of MBean to use.  I ended up writing my 
own drop-in replacement class for javax.management.StandardMBean and 
immediately subclassing this to add more functionality for my other 
MBeans to inherit.  [The issues that caused me to write a replacement 
have since been addressed in Java 6, but are not all addressed in Java 5 
last I knew.]  This approach gives standard MBean ease of use wherever 
possible with any dynamic or open MBean stuff added "as needed".  [By 
the way, is it just me or do others also find the PersistentMBean 
interface useless?]

I end up caching and thus sharing MBeanInfo for each MBean interface and 
implementation class (since implementation class MBeanInfo is generally 
almost the same as that generated from the MBean interface).  Even where 
the MBeanInfo is more dynamic it is based on *something* else, e.g. 
another target object's class, and is thus cached and shared on that 
basis.  In the end each MBean needs very few additional fields and these 
just point to shared objects.  The costs of not taking this kind of 
approach seems clear below...

--
Jess Holle

Abhi Karmos wrote:
Hi all,

Following up on this thread, we took a dump of the heap running tomcat 5.5. 
There is no good reason for JMX to consume 9-10 Meg.
97,236     5,178,736 array of char

25,494     3,463,312 array of java/util/HashMap$Entry

105,908     3,389,056 java/util/HashMap$Entry

98,510     3,152,320 java/lang/String

98,200     2,356,800 
javax/management/modelmbean/DescriptorSupport$ValueHolder

25,343     1,216,464 java/util/HashMap

348         830,888 array of byte

18,222     728,880 javax/management/modelmbean/ModelMBeanAttributeInfo

21,937     526,488 javax/management/modelmbean/DescriptorSupport

Has anybody looked in the code where the DescriptorSupport class is used? 22 
thousand of these things is simply absurd. Nearly 100 thousand 
DescriptorSupport.ValueHolder objects is even crazier. My guess is that the 
HashMap usage is related to the DescriptorSupport.

Thanks,

Abhi.

OS: Linux 2.4.18 / RedHat 7.3
JVM: IBM 1.4.2 SR3


"Henri Gomez" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
We're also using TC 3.3 on our production systems and are switching to TC 
5.5.

The memory penalty is real but you'll be using up to date and actively
maintained stuff with TC 5.5.

Also you could try to reduce the AJP13 / HTTP 11 threads and remove
some JMX Listeners

2006/4/19, Abhi Karmos <[EMAIL PROTECTED]>:
  
Hello all,

Sorry, could not find an answer on tomcat-users.

We run tomcat inside an embedded system and we are planning to upgrade the
tomcat version from 3.3.1 to 5.5.16. We noticed that the memory footprint 
of
a barebones tomcat 5.5 installation is 44 MB. Plain and simple Tomcat 3.3
used to run with 25 MB. We have limited memory on our system and the 
memory
usage of tomcat 5.5 is a concern for us.

The numbers above are the resident set size (RSS) on a linux system. When 
we
took the above numbers, both the tomcats had the same heap setting (min:
25 - max: 30 mb).

When we run our webapps, which add another 20 jars in the classpath, the
steady state memory usage is 50 MB with Tomcat 3.3 and 66 MB with Tomcat
5.5.

Has anyone else solved a similar problem before ? Can I try and tweak 
tomcat
5.5 to run in less memory ? Our server.xml is the minimal configuration
possible.

Regards,
Abhi.

OS: Linux / RedHat 7.3
JVM: IBM 1.4.2




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


    




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]