openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim McConnell (JIRA)" <>
Subject [jira] Assigned: (OPENJPA-474) Memory overhead by openjpa
Date Sun, 17 May 2009 03:11:45 GMT


Tim McConnell reassigned OPENJPA-474:

    Assignee: Tim McConnell

> Memory overhead by openjpa
> --------------------------
>                 Key: OPENJPA-474
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>         Environment: Windows XP, Kodo 4.1.4, Sun JDK 1.6.2, ms sql server 2005, JTDS
>            Reporter: Christiaan
>            Assignee: Tim McConnell
>         Attachments:
> 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 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message