[concurrency-interest] Thread Allocation
mr.chrisvest at gmail.com
Wed Feb 13 04:34:42 EST 2013
If you can tell before hand which tasks (that you submit to the thread pools) are going to be IO bound and which are going to be CPU bound, then you can have to separate thread pools: a big one for the IO bound tasks and a small one for he CPU bound ones.
Otherwise I'd say just set a high upper bound (upwards hundreds, but depends on expected distribution) and let the OS manage things, see how that works and if its performant enough, then you're done.
Note that I have no idea what kind of performance is expected of your SIEM system.
On 13/02/2013, at 09.48, "Pete Haidinyak" <javamann at cox.net> wrote:
> I have a question on how to allocate Threads. I am creating a SIEM which is a bunch of independent Java Services. The most likely use case is this will run on one 2U box. The box will have two quad core Xeon processors and 32G of RAM. Some of the Services will be I/O bound but some will be CPU bound.
> In one of the latest discussion it was mentions that you should allocate a Thread for each core (plus or minus a couple) for the best throughput. I have the ability to turn the Thread Pools after startup based on the number and types of Services running on the box.
> My question is what would be the best way to allocate Threads when you have multiple processes competing for resources?
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest