Re: Oracle 12.1.0.2, RHEL 7 and XFS issue
Date: Wed, 30 Dec 2015 18:09:18 +0100
Message-ID: <573e5570e65443be97e9c29e925b37d9.webmail_at_mx1bln1.prossl.de>
This in in response to a conversation far, far away... But I felt the urge to close this thread with a final response and thanks, so here you go.
On Mon, 3 Aug 2015, Jared Still wrote:
> On Fri, Jul 31, 2015 at 8:13 AM, Martin Bach
<development_at_xxxxxxxxxxxxxxxxx>
> wrote:
>
> > I think this is a key points - "stick it on a VM". You didn't mention
> > which one, and what type of virtualisation (PVM, HVM, HVM with PV
drivers,
> > ...). It might be that you get contention on I/O outside the VM so
> > depending on your product you should have a look at the overall host
> > settings. In addition to contention on hardware you might see QoS
turned on
> > throttling you down.
>
>
> Agreed.
>
> You may want to try a 10046 trace on one of the jobs and look for
> unaccounted for time.
>
> This technique has worked previously for showing that resources were being
> prioritized away from the VM in question.
Thank you Stefan Koehler, Martin Bach and Jared Still for your suggestions! As I can recall from memory, the RDBMS VM is on Vmware ESX 5.5. I cannot recall which storage subsystem is used in case you might ask.
As it turned out, the customer was not in the mood to give me enough
budget to dig deep enough to find the root cause of the slower access to
XFS in combination with direct I/O. They were already comtempt with the
workaround to set "filesystemio_options=ASYNCH" (and wasting RAM and CPU
cycles on double buffering).
But at least I had a 10046 trace that showed quite an amount of
"unnacounted-for" time, which it doesn't when direct I/O is switched off.
Next time this topic pops up at that site, I have at least a hint in a
certain direction. Did I mention BTW that OraSRP is a fantastic 10046
parser? ;-)
Cheers,
Uwe
--- http://oraculix.com/ -- http://www.freelists.org/webpage/oracle-lReceived on Wed Dec 30 2015 - 18:09:18 CET