RAC 环境中 gc block lost 和私网通信性能问题的诊断
************************************************************************ ***** 请阅读原文： blog.csdn.net/clark_xu ***** 欢迎关注微信公众号：clark_blog ************************************************************************ 本文转载自：公共微信号 Oracle疑点通
在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 等待同时出现，如：等待连续的块扫描。
诊断指南1网线/网卡/交换机问题描述：坏掉的网线连接，错误的电缆，制作粗糙的电缆，过于冗长和错误的端口分配，有问题的交换机都会导致低下的传输率，块损坏，数据包丢失和性能问题。
解决：敦促网络供应商对网络进行检查，更换坏掉的网络组件。集群私网应该使用CAT 5 级或者是更好的通信线缆.所有的设备都需要确保安全插牢，并且按照线缆和端口进行标识，线缆的长度需要符合供应商指定的要求。
2UDP设置太小/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个节点）。
3私网性能差，出现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 -s` IP 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文档了解不同平台的对应命令语法。
网络传输坏块（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 <IF> rx off tx off可以关闭该功能。
5通信通道中设置了不匹配的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值会导致节点无法加入集群的问题。
6使用非专用的私网链接 描述:共享的公网和私网配置会导致应用性能低下，网络拥堵，在一些极端的情况下会导致global cache block loss.
解决:数据库/集群私网应该使用独占的VLAN，并定义在non-routed子网中。私网的交换机需要独立于其他的交换机，例如，私网交换机不应该是从接入层的交换机扩展出来,私网的交换机不应该和公网或者NAS的交换机共享。如果使用了VLANs，那么私网应该被划分在单独的VLAN中，并且位于独占的 ，non-routed 子网，独立于公网或者NAS网络。
描述:通常，如果网络上的设备能够通过单跳链接，我们称为“邻接”(adjacency).多跳的配置会增加网络上的延迟，也会增加更多的节点故障风险.
解决:所有的 GbE(千兆以太网)服务器的私网链接都应该邻接在交换机或者交换机组（如果配置了交换机冗余）上。在私网链路中，不应该出现中间网络设备，例如：路由器。在Unix平台上，我们可以通过tracetroute命令来确定“邻接”问题。
描述：配置主机防火墙或网络地址转换（NAT）软件-- IPFILTER (IPF)也是导致私网通信问题的原因之一。IPF还会导致严重的应用程序性能下降，丢包以及global cache block loss问题.
解决:禁用 IPFILTER。
描述:过时的网卡驱动程序或固件，是已知的私网数据包传输问题原因。不兼容的网卡驱动程序会导致节点间通信过程中数据包处理延迟，延迟增加和丢包。
解决：所有节点上的网卡应该采用相同的制造商和型号，相同的性能参数，和对称的插槽(slot) ID。集群中所有节点的私网网卡固件和驱动程序都应该是一致的（最新的）。
描述:非标准的，专享的网络协议，如LLT ，HMP等已经被证明是不稳定的而且很难debug。使用非标准的，专享的网络协议会导致应用的性能下降，丢包和节点重启等故障。
解决:Oracle使用1GbE UDP 作为传输和通信协议，这已经被证明是稳定的，可靠的和高性能的。请避免使用特别的和非标准的通信协议。 在一些平台上，基于Inifiniband 的IP和RDS协议是可用的并且是Oracle支持的，而且10GbE已经被认证(详细信息请参见OTN) - Oracle还在进行这方面的认证工作。
描述:服务器上错误的网卡绑定或链路聚合配置，邻接的私网交换机上错误的聚合配置会导致性能下降，出现由"port flapping"导致的block loss，交换机上构成私网端口的聚合链路发生频繁的"UP"/"DOWN"状态切换。
解决：如果在集群服务器上为私网配置了链路聚合，那么交换机上的端口也应该支持这种配置，并按照聚合配置来配合私网的通信。交换机上构成私网端口的聚合链路配置错误会导致 'port flapping'，交换机端口会被随机删除，导致丢包.对于绑定和聚合，请参考驱动器（driver）文档进行配置，并且在有工作负载的环境下进行测试。 有很多公开的工具和软件可以协助进行带宽和性能延迟的测试（请参考iperf）。我们应该通过评估OS,网络和网络驱动器的统计数据来确定绑定的性能。
描述：错误的Jumbo Frames配置会产生之前提到的不一致的MTU问题
解决：Jumbo Frames 并不是IEEE 标准配置，所以配置的时候应该很小心。单个Jumb Frame的大小是9000 bytes左右。Frame 的大小取决于网络设备供应商，在不同的通信设备上的大小可能是不一致的。如果默认的MTU 尺寸不是9000bytes，请保证通信路径中的所有设备（例如：交换机/网络设备/网卡）都能够支持一个统一的MTU值，在操作的过程中必须把Frame Size（MTU Size）配置成这个值。不合适的MTU设置，例如：交换机上配置MTU=1500,但是服务器上的私网网卡配置成MTU=9000，这样会造成丢包，包的碎片和重组的错误，这些都会导致严重的性能问题和节点异常宕机。大部分的平台上我们都可以通过netstat –s命令的‘IP stats’输出发现包的碎片和重组的错误。大部分的平台上我们可以通过ifconfig –a命令找到frame size的设置。关于交换机上的配置查询，需要查看交换机提供商的文档来确定。
13网卡双工（ Duplex）模式不匹配描述：网卡的双工模式不匹配是指，在同一个交互的链路上，一端使用的是全双工模式，另外一端使用的是半双工模式。这通常是是手动配置错误导致的 或者是一端配置被修改成半双工模式时，另外一端配置成了auto-negotiate引起的。双工模式不匹配会导致严重的私网通信性能问题
解决:集群中所有节点的私网网卡和交换机上的私网线路对应的双工模式都应该配置为auto-negotiate。千兆以太网标准要求auto-negotiate 设置为”on”。双工模式不匹配可能会导致严重的网络性能下降，数据冲突和丢包的情况出现。 每次进行网络硬件和软件升级后都应该检查auto-negotiate设置， Auto-negotiate 在所有的设备上都应该是1000全双工模式。
14私网通信链路流量控制（Flow-control）不匹配 描述：流量控制是指，当一台服务器传输的速度比接收节点（或者是网络设备）的接受速度快 。接收设备会发送“暂停”帧来请求发送端暂时停止发送数据包.
解决：交换机和服务器网卡之间Flow-control设置不匹配的时候会导致丢包和严重的网络性能问题。大部分的情况下，默认的设置"ON"是最好的结果。例如：
tx flow control should be turned on
rx flow control should be turned on
tx/rx flow control should be turned on for the switch(es)
尽管如此，对于一些特殊的案例，例如一些OS或交换机固件的bug，设置成OFF(所有的网络路径)会有更好的结果。
注意：Flow control的设置在固件/网络驱动程序升级后会发生变化，网卡/交换机的设置应该在升级后重新检查。如果没有设备提供商的其它建议值，请使用默认的值。
15OS，网卡，交换机层面的数据包丢弃描述：任何被OS，网卡或者交换机提示的包丢弃信息都应该被彻底的调查和解决。包丢失会导致私网性能降低，CPU使用过高以及节点异常宕机等情况。
解决：具体的工具会帮助我们确定包或帧丢失问题发生在那个层面（process/OS/network/switch）。netstat ,ifconfig,ethtool,kstat(依赖于OS的平台)命令输出和交换机端口状态是首先要进行检查和评估的。您需要一些网络嗅探器（sniffer）跟踪点对点数据通信来排查问题（常见的工具：snoop/wireshare/ethereal）.
注意：从底层来理解丢包的原因是我们找到根本原因不可缺少的步骤。在网络环境中，过小的网卡ring buffers或者receive queues是已知的导致网络上异常丢包的原因，比如：在所有层面都没有提示发生了丢包。请查看下面的网卡驱动问题和Kernel queue长度.这种情况，需要联系系统管理员和网络工程师来确定根本的原因。
16网卡驱动/固件配置问题描述：不合适的配置或者网卡中一些可调属性的不恰当的默认也会导致丢包并增加重传的请求.
解决：大部分网络设备供应商提供的默认出厂配置是可以满足应用要求的。尽管如此，一些网络供应商提供的网卡设备需要修改interrupt coalescence设置和ring buffers描述符数量。interrupt coalescence是CPU发送和接受数据包的中断率。ring buffer在 CPU中断之间持有需要处理的rx 包。不合适的配置会导致在这个层面丢失数据包，诊断这个层面的问题需要系统管理员以及OS/设备提供商的参与。
17网卡发送(tx)和接受（rx）队列的长度描述：设置过小的网卡tx/rx队列长度会导致在队列满的时候出现丢包的情况，这会导致gc block loss，增加重传并且降低私网的效率。
解决：在内核网络子系统（kernel network subsystem）和网络接口设备驱动程序之间移动数据时，发送（TX）和接收（Rx）队列用来实现对数据包的传输和处理进行管理.这些队列的大小是可以配置的。针对产生的网络流量或者配置了MTU的情况，如果这些队列的配置不合适或者过小，队列填满后会导致数据包的丢失或溢出。取决于设备的驱动程序和搜集到的统计信息数量，这类丢包是不容易被发现的，诊断这个层面的问题需要系统管理员和OS/设备的提供商的介入。（通常在linux上我们设置参数：iftxtqueue 和netdev_max_backlog）。
18有限的负载能力和过于饱和的带宽描述：过载的网络使用也会导致私网的性能问题和丢包。
解决：私网配置的最佳实践是您需要知道您的网络使用情况和带宽。这需要通过定期的监控来获取使用的趋势，瞬时值和恒定的值。私网上突然增加的使用请求可能是应用程序调整或异常导致的，如性能很差的SQL语句或者异常产生的数据流量。找到产生带宽饱和的原因并解决它。
19过度的CPU申请和调度延迟描述：持续的高负载和网络堆栈的调度延迟也会对私网的数据包传输产生负面的影响并且会导致私网的性能下降，丢包，gc block loss和节点的重启问题。
解决：持续的高CPU使用率导致的调度延迟也会导致网络上数据包的延迟处理。过度，持续的延迟会导致严重的性能下降，并可能导致群集节点故障。关键是要找到持续的高CPU使用率的原因。使用uptime命令能够列出大部分操作系统的平均负载情况，和网络堆栈处理相关的CPU问题，可以通过NIC interrupt coalescence或者绑定网络到单个CPU得到缓解，请和网络设备的供应商一起来进行此类的优化。调度延迟会导致数据包重组错误。请参见本文的第2点。
20和交换机相关的数据包处理问题描述：交换机的端口缓冲区溢出，交换机拥堵和配置问题，比如MTU大小，网络聚合和VLANS 都能导致低效率的数据包处理和集群节点故障。
解决：Oracle私网需要一个包含交换机的以太网网络。交换机是私网中点对点通信至关重要的组成部分。作为一个网络设备，这个交换机会受到多种因素的影响并导致私网通信性能和高可用性出现异常。监控交换机的异常，数据包处理事件，临时的或持续的吞吐量信息是非常重要的。交换机的状态统计信息，应该定期进行检查并评估是否正常，并找出异常情况。
21QoS对私网数据包处理产生的负面影响描述：在交换机上定义的QoS会共享私网通信的带宽并影响私网处理能力，导致私网性能的下降。
解决：如果私网布置在共享交换机的VLAN上，QoS应该通过优先级配置来避免对私网通信产生负面的影响。任何QoS的定义在布置前都应该进行评估，确保不会影响私网通信。
22重聚过程中生成树限电描述：以太网使用生成树协议(STP)来避免网络环路，确保交换机和冗余的交换机能直接路由到服务器。任何包含在STP拓扑中的设备故障都会导致重新计算路由到主机的重聚。如果STP协议在局域网中被起用，但是配置的有问题或未经优化，网络重聚事件可能需要长达1分钟或者更长的时间（取决于网络的规模和参与设备）。这种延迟会导致私网问题和集群范围的中断。
解决：很多交换机供应商提供优化的扩展，使STP能够实现更快的网络重聚。例如： Rapid Spanning Tree (RSTP), Per-VLAN Spanning Tree (PVST)和Multi-Spanning Tree (MSTP) 可以避免集群大范围的异常出现。
23STREAMS队列的sq_max_size 配置太小 描述：AWR 提示 "gc cr block lost" 和/或"gc current block lost"等待时间很高。 netstat 并没有提示有任何数据包处理的错误. `kstat -p -s '*nocanput*` 返回非0值. nocanput 说明streaming message队列已满，并且包被丢弃。 客户在Solaris平台RAC环境下使用STREAMS。
解决：增加UDP max buffer space，并且把STREAMS队列设置成unlimited能够解决问题，并且消除"nocanput" lost messges。以下是Solaris平台下对应的命令：
`ndd -set /dev/udp udp_max_buf <NUMERIC VALUE>`
set sq_max_size to 0 (unlimited) in /etc/system. Default = 2
udp_max_buf 控制UDP socket发送和接受缓冲区的大小，默认值是262,144 bytes，这个值对于使用STREAMS的应用来说是不够用的。sq_max_size 控制message的队列的长度。
24VIPA和DGD设置不正确（仅限Aix平台）如果您在AIX平台上使用了VIPA（Virtual IP Address），那么Dead Gateway Detection (DGD)必须配置成允许UDP failover模式。
默认的DGD参数可以作为配置起始值，但是在一些客户的环境中，这些参数可能需要调整，但是无论何种情况，都必须设置成大于1的值。默认的设置如下：
dgd_packets_lost = 3
dgd_ping_time = 5
dgd_retry_time = 5
更多配置信息，请参考文章Using VIPA and Dead Gateway Detection on AIX for High Availability Networks, including Oracle RAC： http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102177
当VCS命令lltstat的输出显示"Snd retransmit data"增加时，gc block lost 也会增加。把私网交换机的速度从fixed修改成auto-negotiate，更均匀地分布电缆到每个模块的链接，这样有助于解决"gc blocks lost"的问题。
原因综上，正如上面解释的，块丢失问题通常是由不可靠的私有网络造成的。这可能是由于一个不良补丁或错误的网络配置或硬件问题导致的。
大多数情况下，gc block lost 问题是由于：(a)、缺少OS补丁；(b)、坏掉的网卡；(c)、 有问题的线缆；(d)、有问题的交换机；(e)、网络设置 造成的。