Memory overhead by openjpa
--------------------------
Key: OPENJPA-474
URL: https://issues.apache.org/jira/browse/OPENJPA-474
Project: OpenJPA
Issue Type: Bug
Environment: Windows XP, Kodo 4.1.4, Sun JDK 1.6.2, ms sql server
2005, JTDS driver
Reporter: Christiaan
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.
