Global Cache Miss

最近数据库集群通过spotlight监控经常报一些警告：
 global cache 总是有Miss的情况
 Alarm raised  80.98 milliseconds latency across the interconnect. Average : 27.19 ms (averaged over 30 seconds) High Cluster latency (Interconnect Latency)

通过查找官方文档，发现如下：
确保 UDP 缓冲区大小合适
适用平台： Windows 除外的所有平台

原因： 私网可以说是 RAC 数据库的命脉。但是，如果未向 UDP 分配合适的缓冲空间用以发送和接收缓冲，则私网的性能将大幅降低。这将会导致您的集群出现稳定性问题。

更多信息：有关正确调整 UDP 缓冲区的更多信息，请参考以下文档：
Document 181489.1 Tuning Inter-Instance Performance in RAC and OPS
Document 563566.1 gc lost blocks diagnostics

注意： Windows 集群对 Cache fusion 通信使用 TCP，因此，UDP 缓冲区设置不适用于 Windows。

概要：
    在oracle rac环境中，RDBMS收集global cache的工作负载情况，这个情况会在STATSPACK、AWR、GRID CONTROL中被报告。集群中每个节点的全局内存块丢失状态（gc cr block lost" and/or "gc current block lost")都代表着网络中包交互的问题。这样的状态都应该被监控以及评估一确保GCS/GES网络效率。任何的块丢失会标明网络包传输中的问题并且应该被研究。
    绝大部分的global cache 块丢失都可以被联系到时网络错误配置的原因导致的。文件服务指南可以评估和查询到这行原因。
    即使大多数的讨论集中于性能问题上，它也可能导致一个节点被逐出。oracle集群依赖于心跳机制来确认节点资格。如果网络心跳经常性的被drop，节点被逐出就会发生。以下状况会导致节点被逐出:
 
    主要："gc cr block lost" / "gc current block lost" in top 5 或者重大的等待事件
    次要：
              SQL traces report multiple gc cr requests / gc current request /
              gc cr multiblock requests with long and uniform elapsed times
              Poor application performance / throughput
              Packet send/receive errors as displayed in ifconfig or vendor supplied utility
              Netstat reports errors/retransmits/reassembly failures
              Node failures and node integration failures
              Abnormal cpu consumption attributed to network processing

    注意：块丢失问题经常伴随着gc cr multiblock waits，例如：waits for scans of consecutive blocks

全局块丢失诊断导引：

 1、错误或不可靠的线缆/网卡/转换器的配置连接       --这个很好检查，这里不做讨论。
 2、不合理的UDP接受缓冲区大小设置/UDP缓存套接字溢出

    描述：oracle rac全局内存块的变动通常会是爆发性的，因此，系统需要缓存接受这些包当等待CPU的资源的时候。不可用的缓存区域导致了全局包的丢失。在大多数UNIX系统中 用 'netstat -s' or 'netstat -su'将会得到帮助决定是缓冲区溢出还是内存缓冲接受的错误。
 
    解决办法：包丢失的情况经常是服务器上UDP缓冲设置不充分所引起的。当出现包或块丢失的环境下，可以留心观察到 "global cache cr requests"的等待状况，通常这是由于内存设置不充分引起的。
    当设置 DB_FILE_MULTIBLOCK_READ_COUNT 参数超过4的时候，会导致这一问题的出现，为了减轻这个问题带来的影响，通过增加UDP缓冲区和减小 DB_FILE_MULTIBLOCK_READ_COUNT 参数值可以做到。
    判断你的UDP套接字缓冲是否溢出和包丢失在UNIX平台上，可执行如下：
 ‘netstat -s' 或'netstat -su’然后重点查看以下数值是否过大：
   udpInOverflowsudpInOverflows
   packet receive errors
   fragments dropped
   outgoing packet drop
    注意：UDP包的丢失通常的结果是延时增加，如果netstat -s 中TCP项中"outgoing packets dropped" 增加的明显，增加wmem_default 和 wmem_max 参数值到 4MB可以解决这个问题。UDP的发送和接受缓冲值是依赖于系统的设置的。这些值是可以动态设置的。
 
 net.core.rmem_default 代表socket的接收缓冲区的默认值

 可以通过man tcp帮助中查到此参数的详细解释。如果此参数设置过小，将影响到能够接收到的UDP包的大小。

 net.core.rmem_max     代表socket的接收缓冲区的最大值
 可以通过man tcp帮助中查到此参数的详细解释。如果源代码中设置的值比此值大，这此值为准。

 RHEL最初的设置如下：
    net.core.rmem_default = 126976
    net.core.rmem_max = 131071
 推荐使用值：
     #net.core.rmem_default = 524288
     #net.core.wmem_default = 524288
     #net.core.rmem_max = 4194304
     #net.core.wmem_max = 4194304

 3、低网络性能和高CPU利用率，‘netstat -s’报告包重组失败
 
 状况描述：大UDP数据包可能被重组并依据Medium Transmission Unit（MTU)值发送多帧数据包，这些碎片数据包需要在接受端重组。高CPU利用率、不充分的重组缓冲区和UDP缓冲空间均可导致包的
 重组失败。'netstat -s'报告了大量的’ "reassembles failed" 和 "fragments dropped after timeout" 在接受节点的IP状态栏中。
 netstat -s 查看IP状态：
      3104582 fragments dropped after timeout
      34550600 reassemblies required
      8961342 packets reassembled ok
      3104582 packet reassembles failed
 
 解决办法：增加碎片重组缓冲区，定义更多的重组区域。增加重组碎片的时间，增加UDP接受缓冲区去调节网络延时状况。
 增加以下设置调节内存利用率：
 IP分片缓冲区参数：
      net.ipv4.ipfrag_low_thresh

      net.ipv4.ipfrag_high_thresh

 用于组装分片的IP数据报的最大内存量，它将直接影响到能够接收到最大的UDP包的大小。因为超过MTU值的包都会被分片，分片的IP包达到目的端后需选缓存起来，等所有包都到达之后再组装。如果缓存不够用，多余的将被丢弃，这会导致组装失败。
   redhat linux最初的设置如下：
     net.ipv4.ipfrag_low_thresh = 196608
     net.ipv4.ipfrag_high_thresh = 262144
 该设置能够支持的最大UDP大小约40000字节。

 建议修改如下：
 net.ipv4.ipfrag_low_thresh = 393216

 net.ipv4.ipfrag_high_thresh = 524288

 

4、Global Cache local miss rate is raised

     当本地的全局高速缓存丢失比例超过一定的门槛时候，我们通常需要警惕的是数据库中的热块问题。

     当一个block被一个逻辑读的时候，集群中一个实例需要从另外一个实例的不同模式的内存中传输。可能会引起这样的丢失警告。

    当一个热块被非常高频率的传输调用时，集群会出现过多的协调活动：

    可以解决的办法如下：

      1、对经常被调取的表进行分区

      2、通过使用服务隔离应用活动