不能用ifconfig的rx/tx除以理论带宽算利用率——因统计l2字节数含帧头/crc，比tcp/udp有效载荷多40–60字节，高估15%–20%；且不区分协议、忽略小包突发性，真实瓶颈常是延迟与丢包而非带宽。
别用 ifconfig 的 rx/tx 除以理论带宽算“利用率”——误差常达 15%–20%，根本不可信。
为什么 ifconfig 显示的字节数不能直接换算带宽利用率
ifconfig 统计的是 L2 层字节数，含以太网头（14 字节）、VLAN Tag（4 字节）、CRC（4 字节），而 Oracle GC 流量是 TCP/UDP 载荷，每包实际有效载荷比 ifconfig 计数少约 40–60 字节。直接拿 rx_bytes 除以 10Gbps 算“85% 利用率”，很可能把真实负载高估了。
更关键的是：ifconfig 不区分协议、不反映突发性。Cache Fusion 流量呈短时密集小包（如 gc cr block 2-way），CPU 软中断和 UDP 接收队列压力远大于吞吐均值。
- 看平均包长：用
cat /proc/net/dev | grep bond1提取rx_bytes和rx_packets，计算rx_bytes / rx_packets；若长期低于 300 字节，说明是典型 GC 小包流，此时带宽不是瓶颈，延迟和丢包才是 - 对比 ethtool 协商速率：运行
ethtool bond1，确认显示Speed: 10000Mb/s且Duplex: Full；若降为1000Mb/s，物理链路已降速，所有软件层监控都失去意义 - ifconfig 的
dropped增长 ≠ 网络拥塞，很可能是 ring buffer 满或驱动未及时收包，需结合ethtool -S bond1 | grep rx_discards进一步定位
真正有效的实时带宽监控方法
要盯住「Oracle 实际发出的 GC 流量」，而不是网卡裸吞吐。优先用操作系统级工具抓取 UDP/TCP 负载分布，并过滤 GCS/GES 端口。
- 用
iftop -P tcp -f "port 6200 or port 6201"（默认 GCS/GES 端口）观察节点间实时流量流向，确认是否某对节点间单向压倒性偏高（比如 node1 → node2 流量是 node2 → node1 的 5 倍），这是负载不均的直接证据 - 用
netperf -H node2 -t UDP_STREAM -l 60测纯 UDP 吞吐，万兆私网应稳定 ≥ 9 Gbps；若 ethtool -c bond1） - 写个轻量脚本轮询
/proc/net/dev，只算差值、不除理论带宽，输出 KB/s/MB/s 即可——目的是看趋势突变，不是追求绝对精度。例如某节点rx_bytes每秒增量从 12MB/s 突跳到 85MB/s，配合 AWR 中gc cr blocks received暴涨，就能锁定问题时段
必须同步验证的三个隐藏瓶颈点
带宽利用率本身是个“果”，不是“因”。很多团队盯着数字没下降，却漏掉真正拖慢 GC 的底层因素。
-
netstat -su查UdpInOverflows：非零即危险。说明内核 UDP 接收缓冲区溢出，GC 包被静默丢弃。必须调大net.core.rmem_max至 ≥ 25165824（24MB），且重启 Oracle（LMS 进程启动时读取该值） -
ethtool -S bond1 | grep -i "rx_pause\|tx_pause"：若rx_pause_cnt持续上升，说明交换机正在施加流控，根源在对端端口拥塞或 buffer 配置不足，不是 Oracle 配置问题 - 查 HAIP 地址：RAC 11.2.0.2+ 默认走
169.254.x.x虚拟地址，tcpdump若还抓192.168.1.x私网 IP，必然为空。先跑oifcfg getif确认 cluster_interconnect 网段，再ifconfig | grep 169.254找真实 HAIP，抓包命令必须指定该地址
最常被跳过的动作是：不验证 MTU 是否全链路一致（节点网卡、交换机端口、HAIP 接口），也不检查 UdpInOverflows 是否归零。这两项不做，所有带宽数字都是假象。
