Tuning the Cluster Interconnect - Expert Oracle RAC Performance Diagnostics and Tuning - page 461

polled: 3056035547
uphappy: 2164405573
updropped: 0
tx dropped: 0
csummed: 2164406731
no rcv: 2164406784
rx bytes: 1305880876649
tx bytes: 1621856900611

Step 4
If there are no errors at the NIC level, how about errors during communication? This can be determined using
the netstat -su command at the O/S level. The following output shows errors while receiving packets; however,
compared to the total packets received, the errors are minimal and not much of a concern:

Udp:
2417572082 packets received
352524 packets to unknown port received.
41277 packet receive errors
2439175462 packets sent

Step 5
From Steps 2 to 4, we have not found any significant reason for what could be slowing down the network traffic and
causing high latency. RAC uses the private network for most of the data transfers between instances. Only when the
block is not present in one of the instances in the cluster will a disk I/O be performed. A good rule of thumb to follow
is to ensure that network latency of the private interconnect is much lower compared to the disk I/O latency. If this is
not the case, it probably defeats the purpose of using a RAC configuration.

■ one primary advantage of the clustered solution is to save on physical i/o against a storage system, which is
expensive. This means that the latency of retrieving data across the interconnect should be significantly lower compared
to getting the data from disk. For the overall performance of the cluster, 95% for immediate block transfers should be
between 200 and 700 microseconds, depending on block size, protocol, and hardware when the system load is moderate.
The average latency of a consistent block request is the average latency of a consistent-read request round trip from the
requesting instance to the holding instance and back to the requesting instance.

Note

When are such high latencies experienced over the interconnect? Another good test is to perform a test at the O/S
level by checking the actual ping time. This will help to determine if there are any issues at the O/S level. After all, the
performance issue may not be from data transfers within the RAC environment.
As discussed earlier in this chapter, the interconnect is used by the clusterware and the GCS for sending
messages of various kinds. These messages include request for blocks, request for locks, heartbeats, and so forth. Such
messages should also be taken into account when looking at the reasons for slow performance.
When sending and receiving messages between the nodes in the cluster, the GCS and the clusterware use a
method called ticketing.