You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Arnaud Masson (JIRA)" <ji...@apache.org> on 2009/05/04 11:11:30 UTC
[jira] Created: (DERBY-4210) Use a shared pool for background
threads (rawStoreDaemon)
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.
[jira] Commented: (DERBY-4210) Use a shared pool for background
threads (rawStoreDaemon)
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705621#action_12705621 ]
Kathey Marsden commented on DERBY-4210:
---------------------------------------
This would conflict with my idea for solving DERBY-700 to prevent dual boot from different ClassLoaders by putting the database name in the thread name and checking for existence of the relevant thread before starting up a new one.
I think though that I will go ahead and pursue my idea for DERBY-700 or at least prototype it as it seems to be the only promising option for resolving that critical issue. Then whoever pursues this issue can look into some other way to prevent regression if DERBY-700 has been fixed that way.
> 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.
[jira] Issue Comment Edited: (DERBY-4210) Use a shared pool for
background threads (rawStoreDaemon)
Posted by "Øyvind Harboe (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (DERBY-4210) Use a shared pool for background
threads (rawStoreDaemon)
Posted by "Trejkaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705825#action_12705825 ]
Trejkaz commented on DERBY-4210:
--------------------------------
This is important to us too, as we have a NetworkServerControl where people put a large number of cases which each contain a large number of internal databases.
> 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.
[jira] Commented: (DERBY-4210) Use a shared pool for background
threads (rawStoreDaemon)
Posted by "Øyvind Harboe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787623#action_12787623 ]
Øyvind Harboe commented on DERBY-4210:
--------------------------------------
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.