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.
