db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øyvind Harboe (JIRA) <j...@apache.org>
Subject [jira] Issue Comment Edited: (DERBY-4210) Use a shared pool for background threads (rawStoreDaemon)
Date Tue, 08 Dec 2009 18:25:18 GMT

    [ 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.


Mime
View raw message