- LGWR has to be scheduled and begin executing its code path,
- ...which of course includes the flush of the buffer.
- 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.
--
http://www.freelists.org/webpage/oracle-l
Received on Wed Feb 21 2007 - 15:29:32 CST
