Re: log writer tuning

Kevin Closson wrote:
A. LGWR has to be scheduled and begin executing its code path,
B. ...which of course includes the flush of the buffer.
C. Then the committing process has to be scheduled and returned to its
code path, where it can issue an OS timer call to see how long the <log
file sync> event took.

...I'll elaborate further. When Cary says that "LGWR has to be
scheduled", that presumes he is asleep. That is bad, yes because it adds
his runable time to the whole equation (can be 10,20,30 or more
milliseconds). Worse than that case is if he is already busy with
servicing I/O and posting the previous set of waiters. There are very
few Oracle ports where LGWR can post multiple waiters with one systems
call (certainly not Larry's Linux). Remember, every time a process comes
out of kernel mode, the opportunity arises to schedule a higher priority
process. I've seen (by timing inside the LGWR work loop code) cases
where posting 30 processes (a group commit of 30) take an entire SECOND.
Why? Because the system was really busy. Each post (IPC semaphore
operation) added, on average, 20ms so there went 600ms for some poor
shadow process in LFS. Then there was I/O and other taxation.
We implemented a post/wait driver that allowed LGWR to post all waiters
in a single call and to set their user mode priority if it made sense as
well. That was back in the day where there was port-optimization...its
mostly dwindling down the "reference port" stuff  now...sadly.

That would be the scenario which is our experience, however I am not aware if 10gR2 on Solaris10 is able to post multiple waiters. Number of transactions is quite large so as I said earlier I suppose LGWR is still busy with

"posting the previous set of waiters" as You said. However I suppose also, that if it 
would be so, we would not experience jumps of "log file sync" waits while switching 
between logs, but rather almost continuous increase of their value


Remigiusz Sokolowski <rems@xxxxxxxx>
WP/PTI/DIP/ZAB (+04858) 52 15 770
MySQL  v.  4.x
Oracle v. 10.x


Other related posts: