5:30 a.m.
http://community.jboss.org/blogs/smarlow includes details on our memory
after booting current AS trunk (default profile).
Scott
7:27 a.m.
> Earlier in the AS 6 development (May of 2009), we were consuming
120.4MB after starting the AS (default profile). Since then, we have
gotten it down to 77.1MB
That's a really good improvement. From what I remember, AS5 was using a
way lot more than this.
-Jaikiran
On Friday 08 October 2010 09:00 AM, Scott Marlow wrote:
http://community.jboss.org/blogs/smarlow includes details on our
memory
after booting current AS trunk (default profile).
Scott
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
3:20 p.m.
By the way, as noted in that report, the JMX objects are still holding a
lot of memory. I just quickly checked the jmx-console against AS trunk
and I see a lot of MBeans (mostly for debug level data) related to
classloader under the jboss.classloader domain:
id="vfs:///jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/server/default/deploy/hornetq/hornetq-configuration.xml"
id="vfs:///jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/server/default/deploy/hornetq/hornetq-jboss-beans.xml"
id="vfs:///jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/server/default/deploy/hornetq/hornetq-jms.xml"
... and more.
I checked some config files to see if this can be disabled through
configuration, but couldn't find it. Is there some config which can
disable registering these classloader MBeans? We could then check how
much memory usage improvement this brings in.
-Jaikiran
On Friday 08 October 2010 10:57 AM, Jaikiran Pai wrote:
>> Earlier in the AS 6 development (May of 2009), we were
consuming
120.4MB after starting the AS (default profile). Since then, we have
gotten it down to 77.1MB
That's a really good improvement. From what I remember, AS5 was using a
way lot more than this.
-Jaikiran
On Friday 08 October 2010 09:00 AM, Scott Marlow wrote:
> http://community.jboss.org/blogs/smarlow includes details on our memory
> after booting current AS trunk (default profile).
>
> Scott
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
3:24 p.m.
I checked some config files to see if this can be disabled through
configuration, but couldn't find it. Is there some config which can
disable registering these classloader MBeans?
You need to find who sets MBeanServer to org.jboss.classloader.spi.ClassLoaderSystem.
As this is what then triggers all the CL MBean registration.
6:56 p.m.
On Oct 8, 2010, at 8:20 AM, Jaikiran Pai wrote:
By the way, as noted in that report, the JMX objects are still
holding a
lot of memory. I just quickly checked the jmx-console against AS trunk
and I see a lot of MBeans (mostly for debug level data) related to
classloader under the jboss.classloader domain:
id="vfs:///jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/server/default/deploy/hornetq/hornetq-configuration.xml"
id="vfs:///jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/server/default/deploy/hornetq/hornetq-jboss-beans.xml"
id="vfs:///jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/server/default/deploy/hornetq/hornetq-jms.xml"
... and more.
Those are created by the deployers on the Hornetq-integration integration. Those are
basically done by the dependency injection through those deployers. I'm not sure what
we could do about those here.
4953
days inactive
4955
days old
jboss-development@lists.jboss.org
4 comments
4 participants
participants (4)
-
Ales Justin -
Clebert Suconic -
Jaikiran Pai -
Scott Marlow