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 behaiviour is specified or
changes anything in the handling of idle threads (where idle mean the
executed task is idle, the doc refers to 'idle' to thread which have
been finished their work an waiting to assign an new task):
http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html#newCachedThreadPool%28%29
http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html
I'm really interested in this since I'm using the Executor interface all
around in my programs since it's very usefull.
> Because CachedThreadPool is unbound, it is equivalent to "new Thread()".
> It never blocks the execution of a Runnable.
See my previous comment, this would not reduce the thread count nor
reduce the memory or anything (as far as I know) since it is especially
designed for short living threads, for long running ones there is no
difference.
Am 18.02.2012 22:51, schrieb cowwoc:
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 threads stack size and the OS
and not by the JVM itself. If the thread is really inactive (aka
blocked on a wait or something) it won't harm the VM much. In cases
of low (system) memory it is also likely that the parts which are
inactive are swapped out.
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). You're right that inactive threads will get swapped out but
swapping is extremely slow. Why go for swapping when you could reduce
the overhead of idle threads to zero by using a thread pool?
> What specific problems are you worried about?
Every feature is a potential place for bugs.
True. But the only thing we're doing is replacing "new
Thread(Runnable)" with "pool.submit(Runnable)". Because
CachedThreadPool is unbound, it is equivalent to "new Thread()". It
never blocks the execution of a Runnable.
> This is useful for large computer farms
Exspecially in this case you won't have all threads running on the
same CPU/Host..
True, but the point is you can run more databases per single
CPU/Host (many more!) with the use of a pool. A single node could
handle 10,000 databases or 100,000. Why invest in 10x more computers?
I will admit that this entire argument is too theoretical for my
liking. I am a strong believe in the use of thread pools but I
wouldn't advocate adding this support without a concrete use-case. For
all we know it's easier from a maintenance point of view to just run
thousands of different VMWare instances as opposed to running
thousands of different DB instances under the same VM. I have no doubt
a thread pool would be more efficient but again who cares if it'll
never get used.
I'll throw the ball back to Wolfgang Pedot: why are you running
multiple DBs under the same VM as opposed to multiple VMs? Isn't it
harder to manage?
Thanks,
Gili
Am 18.02.2012 15:34, schrieb cowwoc:
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 have the same number of databases active. For example,
run 1 million instances but only 2000 are active at any given time.
This is useful for large computer farms (think cloud computing)
where you have literally millions of instances running, but only a
few active at a time.
I think we can have the best of both worlds by allowing users to
specify a non-blocking Thread Pool such as
Executors.newCachedThreadPool(). What specific problems are you
worried about?
Gili
On 18/02/2012 2:26 AM, Thomas Mueller wrote:
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 don't see it as a priority currently to support
tens of thousands of concurrently open databases.
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. But if you want to
implement it and want to provide it for others to use, please go
ahead.
Regards,
Thomas
--
You received this message because you are subscribed to the Google
Groups "H2 Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
--
You received this message because you are subscribed to the Google
Groups "H2 Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
