I just deduce this from your comment that 'there are many idle threads
floating around' because if the thread is short living you won't see
much threads around (and thats where a Threadpool can help reduce the
thread allocation costs), but if the thread is sitting around (waiting
for I/O, block
On 20/02/2012 11:15 AM, Christoph Läubrich wrote:
> Quoting from the Javadoc of the first link: "Threads that have not
been used for sixty seconds are terminated and removed from the cache.
> Thus, a pool that remains idle for long enough will not consume any
resources."
I think you are getting
Hi,
> Poor cache hit rate
> Why is that? Wouldn't each database maintain its own cache?
Yes, but with some many databases each cache would need to be
extremely small, otherwise it would run out of memory. Or, as an
alternative, the cache sizes would need to be actively managed, which
would compli
> Quoting from the Javadoc of the first link: "Threads that have not
been used for sixty seconds are terminated and removed from the cache.
> Thus, a pool that remains idle for long enough will not consume any
resources."
I think you are getting the doc wrong! 'Idle' here means: 'Threads that
ha
Hello,
>
> > IMHO permanently reducing the number of idle threads can always be
> > beneficial
>
> H2 doesn't use that many threads - just one per database usually. I
> think using a thread pool would cause more problems that it would
> solve, so I'm against going in this direction.
in my case i
Thomas,
I agree with you on the big picture. Please excuse me as I inject
some skepticism :)
* Out of memory problems
o I agree.
* Poor cache hit rate
o Why is that? Wouldn't each database maintain its own cache?
* "Too many open files"
o According to
http://blogs
Hi Ryan,
Your example fails to take into account the cost of swapping
threads in and out of swap space. You're simulating databases running a
query and going to sleep forever, which is not realistic. I'm thinking
of something along the lines of databases running a query every X
seconds wh
On 19/02/2012 2:28 AM, Christoph Läubrich wrote:
Can you refer to a document where it describes:
> A caching thread pool does more than reducing the overhead of
allocating threads.
> It reduces the cost of idle threads to zero (as opposed to keeping
their stack around at a price of up to 16GB
Maybe the OS or something is smarter than it seems... I've had thousands
of open threads and memory stays a lot lower than 1MB / thread. If it
didn't my little laptop would chug!
I just ran a test then...
public static void main(String[] args) {
for (int i = 0; i < 1000; i++) {
Hi,
As I wrote, opening many databases concurrently is problematic anyway:
- out-of-memory problems when using the default cache settings
- bad or cache hit rate / very bad cache efficiency
- "too many open files" problem
Therefore I consider using a thread pool as trying to solve the wrong prob
Can you refer to a document where it describes:
> A caching thread pool does more than reducing the overhead of
allocating threads.
> It reduces the cost of idle threads to zero (as opposed to keeping
their stack around at a price of up to 16GB memory).
From the javadoc I can't see that this
Inlined replies below.
On 18/02/2012 9:54 AM, Christoph Läubrich wrote:
A CachedThreadpool won't change anything here, it is only usefull if
you have many*short living threads* because it reduces the overhead
assosiated with *allocating* a thread.
The Thread count is manly bound by the thr
Not true. Take another look at his charts:
* The default stack size for threads under 64-bit JVMs is 1MB. Source:
http://www.oracle.com/technetwork/java/hotspotfaq-138619.html
* At 64-bit with 512k stack (notice, this is smaller than the default)
he is still limited to 32k threads an
The latest versions of Java support 10s of thousands of threads. When
they are idle the OS swaps out the memory pages and there is very
little overhead.
http://vanillajava.blogspot.com/2011/07/java-what-is-limit-to-number-of-threads.html
http://stackoverflow.com/questions/2117072/java-thread-creat
A CachedThreadpool won't change anything here, it is only usefull if you
have many* short living threads* because it reduces the overhead
assosiated with *allocating* a thread.
The Thread count is manly bound by the threads stack size and the OS and
not by the JVM itself. If the thread is really
Thomas,
My understanding is that idle threads (even if they are one per
database) will eat up valuable memory. The last time I checked Java
would only allow you to launch a few thousand threads (2000 or so). By
introducing a thread pool you're allowing the user to run more databases
but h
Hi,
Opening many databases concurrently is problematic anyway:
- out-of-memory problems when using the default cache settings
- bad or cache hit rate / very bad cache efficiency
- "too many open files" problem
I would consider using a small number of concurrently open databases
(for example 100)
I understand and I´ll give it a shot.
On 15 Feb., 10:30, Noel Grandin wrote:
> You're welcome to modify the code yourself and try out such things, but
> in general we don't like adding complexity unless it makes a measurable
> difference.
>
> Regards, Noel.
>
> On 2012-02-15 10:13, Wolfgang Pedot
You're welcome to modify the code yourself and try out such things, but
in general we don't like adding complexity unless it makes a measurable
difference.
Regards, Noel.
On 2012-02-15 10:13, Wolfgang Pedot wrote:
Thanks for your input.
IMHO permanently reducing the number of idle threads ca
Thanks for your input.
IMHO permanently reducing the number of idle threads can always be
beneficial (less work for OS, less stack-memory), for example
one could get rid of the log-threads by optionally supporting some
kind of log-interface to let the application handle the file-writing.
This way
See here
http://en.wikipedia.org/wiki/Program_optimization#Quotes
Rather do some actual measurements before changing code.
On 2012-02-13 14:05, Wolfgang Pedot wrote:
Hi,
Sorry this isn't answering your question... but I've worked on a project
with thousands of threads and found it to not actu
Hi,
> Sorry this isn't answering your question... but I've worked on a project
> with thousands of threads and found it to not actually really cause any
> issues (Except for hitting the thread limit for a process). Does the
> large number of threads cause issues for you? I guess for large
> scalab
do a search for "new Thread" on the H2 code.
On 2012-02-13 09:54, Wolfgang Pedot wrote:
Hi,
I am using H2 in a scenario where there are lots of small/medium
databases in embedded-mode (multiple instances of the same design).
The code is designed to operate using thread-pools where possible in
o
Hi,
Sorry this isn't answering your question... but I've worked on a project
with thousands of threads and found it to not actually really cause any
issues (Except for hitting the thread limit for a process). Does the
large number of threads cause issues for you? I guess for large
scalability
Hi,
I am using H2 in a scenario where there are lots of small/medium
databases in embedded-mode (multiple instances of the same design).
The code is designed to operate using thread-pools where possible in
order to keep the
thread-count in check but H2 log/lock-threads are making up ~2/3 of
the th
25 matches
Mail list logo
