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

Figured it was time to send the list an update. 1. Our sysadm said that there are kernel issues and "perf stat" cannot run on these systems
2. I installed a slob instance on both a fast and slow server. There was no way to stop our workload from running, but I ran slob multiple times, trying to keep each run short (~3 minutes) so the underlying workload would not vary much. Also tried running when the load was relatively low. All of the run results were pretty consistent with one another. Configuring SLOB to run strictly LIO, I saw ~4M lio/sec vs. 1.5M lio/sec 3. Our sysadm did get turbostat installed. What I take as the most important output from that was:

slow: TSC_MHz - 2600     Bzy_MHz - 1200   PKG_% - 100%
fast:  TSC_MHz - 2606     Bzy_MHz - 3110    PKG_% - 0%

So the clock speeds are nearly identical, ,but the running speeds when busy are very different. Also RAPL throttling is on in the slow server. I am guessing this could account for the throttled cpu speed. I am starting to google search to see where this can be set from. Anyone out there know any  good resources on RAPL throttling or how to disable it?

Thanks.

Henry

On Fri, Aug 11, 2017 at 2:52 PM, Henry Poras <henry.poras_at_gmail.com> wrote:

> Stefan,
>
> I agree about focusing on cpu (and perhaps memory). As for perf, from what
> I have seen it should be available. I'll check path, but I thought it might
> be a module not installed. I was able to start "perf stat" (didn't get a
> command not found) but then got some lib error. I'll go back and check.
>
> Henry
>
> On Fri, Aug 11, 2017 at 1:42 PM, Stefan Koehler <contact_at_soocs.de> wrote:
>
>> Hello Henry,
>> not quite sure what you are referring to as you are using Linux kernel
>> 2.6.32-696.1.1.el6.x86_64 and perf is based on the perf_events interface
>> and it is exported by Linux kernel >= 2.6.31 - maybe it is just not in your
>> path ("/usr/sbin/perf").
>>
>> In addition i may got your description wrong but you wrote "A select
>> count(*) from dba_objects showed this behavior as did Jonathan Lewis's
>> kill_cpu script." - so you can completely ignore the I/O or network stack
>> and focus on CPU (and memory) as kill_cpu (https://jonathanlewis.wordpre
>> ss.com/2016/10/03/kill-cpu/) has nothing to do with these stacks.
>>
>> ... and if you want to analyze the CPU (and memory caching) behavior -
>> measure it with perf and you will see the difference.
>>
>> Best Regards
>> Stefan Koehler
>>
>> Independent Oracle performance consultant and researcher
>> Website: http://www.soocs.de
>> Twitter: _at_OracleSK
>>
>> > Henry Poras <henry.poras_at_gmail.com> hat am 11. August 2017 um 19:27
>> geschrieben:
>> >
>> > Some more minor updates and responses to suggestions:
>> >
>> > Stefan - nice articles. Unfortunately neither turbostat or perf stat is
>> available. I've asked the sysadms about this.
>>
>
>

--
http://www.freelists.org/webpage/oracle-l