[concurrency-interest] Thread Allocation
nathan.reynolds at oracle.com
Wed Feb 13 09:50:46 EST 2013
I have heard that building your system to deal with asynchronous I/O
will perform much better. With synchronous I/O, the thread blocks and
waits. This incurs 2 context switches as well as ties up a thread and
all of its resources. With asynchronous I/O, the thread submits the I/O
request and continues to do other processing. When the I/O completes, a
thread picks up the result and continues processing. Asynchronous I/O
allows 1 thread to submit enough I/O requests that the underlying
storage system can optimize how the requests are stored. For example, a
bunch of random writes using synchronous I/O will cause the disk head to
seek wildly since each write has to go to a different location. A bunch
of random writes using asynchronous I/O will give the underlying system
a chance to sort the writes and have the disk head make a single pass
over the disk. Disk performance will greatly improve.
Architect | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 2/13/2013 2:34 AM, Chris Vest wrote:
> 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
> <mailto: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
>> <mailto:Concurrency-interest at cs.oswego.edu>
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest