RE: CPU Wait troubleshoot

From: Stefan Koehler <contact_at_soocs.de>
Date: Mon, 18 Apr 2016 17:46:22 +0200 (CEST)
Message-ID: <85677051.700001.1460994382145.JavaMail.open-xchange_at_app02.ox.hosteurope.de>



Hello Christopher,

> My understanding of the RWP recommendation is that max session should be between 1 and 10 times the number of cores, depending on the percentage
> time spent on IO versus CPU for your app.

Almost correct. It is not just about I/O versus CPU as there are many many other non-CPU (waiting) states as well. Max session of 1 time the number of cores would mean an absolute perfect world as the application would have no waiting state at all, which is not very "real world". In addition you also have to consider multi-threading up to a specific point. Max session of a small multiple up to 10 times the number of cores would be the range.

> On the rare occasions when we get in early and have time for full testing, I like to have each app server with a connection pool set very low, and
> then test for performance versus requirement, and then only go up the way if we don't meet the requirements.

You can only go up, if the "very low" connection pool is not already exhausting the hardware (CPU) capacity. SwingBench (with high frequency OE) is a nice reproducible example of the RWP guideline. Max session of 10 times the number of cores is using round about 70 to 80 percent of the CPU capacity in my recent benchmarks.

Best Regards
Stefan Koehler

Freelance Oracle performance consultant and researcher Homepage: http://www.soocs.de
Twitter: _at_OracleSK

> "Osborne, Chris" <Chris.Osborne_at_sky.uk> hat am 18. April 2016 um 16:29 geschrieben:
>
> My understanding of the RWP recommendation is that max session should be between 1 and 10 times the number of cores, depending on the percentage
> time spent on IO versus CPU for your app.
>
> On a 32 Core system, 320 sessions max, if they are IO intensive. However, if each session is roughly 50/50 on IO versus CPU, you'll probably want a
> smaller number than 320. As always, testing is your friend.
>
> On the rare occasions when we get in early and have time for full testing, I like to have each app server with a connection pool set very low, and
> then test for performance versus requirement, and then only go up the way if we don't meet the requirements.
>
> Christopher Osborne

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Apr 18 2016 - 17:46:22 CEST

Original text of this message