Home » Modeling » EMF » [CDO] DBStoreAccessor, SmartPreparedStatementCache
| |
| Re: [CDO] DBStoreAccessor, SmartPreparedStatementCache [message #898705 is a reply to message #898647] |
Fri, 27 July 2012 05:22   |
Eclipse User |
|
|
|
Hi,
> Stefan, do you think we should pool the store accessors less
> aggressively? What about a limit on the StoreAccessorPool.accessors
> queue? Or a periodic cleanup?
Currently, we assume a rather constant use of concurrent operations
(which are carried out by StoreAccessors). Therefore, the pool in which
StoreAccessors live is not automatically cleaned up. If you have a usage
pattern, where you have peaks of activity and periods of low activity,
you'd have a pool of inactive StoreAccessors which is not cleaned up.
We couls implement a smarter pooling strategy which has a defined
regular amount of elements. If a peek requires more accessors, these are
created and pooled, but if they are inactive for some time, they could
be removed from the pool and freed up until the regular pool level is
reached again.
@Per: If this sounds good, please file a bugzilla for this request.
Cheers,
Stefan
Am 27.07.12 06:18, schrieb Eike Stepper:
> Am 26.07.2012 20:26, schrieb Per Sterner:
>> Hello,
>>
>> I am still searching for our problems :)
> What exactly are those? Are there any OutOfMemoryErrors being thrown?
>
>> On my server I have after some days 3637 instances from the class
>> 'org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor' and some of
>> these contain/reference alot of data. The mat - MemoryAnalyzer tells
>> me that these instances contain/reference 350MB of data.
>> There are only 2 CDOSessions open to the CDOServer, one client is in
>> the same VM and the other client is operating remote. The CDOClient on
>> the server is doing alot transactions and queries, but all in one thread.
>>
>> These classes have same instance count (in the CDOServer VM):
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$ConnectionKeepAliveTask
>>
>> org.eclipse.emf.cdo.server.internal.db.SmartPreparedStatementCache
>> (The instances are connected to 'java.util.TimerTask')
> What do you mean by "connected"? Do you have a screenshot from MAT?
>
> Stefan, do you think we should pool the store accessors less
> aggressively? What about a limit on the StoreAccessorPool.accessors
> queue? Or a periodic cleanup?
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
|
|
|
| Re: [CDO] DBStoreAccessor, SmartPreparedStatementCache [message #898744 is a reply to message #898705] |
Fri, 27 July 2012 08:34 |
| Eclipse User |
|
|
|
Hi,
>> I am still searching for our problems 
>What exactly are those? Are there any OutOfMemoryErrors being thrown?
Actually the cpu load goes up (~100%, Garbage collector) and therefore (?) a lot TimeoutException occur on transactions.
(I think 'OutOfMemoryErrors' would come later)
INFO | jvm 1 | 2012/07/27 08:03:50 | Caused by: org.eclipse.net4j.signal.RemoteException: org.eclipse.net4j.util.om.monitor.MonitorCanceledException: org.eclipse.net4j.util.concurrent.TimeoutRuntimeException: Timeout after 10001 millis
INFO | jvm 1 | 2012/07/27 08:03:50 | at org.eclipse.net4j.signal.RequestWithConfirmation.getRemoteException(RequestWithConfirmation.java:141)
INFO | jvm 1 | 2012/07/27 08:03:50 | at org.eclipse.net4j.signal.RequestWithConfirmation.setRemoteException(RequestWithConfirmation.java:130)
INFO | jvm 1 | 2012/07/27 08:03:50 | at org.eclipse.net4j.signal.SignalProtocol.handleRemoteException(SignalProtocol.java:467)
INFO | jvm 1 | 2012/07/27 08:03:50 | at org.eclipse.net4j.signal.RemoteExceptionIndication.indicating(RemoteExceptionIndication.java:66)
INFO | jvm 1 | 2012/07/27 08:03:50 | at org.eclipse.net4j.signal.Indication.doExtendedInput(Indication.java:57)
INFO | jvm 1 | 2012/07/27 08:03:50 | at
>> (The instances are connected to 'java.util.TimerTask')
>What do you mean by "connected"? Do you have a screenshot from MAT?
I have attached 3 screenshots.
>Currently, we assume a rather constant use of concurrent operations
>(which are carried out by StoreAccessors). Therefore, the pool in which
>StoreAccessors live is not automatically cleaned up. If you have a usage
>pattern, where you have peaks of activity and periods of low activity,
>you'd have a pool of inactive StoreAccessors which is not cleaned up.
>
We are syncing some data every 10 seconds (yes polling :-/). But only if new data arrives, this is commited in CDO (But there are always some changes).
>We couls implement a smarter pooling strategy which has a defined
>regular amount of elements. If a peek requires more accessors, these are
>created and pooled, but if they are inactive for some time, they could
>be removed from the pool and freed up until the regular pool level is
>reached again.
>
I think a smarter cleanup of the pool would solve our problem (screenshots)?
>@Per: If this sounds good, please file a bugzilla for this request.
Yes, this sounds good, on my way 
Regards,
Per
Thanks for this project'
Attachment: mat_001.png
(Size: 129.93KB, Downloaded 168 times)-
Attachment: mat_002.png
(Size: 148.14KB, Downloaded 167 times) -
Attachment: mat_003.png
(Size: 146.38KB, Downloaded 149 times)
|
|
| | | | | | | | | |
Goto Forum:
Current Time: Tue Jul 22 11:47:18 EDT 2025
Powered by FUDForum. Page generated in 0.06954 seconds |
Home