Re: Increase in 'log file sync' waits while 'log file parallel write' remains unchanged
Date: Tue, 22 Sep 2009 10:23:30 -0700 (PDT)
Message-ID: <089efa37-7da4-4244-8a98-97a795adb685_at_h14g2000pri.googlegroups.com>
On Sep 21, 5:14 pm, John Hurley <johnbhur..._at_sbcglobal.net> wrote:
> On Sep 21, 8:02 pm, John Hurley <johnbhur..._at_sbcglobal.net> wrote:
>
> snip
>
> > Most of my systems are at 128 MB ... why would you have a system with
> > a 1 MB log buffer?
>
> Missed ... looks like my systems are at 10 MB log_buffer not sure why
> 128 jumped into my mind.
>
> The old advice for 1MB is afaik not relevant much anymore. Several
> metalink articles available if you search log_buffer ...
Pehaps you've forgotten that Oracle rounds up log buffer to fill up a granule on 10gR2 and up. Perhaps at some point you set a 65M log_buffer and found it at 128. Perhaps you're running apps and that's what was recommended before 10gR2.
Here's a forum thread that explains some stuff, including that a toobig buffer may cause log syncs: http://forums.oracle.com/forums/thread.jspa?messageID=1940709�
Of course, I don't expect that 1M is too big. I'd guess that something is happening on the OS side periodically that is pounding I/ O (or like you suggested, cpu starvation is preventing I/O from happening, but...). The waits aren't on parallel write perhaps because it's being written to a hardware cache, but the commit ack isn't coming back. Would there be snaps happening on the SAN? Why does this sound so familiar, like an async i/o problem? Which AIX is this? Search metalink for async i/o ibm, see things like Note: 233659.1
jg
-- _at_home.com is bogus. http://www3.signonsandiego.com/stories/2009/sep/22/dell-reaches-deal-buy-perot-systems/?uniontribReceived on Tue Sep 22 2009 - 12:23:30 CDT