RE: log buffer size and log file syncs

Unfortunately our change control policies prevent me from running Snapper on 
the problem system.
From: tanel@xxxxxxxxxx [mailto:tanel@xxxxxxxxxx] On Behalf Of Tanel Poder
Sent: Tuesday, May 01, 2012 11:54 AM
To: CRISLER, JON A
Cc: oracle-l
Subject: Re: log buffer size and log file syncs

Hi Jon,

Increasing LGWR priority would only help if it was currently starving for CPU / 
or waiting too long in the CPU runqueue... Unfortunately on Linux there's no 
easy way to measure this directly. If your load is low (let's say only 10 on a 
32 CPU machine) then I'd expect that LGWR priority change isn't going to help 
much.

However, I don't like to fix a problem first and then see whether the problem 
existed in first place (trial and error), that's why I asked for extra 
information / hard evidence in form of LGWR's snapper output ...

Tanel.
On Tue, May 1, 2012 at 6:19 PM, CRISLER, JON A 
<JC1706@xxxxxxx<mailto:JC1706@xxxxxxx>> wrote:
Red Hat Linux 5.  We have async DG running but Real Time apply is also 
configured, and redo logs are mirrored.  I believe LGWR is not starved for CPU 
given the overall conditions for the system, but I am finding some info that 
putting lgwr in a real-time OS priority would be a good thing.

The default for _high_priority_processes is  LMS*|VKTM  but I have seen some 
Metalink notes about adding LGWR.  I also saw a blog post that mentioned you 
discussed setting this parameter at a HOTSOS seminar, and this is something we 
are considering.  Given all the CPU power in this server, and all the LMS 
processes, I don't this would pose a problem.

alter system set "_high_priority_processes"='LMS*|VKTM|LGWR' scope=spfile 
sid='*';


From: tanel@xxxxxxxxxx<mailto:tanel@xxxxxxxxxx> 
[mailto:tanel@xxxxxxxxxx<mailto:tanel@xxxxxxxxxx>] On Behalf Of Tanel Poder
Sent: Monday, April 30, 2012 6:21 PM

To: CRISLER, JON A
Cc: oracle-l
Subject: Re: log buffer size and log file syncs

Which OS are you on? If it happens to be Solaris, then prstat -mLp PID would 
show the scheduling latency for LGWR. This would help to find out whether LGWR 
is CPU starved or not.... what load averages do you have?

Also, what does snapper say when ran on LGWR? If you have synchronous DG for 
example, then LGWR would wait for the LNS ack too in addition to the log file 
parallel write wait, before returning OK back to the committing session ...

Tanel.
On Mon, Apr 30, 2012 at 5:56 PM, CRISLER, JON A 
<JC1706@xxxxxxx<mailto:JC1706@xxxxxxx>> wrote:
Interesting thoughts Tanel: in this case of this specific app, the majority of 
the work is made of up small commits to a handful of tables on a 6 node RAC 
cluster.  I/O times are generally quite good, and with 32 cores per node the 
CPU and load average is very low.  Its 11gR1 - I was wondering if some of the 
tweaks to put LGWR at "real time" priority that are mentioned for 10g also 
apply to 11g.



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

Other related posts: