当前位置：首页 > news >正文

Oracle RAC最佳实践-优化私网连接

news 来源：原创 2025/6/16 1:17:20

在 Oracle RAC 环境中，私网（Interconnect） 是节点之间通信和数据传输的关键部分。一直有个误解，认为私网（心跳网）只要能通随便什么交换机都可以,甚至有直连的，实际上私网的性能至关重要，应该用公司里性能最好的交换机；私网连接性能直接影响集群的整体效率，尤其是在全局缓存（GC，Global Cache）操作中，如果通信延迟或带宽不足，会导致等待事件增多，进而影响数据库性能。在ORACLE RAC最佳实践中私网络建议配置 Jumbo Frame（也就是设置网卡的 MTU 为 9000，默认为1500），可以极大的减少心跳网络上的包重组。Jumbo Frame 可以非常有效地解决很多 RAC 上的 ORA-600/ORA-7445/性能问题/节点驱逐问题。比如：常见的“节点不断因心跳中断被驱逐的问题” 和某些 “ORA-600 [kjctr_pbmsg:badbmsg2] 的问题”。

为什么要配置Jumbo Frame：

以太网是集群互联（Cluster Interconnect）中广泛使用的网络技术。以太网的可变帧大小范围为46-1500 字节，这是主机、交换机等所有以太网参与者之间的传输单元。在这种情况下，1500 字节的上限被称为MTU（Maximum Transmission Unit，最大传输单元）。当一个应用程序发送的消息大于1500 字节（MTU） 时，这些消息会被分段为1500 字节或更小的帧，在端点之间进行传输。在 Oracle RAC 中，DB_BLOCK_SIZE（一般8K） 乘以db_file_multiblock_read_count（默认128）的设置决定了全局缓存（Global Cache）消息的最大大小，而PARALLEL_EXECUTION_MESSAGE_SIZE（默认16384）决定了并行查询（Parallel Query）中消息的最大大小。这些消息的大小可以从2K 到64K 或更大。因此，在使用较低或默认的 MTU 值时，消息会被分段得更加频繁，碎片化更严重，消息重组消耗更多的时间，从而带来RAC性能问题。

1. 在负载较高时，或者实例重启时，私网流量会很大。

2. 增大MTU减少包重组可以显著提升RAC的稳定性。

3. OSWatcher 的 netstat log 中显示 packet reassembles failed 指标增加，就可以考虑配置 Jumbo Frame 了。

1. 如何通过 Jumbo Frame 优化私网

Jumbo Frame 是指支持超过标准 MTU（1500 字节）的网络数据包，通常设置为9000 字节。

(1) 修改网卡 MTU 为 9000

在 Linux 系统中，临时修改私网eth1的 MTU 的命令如下：

[root@dbt01 ~]# ip link showeth1 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether fe:fc:fe:30:7c:a4 brd ff:ff:ff:ff:ff:ff[root@dbt01 ~]#[root@dbt01 ~]# ip link set dev eth1 mtu 9000 ##修改私网网卡MTU[root@dbt01 ~]# ip link show eth1 ##验证修改结果 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether fe:fc:fe:30:7c:a4 brd ff:ff:ff:ff:ff:ff

注意：两个节点都需要修改

(2) 永久修改 MTU

编辑网卡配置文件：

Red Hat/CentOS

sudo vi /etc/sysconfig/network-scripts/ifcfg-eth1

添加以下内容：

```
MTU=9000
```

重启网卡：

sudo ifdown eth1 && sudo ifup eth1

注意：两个节点都需要修改

2. 修改 Jumbo Frame 后如何验证效果

(1) 使用`ping` 命令测试 Jumbo Frame

测试节点间的网络是否支持 9000 字节的 MTU：

 [root@dbt01 ~]# ping -c 4 -Mdo -s 8972 192.168.11.122
PING 192.168.11.122 (192.168.11.122) 8972(9000) bytes of data.
8980 bytes from 192.168.11.122: icmp_seq=1 ttl=64 time=0.887 ms
8980 bytes from 192.168.11.122: icmp_seq=2 ttl=64 time=0.492 ms
8980 bytes from 192.168.11.122: icmp_seq=3 ttl=64 time=0.546 ms
8980 bytes from 192.168.11.122: icmp_seq=4 ttl=64 time=0.557 ms

-Mdo
：强制不分片。
-s 8972
：ICMP 数据包大小（加上 28 字节头部等于 9000 字节 MTU）。

正常情况下，所有包都应返回成功。

如果没有启用成功报错应该如下，提示message to long

[root@dbt01 ~]# ping -c 4 -Mdo -s 8972 10.229.43.142
PING 10.229.43.142 (10.229.43.142) 8972(9000) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500

(2) 检查网络统计信息

使用ifconfig 检查网卡统计信息：

[root@btdbt01 ~]# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr FE:FC:FE:30:7C:A4  inet addr:192.168.11.121  Bcast:192.168.11.255  Mask:255.255.255.0inet6 addr: fe80::fcfc:feff:fe30:7ca4/64 Scope:LinkUP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1RX packets:853452922 errors:0 dropped:5 overruns:0 frame:0TX packets:708597428 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:1000 RX bytes:724294742414 (674.5 GiB)  TX bytes:510652307354 (475.5 GiB)

确保没有RX 或TX 错误包。
验证网络数据包的传输正常。

(3) AWR 报告对比分析

启用 Jumbo Frame 后，重新生成 AWR 报告，比较RAC相关指标变化如GC类等待，interconnect statistics等

总结

尽管Jumbo Frames在大多数交换机中广泛支持，但它并不是IEEE认可的标准。所以在实际操作中，建议与网络管理员协作，确保交换机和所有节点都支持Jumbo Frame，以避免网络不兼容问题。在许多情况下，由于不正确的设置、驱动程序或交换机软件中的错误，可能会出现故障或不一致，从而导致次优性能和网络错误。基于这些考虑在做集群的Jumbo Frame优化时建议谨慎操作，并和网络管理员深度沟通确认。

虽然有诸多限制，和可能得风险但是在oracle的官方文档中依然有如下的表述“There is some complexity involved in configuring Jumbo Frames, which is highly hardware and OS specific. The lack of a specific standard may present OS and hardware bugs. Even with these considerations, Oracle recommends using Jumbo Frames for private Cluster Interconnects.” 总之一句话虽然可能有诸多困难和问题，但是oracle 仍然建议在RAC集群中启用Jumbo Frame。

参考文档：

Recommendation for the Real Application Cluster Interconnect and Jumbo Frames (Doc ID 341788.1)

How to Modify Private Network Information in Oracle Clusterware (Doc ID 283684.1)

Troubleshooting gc block lost and Poor Network Performance in a RAC Environment (Doc ID 563566.1)