[
https://issues.apache.org/jira/browse/DERBY-4210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787623#action_12787623
]
Øyvind Harboe edited comment on DERBY-4210 at 12/8/09 6:24 PM:
---------------------------------------------------------------
We switched to Derby 10.5 from 10.1(?) and we're now seing memory consumption
going through the roof. Memory problems with Java are not easy to diagnose
correctly, that in mind, here is some information:
- We have ~100 embedded databases in a single java process. 1 database per
customer. We would have liked to use a single database for a customers, but at
that point we would probably be looking at PostgreSQL I think.
- There are lots of said threads in our system(one per database?).
- From Eclipse heap analysis some fingerpointing is done to derby:
142 instances of "org.apache.derby.impl.services.cache.ConcurrentCache", loaded
by "sun.misc.Launcher$AppClassLoader @ 0x736e14d8" occupy 86,289,208 (53.63%)
bytes.
Keywords
sun.misc.Launcher$AppClassLoader @ 0x736e14d8
org.apache.derby.impl.services.cache.ConcurrentCache
(I'm learning about these profiling tools. If I figure out more I'll update
this bug report.)
was (Author: oharboe):
We switched to Derby 10.5 from 10.1(?) and we're now seing memory
consumption going through the roof. Memory problems with Java are not easy to
diagnose correctly, that in mind, here is some information:
- We have ~100 embedded databases in a single java process. 1 database per
client. We would have liked to use a single database for a single client, but
at that point we would probably be looking at PostgreSQL I think.
- There are lots of said
- From Eclipse heap analysis some fingerpointing is done to derby:
142 instances of "org.apache.derby.impl.services.cache.ConcurrentCache", loaded
by "sun.misc.Launcher$AppClassLoader @ 0x736e14d8" occupy 86,289,208 (53.63%)
bytes.
Keywords
sun.misc.Launcher$AppClassLoader @ 0x736e14d8
org.apache.derby.impl.services.cache.ConcurrentCache
(I'm learning about these profiling tools. If I figure out more I'll update
this bug report.)
> Use a shared pool for background threads (rawStoreDaemon)
> ---------------------------------------------------------
>
> Key: DERBY-4210
> URL: https://issues.apache.org/jira/browse/DERBY-4210
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Affects Versions: 10.5.1.1
> Reporter: Arnaud Masson
>
> Use a shared pool for background threads (rawStoreDaemon).
> May it could be a configuration option (pooling or not, max pool size, core
> pool size, ...).
> I have an application that opens several small derby databases (using
> EmbeddedDriver).
> Most of these instances don't handle many requests, but each instance
> maintains its own thread "derby.rawStoreDaemon".
> It would more efficient to use a thread pool shared by all the instances.
> See http://osdir.com/ml/apache.db.derby.devel/2005-04/msg00093.html
> See also DERBY-206 and DERBY-696 about threading in Derby.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
