合 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 利用率原因.
注意:
增加以下设置的同时也会增加内存的使用
LINUX:
我们可以通过以下设置来修改reassemble buffer大小
/proc/sys/net/ipv4/ipfrag_low_thresh (default = 196608)
/proc/sys/net/ipv4/ipfrag_high_thresh (default = 262144)我们可以通过以下设置来修改reassemble的时间:
/proc/sys/net/ipv4/ipfrag_time (default = 30)请参考OS文档了解不同平台的对应命令语法。
以上不适用于RHEL 6.6， RHEL 6.6版本请参考RHEL 6.6: after manually lowered ipfrag_high_thresh IPC Send timeout/node eviction etc with high packet reassembles failure (Doc ID 2008933.1)
网络传输坏块（corruption）导致的UDP checksum errors 和/或 send (tx) / receive (rx) transmission errors
描述: UDP包传输的过程中，接受进程会读取数据包头的校验值。任何校验值损坏都会使这个包被丢弃，并导致重发，这会增加CPU的使用率并且延缓数据包处理。
解决: 使用 tcpdump，snoop等网络工具来捕获数据包的dump,定位这些checksum错误并确认checksum corruption。敦促OS或者网络管理员查找产生corruption的原因。 已知的问题是由于网卡上开启了Checksum offloading 导致了checksum 错误，如果出现这样的问题请检查checksum offloading的功能是否被禁用，测试后考虑关闭网卡上的该项功能。在Linux系统上执行ethtool -K rx off tx off可以关闭该功能.
在通信通道中设置了不匹配的MTU的值
描述: 不匹配的MTU大小设置会导致传输过程中出现 "packet too big" 错误并丢失数据包，导致global cache block丢失和大量的重传（retransmission）申请。.
解决: MTU 是"Maximum Transmission Unit" 或者是私网通信过程中帧的尺寸.对于以太网（Ethernet），大多数UNIX平台的默认值是1500字节。私网链路中所有设备都应该定义相同的MTU。请确认并监控私网链路中的所有的设备。为ping ,tracepath,traceroute命令指定大的，非默认尺寸，ICMP probe 包来检查MTU设置是否存在不一致。使用ifconfig或者厂商推荐的工具为服务器网卡（NIC）的MTU设置合适的值。关于JUMBO Frames的设置，请见第12点的介绍。
注意：私网中不一致的MTU值会导致节点无法加入集群的问题。
使用非专用的私网链接
描述: 共享的公网和私网配置会导致应用性能低下，网络拥堵，在一些极端的情况下会导致global cache block loss.
解决:数据库/集群私网应该使用独占的VLAN，并定义在non-routed子网中。私网的交换机需要独立于其他的交换机，例如，私网交换机不应该是从接入层的交换机扩展出来,私网的交换机不应该和公网或者NAS的交换机共享。如果使用了VLANs，那么私网应该被划分在单独的VLAN中，并且位于独占的 ，non-routed 子网，独立于公网或者NAS网络。服务器/交换机缺少“邻接”（adjacency）配置
描述:
通常，如果网络上的设备能够通过单跳链接，我们称为“邻接”(adjacency).多跳的配置会增加网络上的延迟，也会增加更多的节点故障风险.
解决:
所有的 GbE(千兆以太网)服务器的私网链接都应该邻接在交换机或者交换机组（如果配置了交换机冗余）上。在私网链路中，不应该出现中间网络设备，例如：路由器。在Unix平台上，我们可以通过tracetroute命令来确定“邻接”问题。
配置了 IPFILTER
描述:配置主机防火墙或网络地址转换（NAT）软件-- IPFILTER (IPF)也是导致私网通信问题的原因之一。IPF还会导致严重的应用程序性能下降，丢包以及global cache block loss问题.
解决: 禁用 IPFILTER过时的网卡驱动程序(Network driver)或者是网卡固件（firmware）
描述: 过时的网卡驱动程序或固件，是已知的私网数据包传输问题原因。不兼容的网卡驱动程序会导致节点间通信过程中数据包处理延迟，延迟增加和丢包。
解决： 所有节点上的网卡应该采用相同的制造商和型号，相同的性能参数，和对称的插槽(slot) ID。集群中所有节点的私网网卡固件和驱动程序都应该是一致的（最新的）。特别的私网链接和网络协议
描述:
非标准的，专享的网络协议，如LLT ，HMP等已经被证明是不稳定的而且很难debug。使用非标准的，专享的网络协议会导致应用的性能下降，丢包和节点重启等故障。
解决:
Oracle使用1GbE UDP 作为传输和通信协议，这已经被证明是稳定的，可靠的和高性能的。请避免使用特别的和非标准的通信协议。 在一些平台上，基于Inifiniband 的IP和RDS协议是可用的并且是Oracle支持的，而且10GbE已经被认证(详细信息请参见OTN) - Oracle还在进行这方面的认证工作。
错误配置的网卡绑定/链路聚合
本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务，私聊QQ646634621或微信dbaup66，谢谢！
