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 and a whopping 16GB of memory
gets used. You never even more memory to keep the heap around.
It is true that the OS will swap unused memory to disk but swapping
is very slow. It is *much* faster and more efficient to simply use a
caching thread pool. You only pay for active threads.
Gili
On 18/02/2012 12:28 PM, Noel Grandin wrote:
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-creation-overhead
On Sat, Feb 18, 2012 at 16:54, Christoph Läubrich<[email protected]> 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.
What specific problems are you worried about?
Every feature is a potential place for bugs.
This is useful for large computer farms
Exspecially in this case you won't have all threads running on the same
CPU/Host..
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.
