RAC 环境中 gc block lost 和私网通信性能问题的诊断 (文档 ID 1674865.1)

0    140    1

Tags:

👉 本文共约10741个字,系统预计阅读时间或需41分钟。

文档内容

症状
概要:
场景:
原因:
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诊断指南

    1. 网线/网卡/交换机问题

      描述: 坏掉的网线连接,错误的电缆,制作粗糙的电缆,过于冗长和错误的端口分配,有问题的交换机都会导致低下的传输率,块损坏,数据包丢失和性能问题。

      解决: 敦促网络供应商对网络进行检查,更换坏掉的网络组件。集群私网应该使用CAT 5 级或者是更好的通信线缆.所有的设备都需要确保安全插牢,并且按照线缆和端口进行标识,线缆的长度需要符合供应商指定的要求。

    2. 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个节点)。

    3. 私网性能差并且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 -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文档了解不同平台的对应命令语法。

      以上不适用于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)

    4. 网络传输坏块(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可以关闭该功能.

    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网络。

    7. 服务器/交换机缺少“邻接”(adjacency)配置

      描述:

      通常,如果网络上的设备能够通过单跳链接,我们称为“邻接”(adjacency).多跳的配置会增加网络上的延迟,也会增加更多的节点故障风险.

      解决:

      所有的 GbE(千兆以太网)服务器的私网链接都应该邻接在交换机或者交换机组(如果配置了交换机冗余)上。在私网链路中,不应该出现中间网络设备,例如:路由器。在Unix平台上,我们可以通过tracetroute命令来确定“邻接”问题。

    8. 配置了 IPFILTER

      描述:配置主机防火墙或网络地址转换(NAT)软件-- IPFILTER (IPF)也是导致私网通信问题的原因之一。IPF还会导致严重的应用程序性能下降,丢包以及global cache block loss问题.
      解决: 禁用 IPFILTER

    9. 过时的网卡驱动程序(Network driver)或者是网卡固件(firmware)

      描述: 过时的网卡驱动程序或固件,是已知的私网数据包传输问题原因。不兼容的网卡驱动程序会导致节点间通信过程中数据包处理延迟,延迟增加和丢包。
      解决: 所有节点上的网卡应该采用相同的制造商和型号,相同的性能参数,和对称的插槽(slot) ID。集群中所有节点的私网网卡固件和驱动程序都应该是一致的(最新的)。

    10. 特别的私网链接和网络协议

      描述:

      非标准的,专享的网络协议,如LLT ,HMP等已经被证明是不稳定的而且很难debug。使用非标准的,专享的网络协议会导致应用的性能下降,丢包和节点重启等故障。

      解决:

      Oracle使用1GbE UDP 作为传输和通信协议,这已经被证明是稳定的,可靠的和高性能的。请避免使用特别的和非标准的通信协议。 在一些平台上,基于Inifiniband 的IP和RDS协议是可用的并且是Oracle支持的,而且10GbE已经被认证(详细信息请参见OTN) - Oracle还在进行这方面的认证工作。

    11. 错误配置的网卡绑定/链路聚合

      描述:

      服务器上错误的网卡绑定或链路聚合配置,邻接的私网交换机上错误的聚合配置会导致性能下降,出现由"port flapping"导致的block loss,交换机上构成私网端口的聚合链路发生频繁的"UP"/"DOWN"状态切换。

      解决:

      如果在集群服务器上为私网配置了链路聚合,那么交换机上的端口也应该支持这种配置,并按照聚合配置来配合私网的通信。交换机上构成私网端口的聚合链路配置错误会导致 'port flapping',交换机端口会被随机删除,导致丢包.对于绑定和聚合,请参考驱动器(driver)文档进行配置,并且在有工作负载的环境下进行测试。 有很多公开的工具和软件可以协助进行带宽和性能延迟的测试(请参考iperf)。我们应该通过评估OS,网络和网络驱动器的统计数据来确定绑定的性能.

    12. 错误的巨帧(Jumbo Frame)配置

      描述: 错误的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)

      本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务,私聊QQ646634621或微信db_bao,谢谢!
      RAC 环境中 gc block lost 和私网通信性能问题的诊断 (文档 ID 1674865.1)后续精彩内容已被小麦苗无情隐藏,请输入验证码解锁本站所有文章
      验证码:
      请关注本站微信公众号,回复“小麦苗博客”,获取验证码。在微信里搜索“DB宝”或者“www_xmmup_com”或者微信扫描右侧二维码都可以关注本站微信公众号。

标签:

Avatar photo

小麦苗

学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复

嘿,我是小麦,需要帮助随时找我哦
  • 18509239930
  • 个人微信

  • 麦老师QQ聊天
  • 个人邮箱
  • 点击加入QQ群
  • 个人微店

  • 回到顶部