Any chance of creating a JIRA issue and attaching the sample app to it? Also, what JVM vendor / version, and what do your configuration settings look like?
> 3) "overwriting" embedded objects within a transaction, the previous > embedded object still seems to take up some memory; This is because we don't throw away the embedded record until after we release refs to the owning records. > 2) Though I've set kodo.Log=none there is a hotspot in > LoggingConnectionDecorator? Is this decorator used for something else as > well or is this a bug? I removed it in code from DecoratingDatasource and > this reduced the total memory usage to 500mb That's surprising. -Patrick On Dec 20, 2007 3:55 PM, Christiaan <[EMAIL PROTECTED]> wrote: > > Hi, > > I am doing some analysis for the memory usage since we are running into a > couple of problems in our project when doing import of large quantities of > objects. I've created a simple testcase which does the following: > > 1) Create all objects (2 classes, one class with 5 string attributes, the > other is embedded and has no attributes); > 2) Call makePersistent() on the objects; > 3) Call commit(); > > The results: > - After step 1) takes up 23 mb of memory in the testcase; > - After step 2) the memory usage has increased to 191 mb. Actually > there are > 3 scenarios I used: > 1) Creating objects without the embedded class (which has no attributes, > just an empty class): 75 mb > 2) Creating objects with the embedded class instantiated: 180 mb; > 3) Creating objects with the embedded class instantiated and after > makePersistent() again instantiated (overwriting the previous value): 191 mb > - During step 3) commit() the memory usage peaks at 580mb > > So, > 1) to persist objects which take up 23mb of memory, a total of 580mb so > giving a memory overhead of a factor 25 by the openjpa! > 2) maintaining the datastructure whether objects are persistent increases > the memory with a factor of 4 to 8, depending whether embeddable objects are > used; > 3) "overwriting" embedded objects within a transaction, the previous > embedded object still seems to take up some memory; > > I haven't done a thorough analysis on this but some interesting things I > noticed from the profiler: > 1) One of the hotspots is in storing the RowImpl._sql. If I am not mistaken, > this sql is stored (cached) for each object to be inserted. So in large > transactions where a lot of similar objects and modifications are involved, > this is quite a duplication which leads to unnecessary memory overhead. Of > course there is a performance gain of caching it, but may be this should be > better balanced with memory usage?; > 2) Though I've set kodo.Log=none there is a hotspot in > LoggingConnectionDecorator? Is this decorator used for something else as > well or is this a bug? I removed it in code from DecoratingDatasource and > this reduced the total memory usage to 500mb > > Comments are welcome. > > Kind regards, > Christiaan > > -- > View this message in context: > http://www.nabble.com/Memory-overhead-by-openjpa-tp14438029p14438029.html > Sent from the OpenJPA Developers mailing list archive at Nabble.com. > > -- Patrick Linskey 202 669 5907
