Database Reference
In-Depth Information
Typically, the LMS process runs in a real-time CPU scheduling priority; therefore, CPU scheduling delays will be
minimal. The excessive number of waits for this event would indicate that there was a sudden spike in global cache
requests and that the LMS process was not able to process the requests quickly enough. Memory starvation in the
server also can lead to paging of the LMS process, affecting global cache performance.
You can review to see why LMS process is not able to process requests efficiently.
Placeholder Wait Events
After sending a message to LMS process to access a block, an FG process must wait for a response back from LMS
process. RAC code is instrumented such that the FG process will wait on a placeholder event such as gc cr request
or gc current request . The response from LMS process will indicate the type of delay encountered while processing
the block. After receiving the response, the FG will account the time correctly to an actual wait event.
Generally, these placeholder wait events have no significance, since actual wait time is recorded to another wait
event. If there is no response after a 0.5-s wait (6 s in Windows platform), the FG process will declare that the block
has been lost, accounts time to gc lost block 7 wait event, and then resends the message. These placeholder events
are visible only in the v$session/v$session_wait family of views and indicate the real-time session waits. As 500 ms is a
long time compared to 2-3 ms, you would probe to identify why the reply is not received in 500 ms.
In a healthy database, the amount of time accounted toward these two placeholder wait events will be negligible.
If you see many processes waiting for these placeholder wait events, then review other events such as gcs log flush
sync or background waits to identify the performance delay.
Sending-Side Analysis 8
Many analysts focus on the performance metrics of the receiving side exclusively while troubleshooting a global
cache performance issue. RAC wait events suffered by the FG processes are instrumenting the performance of the
receiving side .
It is equally important to understand the performance metrics of the sending side too. You need to understand
that slowdown in the sending side can lead to longer wait times for FG processes in other nodes. Focus on sending
side is more important if the histogram of wait events indicates latencies in higher-order buckets.
Fortunately, Oracle Database is instrumented with extensive statistics to perform a breakdown analysis on the
sending side too. Before you can understand the metrics, you should understand the internal mechanics involved in a
global cache block transfer. Figure 10-3 provides a rough overview of global cache processing. In this Figure, only two
instances are shown to improve readability. The FG process connected to instance 1 tries to access a block, constructs
a GC message, and sends the message to the LMS process running in instance 2. Assume that the block is resident in
the buffer cache of instance 2 and that block is also mastered by instance 2.
7 Event gc lost block is discussed extensively in Chapter 9. I think it is repetitive to probe this event further in this chapter.
8 Sending side refers to the instance and LMS processes sending the block. Receiving side refers to the FG process requesting
the blocks.
 
Search WWH ::




Custom Search