合 RAC 环境中 gc block lost 和私网通信性能问题的诊断 (文档 ID 1674865.1)
Tags： Oracle
文档内容
| 症状 | |
|---|---|
| 概要： | |
|---|---|
| 场景: | |
|---|---|
| 原因: | |
|---|---|
| Global Cache Block Loss诊断指南 | |
|---|---|
| 更改 | |
|---|---|
| 原因 | |
|---|---|
| 解决方案 | |
|---|---|
| 参考 | |
|---|---|
适用于:
Oracle Database - Enterprise Edition - 版本 9.2.0.1 和更高版本
本文档所含信息适用于所有平台
Oracle Clusterware & Oracle Real Application Clusters
症状
概要：
在Oracle的RAC环境中，数据库会收集global cache 的工作负载统计信息，并把这些信息通过STATSPACK, AWRs 和 GRID CONTROL等工具呈报。对于每个节点，以及集群汇总统计信息中的global cache数据块丢失的统计信息("gc cr block lost" 和/或 "gc current block lost") 代表了私网通信的包处理效率低或者包的处理存在异常。这些信息是需要定期进行监控和评估来保证私网之间的global cache和 Enqueue服务（gcs/ges）以及集群之间的正常通信。任何块丢失的信息都说明私网在对数据包的处理过程中是存在异常情况并且需要进行调查。
数据库绝大部分的 “global cache lost blocks”的问题都可以直接联系到私网的故障和错误的配置。本文可以作为调查和评估常见原因（有时是非常明显）的指南。
尽管我们讨论的大部分都是性能问题，但是这些问题也有可能会导致节点或实例的驱逐。Oracle集群和RAC实例依赖于心跳来维持节点关系。如果网络心跳持续无法连通，那么实例/节点驱逐就会发生 。因此，以下的这些症状也和节点/实例驱逐相关。
场景:
主要:
- "gc cr block lost" / "gc current block lost" 出现在AWR的top 5等待事件中或者产生了非常多的等待。
其次:
- SQL traces 文件中多次出现 gc cr requests / gc current request
- 出现 gc cr multiblock requests 等待，每次等待时间都很长而且elapsed times 都一样。
- 应用的性能和吞吐量都很差
- 通过ifconfig或者其它第三方的工具能够看到网络上发送和接受包的错误
- 使用netstat命令会看到一些error/retransmits/reassembly failures
- 节点故障和节点通信错误
- 大量的CPU消耗在网络进程上
注意: 块丢失的问题通常会和gc cr multiblock requests 等待同时出现，如：等待连续的块扫描
原因:
- 可能的原因已经在下面的诊断指南中列出（按照出现概率排序）
Global Cache Block Loss诊断指南
网线/网卡/交换机问题
描述: 坏掉的网线连接，错误的电缆，制作粗糙的电缆，过于冗长和错误的端口分配，有问题的交换机都会导致低下的传输率，块损坏，数据包丢失和性能问题。
解决: 敦促网络供应商对网络进行检查，更换坏掉的网络组件。集群私网应该使用CAT 5 级或者是更好的通信线缆.所有的设备都需要确保安全插牢，并且按照线缆和端口进行标识，线缆的长度需要符合供应商指定的要求。
UDP receive(rx) buffer sizes设置过小/UDP buffer socket溢出
描述:
Oracle RAC Global cache块的处理是突发性的，因此，操作系统需要缓冲区来接受接收（RX）数据包并等待CPU的处理,如果缓冲区设置的不合理或者过小会导致块丢失和global cache 块丢失。通过'netstat -s' 或者 'netstat -su'命令可以帮助我们在unix平台上获取到UDPInoverflows，package receive errors, dropped framces 或packets dropped due to buffer full errors信息。
解决:
数据包丢失往往是由于在接收服务器上设置的UDP缓冲区不足，从而导致了块在缓冲区中溢出而产生块丢失。当OS的缓冲区设置小于128k的时候，Oracle 在打开一个socket 时会设置 UDP receive buffer 尺寸为 128k。如果OS的缓冲区设置大于128k，Oracle会采用OS 的设置。如果数据库的块尺寸大于8k，那么缓冲区会自动的进行调整，但是不会超过OS的限制。当DB参数DB_FILE_MULTIBLOCK_READ_COUNT的值大于4时，如果发现 UDP buffer overflows, packet loss 和 lost blocks，并且数据库出现了大量的"global cache cr requests"等待超时，这是由于缓冲区设置过小导致的，我们可以通过调大OS的UDP缓冲区的或者调低数据库参数DB_FILE_MULTIBLOCK_READ_COUNT来解决问题 ，这个参数可以在系统或session级别调整。
对于大部分的unix平台，我们可以通过以下的一些命令来判断是否出现UDP缓冲区溢出或者block loss，执行：
'netstat -s' 或 'netstat -su'，并根据具体平台查看 "udpInOverflowsudpInOverflows", "packet receive errors", "fragments dropped" 或 "outgoing packet drop" 信息
注意：UDP丢包通常会引起更多的延迟，网络带宽减少，更高的CPU使用率(kernel 和user)，以及消耗更多的内存来处理这些包的重传。
在系统运行时，如果工作节点（运行负载的节点）对应的远程节点上命令netstat –s的输出中 "outgoing packets dropped"值显著的增加，同时增加wmem_default 和 wmem_max到4M（Linux平台）可以解决问题。
UDP发送和接收缓冲区参数是和操作系统有关的，它们可以滚动（rolling）修改（例如：每次1个节点）。
私网性能差并且CPU使用率高，
netstat -s出现packet reassembly failures。描述: 根据MTU（Maximum Transmission Unit）的尺寸，大的UDP数据包可能被分片，并在多个帧中发送。这些零散的数据包需要在接收节点上重新组合。高CPU使用率（持续的或者是频繁的峰值），过小的reassembly buffer或者UDP buffer也会导致块重组失败。在接收节点’netstat -s’输出的 "IP Statistics"部分提示有大量的Internet Protocol (IP)上的"reassembles failed" 和 "fragments dropped after timeout"信息。分片的报文需要在指定时间（time-to-live）内完成重组（reassemble）。没有能够完成重组的分片报文会被丢弃并要求重传。已经收到，但是由于空间不足没有进行重组的数据分片会被直接丢弃。
netstat -sIP stat counters:
3104582 fragments dropped after timeout
34550600 reassemblies required
8961342 packets reassembled ok
3104582 packet reassembles failed.解决:
增加reassemble buffer尺寸，给重组分配更多的空间。增加reassemble的时间，增加UDP receive buffer以避免由于网络延迟导致的reassemble失败，并找到对网络数据包处理产生负面影响的高CPU 利用率原因.
注意:
增加以下设置的同时也会增加内存的使用
本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务，私聊QQ646634621或微信db_bao，谢谢！
