Waits, Enqueues, and Latches - Expert Oracle RAC Performance Diagnostics and Tuning - page 596

In the RAC architecture, to get a block, the GCS may usually have to perform two hops if the block requested
cannot be found on the local instance: two hops because if the master is located on the instance where the demand
for the blocks concerning a specific object is the highest, and hence most likely, the block is going to be present
where the master is located. When the demand for the blocks concerning the object increases on another instance,
the master will dynamically move/relocate to this new instance. Only when blocks are not found on the master does
the GCS need to direct the transfer from another instance or from disk (three hops). Irrespective of the number of
instances in the cluster, the GCS process will have to make a maximum of three hops. That is the reason why the RAC's
architecture provides maximum scalability irrespective of the number of instances in the cluster. Now, when the
three-way wait values are significantly high, it could be an indication that the block was never found on the master or
the master did not relocate to another instance where the demand is high.
High wait times for these events would be an indication of poor network transfer speed and bandwidth. Very high
wait numbers would indicate further investigation should be made into the configuration of the private interconnect
configuration and the socket send and receive buffer sizes. Apart from the configuration as discussed in Chapter 13,
the run queue length and CPU utilization of the servers should be looked at. From the application level, hot spots of
the database should be looked into, and the SQL should be tuned to minimize full scans and high block movement
across the interconnect by reducing LIO.
gc cr/current block congested
This wait indicates that the request was made to the DLM but ends up waiting, and the foreground processes have to
retry the request. Under these circumstances, the “ gc cr/current block congested ” wait counter is incremented.
Normally this indicates that the GCS process ( LMSn background) is not able to keep up with the requests. LMSn
is a single threaded synchronous process and follows the FIFO algorithm to complete block requests. This means
that when multiple requests are received, the GES will place the requests in a queue and send the request to the LMSn
process when it has completed a previous operation. In such situations, considerations should be given to increase
the number of LMSn processes using the parameter GCS_SERVER_PROCESSES . Performance implications of setting a
high value for this parameter are discussed in Chapter 13.
LMSn processing delays due to frequent interrupts by other high priority processes and LMS being overloaded,
making it unable to keep up with requests, could be indications for high wait times. Almost always this is the result of
scheduling delays and high queue lengths experienced by the node at the O/S level.
RAC has several other types of wait events. For a better understanding, in Figure 17-5 the global cache related
wait events have been grouped by the resource area they impact.