1:MTU相关概念

1.1:MTU（Maximum Transmission Unit）

MTU是一个计算机网络专有名词，意思为最大传输单元MTU（Maximum TransmissionUnit，MTU），是指网络能够传输的最大数据包大小，以字节为单位。MTU的大小决定了发送端一次能够发送报文的最大字节数。如果MTU超过了接收端所能够承受的最大值，或者是超过了发送路径上途经的某台设备所能够承受的最大值，就会造成报文分片甚至丢弃，加重网络传输的负担。如果太小，那实际传送的数据量就会过小，影响传输效率。

MTU是数据链路层的概念，指数据链路层对数据帧长度的限制。不同链路介质类型的网络有不同的默认MTU值，以下是一些常见网络的默认值：

1.2:Jumbo帧（Jumbo Frame）

以太网经过几十年的发展，速度已经从最初的10M被提升到了上百G，速度提高了上万倍。在这样高速度的传输数据中，如果还是延续经典以太网的最大帧长不超过1518 字节的限制，那么在每秒中传输的数据包的个数将很大。由于每个数据包都需要网络设备来进行处理，由此带来的额外开销也将很大，而且这个开销随着网络速度的提高而愈加明显。

于是一些厂商提出了巨型帧（Jumbo Frame）的概念，把以太网的最大帧长扩展到了9K，相当于增强版的MTU，区别在于：

Jumbo帧是在数据链路层进行处理的。MTU涉及的分片通常是在网络层进行。

Jumbo帧长包括二层以太帧头及CRC部分。

MTU一般不包括这部分，指的是三层IP报文部分的长度。在网络应用中，MTU最大值受限于Jumbo帧的最小值，MTU值至少要比Jumbo帧小18字节

加大帧长的好处在于，减少了网络中数据包的个数，减轻了网络设备处理包头的额外开销。大量减少的帧数目也带来了性能的提高。Jumbo帧是一种厂商标准的超长帧格式，目前还没有获得IEEE标准委员会的认可，但是大多数的设备厂商都已经开始支持。

1.3:回环网卡（Loopback adaptor）

回环网卡（Loopback adaptor），是一种特殊的网络接口，它不是实际的网络接口或真正的网卡硬件，而是操作系统提供的一个软件。通过回环网卡，可实现同主机下不同服务间网络层上使用网络协议（如TCP/IP协议）的通信。比如 Linux 下的 lo 接口和 Windows 下的 Microsoft Loopback Interface 网卡都是回环网卡。

1.4:内联网卡（host's network adapter）

内联网卡，也称主机网卡。泛指Oracle RAC环境中集群间内部通信，或与集群所在LUN网段上交换机通信的网卡，与回环网卡不同，这些内联网卡是实际的硬件设备。比如RAC环境中公私网IP所在的网卡就是内联网卡。

MTU指的就是在网络层一个报文单元中IP Header+IP Payload的长度，这中间存储的就是实际的数据，传统的网络层MTU在46~1500字节之间

如上图所示：

上边为标准帧大小，单个标准帧有1522字节长度MTU构成

下边为巨型帧大小，单个巨型帧有9000字节长度MTU构成

2:回环网卡上的MTU

回环网卡上MTU由操作系统自行决定（默认为“65536”），且可修改，当linux系统上lo接口的MTU过大，可能会导致oracle数据库存在异常。

如下，当loopback adapter的MTU过大时，会导致oracle出现如下告警：

ORA-00603: ORACLE server session terminated by fatal error

ORA-27504: IPC error creating OSD context

ORA-27300: OS system dependent operation:sendmsg failed with status: 105

ORA-27301: OS failure message: No buffer space available

ORA-27302: failure occurred at: sskgxpsnd2 Source Script: rman_backup.ksh

可使用"netstat -in"查看linux机器上各网口的MTU值

Linux: #netstat -in

可以看到上图中linux服务器lo接口的mtu值为：65536

可使用"ifconfig lo mtu 16384"修改回环网卡的mtu值

Linux : #ifconfig lo mtu 16384

修改后立即生效

参考文档:MOS DOC ID: 2322410.1

说明：lo接口的mtu仅在本地主机生效，上述提到的问题也很常见，在客户生产环境上多有修改

3:内联网卡的MTU

3.1:相关说明

内联网卡既主机网卡，若厂商支持，是可以开启巨型帧（Jumbo Frame）模式。设置单个报文包的MTU大小为9000。

加大帧长的好处在于：减少了网络中数据包的个数，减轻了网络设备处理包头的额外开销。大量减少的帧数目也会带来一定程度上性能的提高。

Jumbo帧是一种厂商标准的超长帧格式，目前还没有获得IEEE标准委员会的认可，但是大多数的设备厂商都已经开始支持。

需要注意：不管是否开启巨型帧,对接的设备以太网接口MTU配置需要保持一致，也及时说在RAC环境中,每个节点主机上内联网卡的MTU以及相关交换机的MTU必须保持一致。

3.2:存在的风险

1. 机器配置风险：

如果想在内联网卡上开启巨型帧模式，首先需要确定集群内所有机器都支持巨型帧模式，这个需要与相关厂商确认。其次，需保证相关机器上的相关配置正确，包括RAC环境中的各节点主机及相关交换机。只要其中一个配置存在问题，都会导致RAC集群对内或对外的数据传输存在异常。

1. 网络传输风险

开启巨型帧模式后，在网络层，当个报文传输的最大单元由1500上升到9000，如果在传输中存在丢包或错包的情况，那问题报文包的回传或纠错时间会比不开巨型帧模式耗时更长。如果集群网络不佳，丢包或错包过多，那么回传及纠错的时间消耗可能会抵消掉因传输帧数减少而带来的性能提升，甚至可能会照成性能下降。

4:ORACLE RAC与 Jumbo帧的官方建议

4.1:相关说明及影响范围

以太网是一种广泛用于集群互连的网络技术。以太网的可变帧大小为 46-1500 字节，是所有以太网参与者（如主机和交换机）之间的传输单元。

其上限（在本例中为1500）称为 MTU（最大传输单位）。当应用程序发送大于 1500 字节 （MTU） 的消息时，它会从一个端点分段为 1500 字节或更小的帧到另一个端点。

在 Oracle RAC 中，DB_BLOCK_SIZE 的设置乘以 MULTI_BLOCK_READ_COUNT 确定全局缓存消息的最大大小，PARALLEL_EXECUTION_MESSAGE_SIZE确定并行查询中使用的消息的最大大小。这些消息大小的范围可以从 2K 到64K或更大,因此使用较低/默认MTU时会更加碎片化。

巨型帧引入了以太网帧超过其 IEEE 802 指定的最大传输单位 1500 字节到最大 9000 字节的功能。尽管巨型帧在大多数 NIC 和数据中心级管理型交换机中广泛使用，但它不是 IEEE 批准的标准。

虽然好处是显而易见的，但不能保证巨型帧与某些现有网络设备的互操作性。虽然巨型帧可以为专用群集互连实施，但它需要非常仔细的配置和测试才能实现其优势。在许多情况下，由于设置不正确、驱动程序或交换机软件中的错误，可能会导致性能欠佳和网络错误，从而导致故障或不一致。

上图oracle原厂提供的参数优化建议就是基于上述描述而来的。

4.2:相关配置

为了使巨型帧在群集互连网络中正常工作，需要在主机、其网络接口卡和交换机级别中进行仔细配置：

• 主机的网络适配器必须配置为 9000 的持久 MTU 大小（该大小将在重启或重引导后继续存在）。
• 例如：ifconfig -mtu 9000 后跟 ifconfig -a 以显示设置已完成。
• 某些网卡需要额外的硬件配置。

例如，某些英特尔网卡需要配置特殊的描述符和缓冲区，以便巨型帧正常工作。

• • 此外还必须正确配置 LAN 交换机，以增加巨型帧支持的 MTU。确保所做的更改是永久性的（在电源重启后仍能幸存下来），并且两个“Jumbo”引用相同的大小，建议使用 9000（某些交换机不支持此大小）。
• 由于巨型帧缺乏标准，交换机之间的互操作性可能会出现问题，需要高级工程师进行故障排除。
• 请记住，给定网络路径中任何设备使用的最小 MTU 决定了沿该路径传输的所有流量的最大 MTU（MTU 上限）。
• 未能在集群和交换机的所有节点中正确设置这些参数可能会导致不可预测的错误以及性能下降

4.3:测试

说明：下列测试方法及结果参考ORCALE MOS官方文档，未在生产环境上进行测试

要求网络和系统管理员以及供应商使用标准工具（如 SPRAY 或 NETCAT）全面测试配置，并证明在使用巨型帧时有改进而不是降级。

（1）：Traceroute测试
在 Linux/Unix 上检查它是否正确配置的方法是使用Traceroute，具体命令如下：

[node01] $ traceroute -F node02-priv 9000

traceroute to node02-priv (10.x.x.2), 30 hops max, 9000

1 node02-priv (10.x.x.2) 0.232 ms 0.176 ms 0.160 ms

[node01] $ traceroute -F node02-priv 9001

traceroute to node02-priv (10.x.x.2), 30 hops max, 9001 byte packets

traceroute: sendto: Message too long

1 traceroute: wrote node02-priv 9001 chars, ret=-1

9000 数据包通过没有错误，而 9001 失败，所以这是一个正确的配置，支持最多 9000 字节的消息，没有碎片。

（2）Ping测试

使用 ping 时，我们必须考虑每个数据包约 28 字节的开销，因此 8972 字节没有错误，而 8973 字节失败，说明这是一个正确的配置，支持最多 9000 字节的消息，没有碎片：

[node01]$ ping -c 2 -M do -s 8972 node02-priv

PING node02-priv (10.x.x.2) 1472(1500) bytes of data.

1480 bytes from node02-priv (10.x.x.2): icmp_seq=0 ttl=64 time=0.220 ms

1480 bytes from node02-priv (10.x.x.2): icmp_seq=1 ttl=64 time=0.197 ms

[node01]$ ping -c 2 -M do -s 8973 node02-priv

From node02-priv (10.x.x.1) icmp_seq=0 Frag needed and DF set (mtu = 9000)

From node02-priv (10.x.x.1) icmp_seq=0 Frag needed and DF set (mtu = 9000)

2022/11/9 09:22 Document 341788.1

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=142419yuph_119&id=341788.1 3/4

--- node02-priv ping statistics ---

0 packets transmitted, 0 received, +2 errors

For Solaris platform, the similar ping command is:

$ ping -c 2 -s node02-priv 8972

注意：由于超过 MTU 大小，Ping 会报告碎片错误。

4.4性能说明

对于 RAC内联网卡，正确配置巨型帧的设备通过减少必须将大型消息分解为标准以太网的较小帧时发生的 TCP、UDP 和以太网开销来提高性能。

由于可以发送一个较大的数据包，因此消除了各种较小数据包之间的数据包间延迟。在需要高吞吐量和带宽的方案中以及系统受 CPU 限制时，性能的提高最为明显。

使用巨型帧时，需要的缓冲区传输更少，这是 IP 堆栈中分段和重组减少的一部分，因此对减少 Oracle 块传输的延迟有影响。

如配置部分所示,任何不正确的设置都可能会阻止实例启动或对性能产生非常不利的影响。

4.5已知错误

在某些版本的 Linux 中，英特尔的以太网驱动程序和 UDP 代码路径以及巨型帧中存在可能影响性能的特定错误。检查并使用这些驱动程序的最新版本，以确保您没有遇到这些较旧的错误。

The following bugzilla bugs 162197, 125122 are limited to RHEL3.

4.6官方建议

配置巨型帧涉及一些复杂性，这是高度特定于硬件和操作系统的。缺少特定标准可能会出现操作系统和硬件错误。即使有这些考虑，Oracle 仍建议对专用群集互连使用巨型帧。

由于巨型帧没有官方标准，因此客户应对此配置进行适当的负载测试。适配器中数据包丢失、套接字缓冲区或 DMA 溢出、TX 和 RX 错误的任何指示都应注意并与硬件和操作系统供应商核实。

本说明中的建议仅适用于 Oracle 专用互连，不适用于其他 NAS 或 iSCSI 供应商测试和验证的巨型帧配置网络。

Oracle VM 在所有 ovm2 版本和所有 ovm3.0 中都不支持 Jumbo，但从 ovm3.1.1 开始，它受支持，请参阅：

http://www.oracle.com/us/technologies/virtualization/ovm-3-1-whats-new-1634275.pdf

-------------------------------------------------------------------------------

本章节参考文档：Recommendation for the Real Application Cluster Interconnect and Jumbo Frames (Doc ID341788.1)

5:汇总总结：

回环网卡MTU修改：

根据上述材料提到的，遇到数据库出现：
ORA-27301: OS Failure Message: No Buffer Space Available
ORA-27302: failure occurred at:sskgxpsnd2 Source Scrip

报错时,可以通过调低对应主机lo接口的MTU值来处理，由于linux服务器中lo接口属于回环网卡，只对本地主机生效，且上述问题比较常见，在客户的生产环境多有发生，且都是通过修改lo接口的MTU来处理。

内联网卡巨型帧模式MTU修改：

至于内联网卡的MTU修改，ORACLE官方建议是在支持巨型帧的集群环境机器上开启巨型帧模式，并将巨型帧的MTU设定为9000。

修改巨型帧MTU为9000后,单个报文包中可传输的数据远大于标准帧MTU1500的数据，因此可以减少帧切片次数及传输的帧目数，从而可以节省部分性能消耗及传输时间。

但是，开启rac环境内联网卡的巨型帧模式需十分谨慎：

修改前：

需确定该集群环境中各个机器是否支持开启巨型帧模式，这个机器不只包括节点主机，还包括相关的网络设备，如交换机，路由器等机器，只要其中有一个机器不支持Jumbo帧模式，那么整个集群都可能收到影响。

修改时：

修改网卡巨型帧模式时要确保所有配置全部配置正确且生效，确保主机重启或其他情况下，相关配置不会失效，之间只要有一项配置存在问题，将会导致所有正确的配置全部作废。

修改后：

修改集群内联网卡开启巨型帧模式后，需网络方面专家进行评估并测试，确定配置生效并评估修改后集群的性能变化。如果集群网络情况不佳，修改巨型帧后非但无法达到预期的性能提升，反而可能出现性能下降，通信异常等问题。

由于修改集群内联网卡巨型帧模式涉及方面较大，涉及网络方面配置等因素，在客户中未对此进行过修改。

此外，日常运维中如果集群在网络方面不存在瓶颈（如gc等待严重，不同节点数据传输时间过长影响业务性能），通常不建议对此配置进行修改