Re: LIO/sec per CPU limit? Is it Hardware or Oracle code?

From: Lothar Flatz <>
Date: Thu, 10 Aug 2017 17:51:08 +0200
Message-ID: <>

I have encountered two cases that showed a very similar behavior. In both cases one of the OS Processes consumed most of the CPU. Just my 2 cent.;-)

Am 10.08.2017 um 15:59 schrieb Hans Forbrich:
> In my lab, subtle things like NIC firmware and RAM stick specs on
> "identical" workstations (Dell T5500s) cause significant performance
> differences. I'd want to note those kinds of differences, to
> eliminate them during root cause analysis.
> /Hans
> Disclaimer: My opinion, and mine alone. Not an opinion from my employer.
> On 2017-08-09 3:46 PM, Henry Poras wrote:
>> I have two identical servers (or so I am told), but application work
>> is running 2-3 times slower on one than the other. Using Tanel's
>> snapper, I see that all active sessions are all on CPU. Viewing top
>> shows me the same thing, each session pegs a cpu. We also found that
>> it wasn't particular SQL that slowed down across severs, but it
>> looked like everything was slow. A select count(*) from dba_objects
>> showed this behavior as did Jonathan Lewis's kill_cpu script. This
>> gave me something to test with. Running a 10046, I saw the same
>> amount of resource utilization (parse count, fetch count, cr count,
>> ...), no contention (wait events), but one server finished 2.5 times
>> faster than the other. Looking at session stats through snapper, I
>> see that the number of session logical reads per sec (~all of which
>> are consistent reads) is ~ 2.5 times higher on one server than the
>> other. That explains why it takes one longer to finish.
>> So, now what?? Why is one server giving me 350k consistent gets/per
>> second and the other is ~800k? Is it hardware? /proc/cpuinfo shows
>> the same cpu for each box. Is it hidden in the Oracle code path? I
>> realize that not all LIO are created equal, but how do I check this?
>> I am running on SE12.1.0.1
>> Any and all thoughts welcome.
>> Henry
> --


Received on Thu Aug 10 2017 - 17:51:08 CEST

Original text of this message