2 Replies Latest reply on Dec 15, 2003 1:42 PM by mike andrews

    memory usage when creating an EJBLocalObject

    mike andrews Newbie

      hi folks,

      i have an application where i'm creating a couple hundred thousand CMR entity beans in a single transaction, and it seems memory usage is surprisingly high, even though the entity beans' field types are quite small --- things like int's, short String's, float's, etc.

      so, i imagine there must be a minimum 'memory overhead' in jboss for creating EJBLocalObjects, and i'm wondering if someone could comment on that.

      i measure the approximate memory cost of creating each EJBLocalObject by logging

      before and afterwards. although this is not guaranteed to be precise, due to garbage collection and other issues, from the distribution of values it looks like about 13 kilobytes per object. the distribution seems to be accurate to a few hundred bytes, but of course sometimes the value goes quite 'negative' after garbage collection.


        • 1. Re: memory usage when creating an EJBLocalObject
          Franco Apprentice

          What about your EJB cache size ?
          Are you using P6SPY ?

          • 2. Re: memory usage when creating an EJBLocalObject
            mike andrews Newbie

            i'm not using p6spy, but certainly could do so to see what's going on in the database. but i think the problem may be in the cache, as you may also suspect.

            i've been playing around a bit with the cache size, and now its at 300000 entity beans per entity bean type. previously, when my cache size was smaller, say 50000, i would get tons of streaming warning log messages from org.jboss.ejb.plugins.AbstractInstanceCache saying "unable to passivate due to ctx lock". despite the warnings, the transactions seemed to succeed, however. is this due to some problem with jboss, where it somehow has trouble recycling entity beans involved in the current transaction? it seems awful to emit all those warning log messages.

            prior to setting the cache at all, the jboss default was some tremendous number which caused my java virtual machine to throw an OutOfMemory error after just a few transactions within several minutes (since each one creates a couple hundred thousand entities).

            by the way, i'm running jboss 3.2.2 (binary distribution) on linux redhat 9 with 1.5 gigabytes maximum heap size, dual processor, and LD_ASSUME_KERNEL=2.4.1 to avoid the posix threading issue that tends to hang the virtual machine after running jboss for a while. i'm using mysql 3.23.54 with innodb tables.