| [CDO] OutOfMemoryError when committing frequently [message #503776] |
Tue, 15 December 2009 12:20  |
 Walter Hargassner
Messages: 5
Registered: November 2009 |
Junior Member |
|
|
Hi,
I'm using CDO 2.0 and have a CDO client and server running within one
process. As we have limited resources, we need to have a look at the
memory consumption. Currently I'm ending up in an OutOfMemoryError.
We have the following use case:
1. Create a hierarchically structured model (about 2.000 CDOObjects)
2. Storing the model in one resource on the server
3. Getting the single root element
4. Set a new value for each element
5. Commit the transaction
6. Continue with step 4.
For the server setup I've used the server config file and set the
currentLRUCapacity and the revisedLRUCapacity to 1, supportingAudits is
set to false. On the client side I created a new LRUCache and set it in
the CDOSessionConfiguration.
After step 3 we need about 30 MB of heap size. After a few minutes we
run out of memory (64 MB).
First experience I've made is, that somehow the revisedLRUCapacity and
currentLRUCapacity from the config file are ignored. The created cache
uses 1000 and 1000 as default values. I've set the cache size manually,
both to 1, but it does not really change anything.
By using the profiler I found out, that I have a lot of
LinkedList$Entry, KeyedSoftReference, CDOIDAndVersionImpl objects,
nearly the same number of HashMap$Entry objects and a lot of
CDORevisionImpl and CDOListImpl objects.
Any hints for me where else I should have a look?
BR
Walter
|
|
|
| Re: [CDO] OutOfMemoryError when committing frequently [message #503868 is a reply to message #503776] |
Wed, 16 December 2009 07:56  |
|
Hi Walter,
Comments below...
Walter Hargassner schrieb:
> Hi,
>
> I'm using CDO 2.0 and have a CDO client and server running within one
> process. As we have limited resources, we need to have a look at the
> memory consumption.
Are you using JVMAcceptor and JVMConnector instead of TCP connections?
> Currently I'm ending up in an OutOfMemoryError.
>
> We have the following use case:
>
> 1. Create a hierarchically structured model (about 2.000 CDOObjects)
> 2. Storing the model in one resource on the server
> 3. Getting the single root element
> 4. Set a new value for each element
> 5. Commit the transaction
> 6. Continue with step 4.
>
> For the server setup I've used the server config file and set the
> currentLRUCapacity and the revisedLRUCapacity to 1, supportingAudits
> is set to false. On the client side I created a new LRUCache and set
> it in the CDOSessionConfiguration.
If reloading revisions is fast (client and server are in the same VM)
you could even consider to set a NOOPRevisionCache (self-made). Or you
just set a MEMRevisionCache
>
> After step 3 we need about 30 MB of heap size. After a few minutes we
> run out of memory (64 MB).
How big are your 2000 revisions in total?
>
> First experience I've made is, that somehow the revisedLRUCapacity and
> currentLRUCapacity from the config file are ignored. The created cache
> uses 1000 and 1000 as default values. I've set the cache size
> manually, both to 1, but it does not really change anything.
That sounds like https://bugs.eclipse.org/bugs/show_bug.cgi?id=292375 .
We want to publish new builds ASAP.
>
> By using the profiler I found out, that I have a lot of
> LinkedList$Entry, KeyedSoftReference, CDOIDAndVersionImpl objects,
> nearly the same number of HashMap$Entry objects and a lot of
> CDORevisionImpl and CDOListImpl objects.
"A lot" is not very specific :P How do the numbers relate to your use cases?
>
> Any hints for me where else I should have a look?
Hard to say. First ensure that the cache sizes are really what you
expect them to be. Then try to find out whether the system consumes more
memory than expected. There's a chance that you just need more memory.
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.02990 seconds
] 
Search
Help
Register
Login
Home
