原文链接：http://www.dbaleet.org/about_rac_interconnect_flow_control/
通常流量控制是如此的不起眼，以至于很少有dba知道它的存在，更不用说去了解它。“听名字，这个通常是网络工程师的该做的，不是吗？”“保持默认的就可以了，dba没有必要了解一些无关紧要的细支末节，因为这简直是浪费时间。法律没有规定不允许的事情都是允许的，没有哪条法律写的是你可以做什么。“ 说得有道理，流量控制通常是属于网络工程师管辖的领地，但是有时诊断问题的时候难免会越界，越是一些边界问题，越是容易遇到扯皮的事情。这就像大部分国家确实是法律没有规定不允许的事情都是允许的，但是你永远无法排除某些少数几个神奇国家的存在。
流量控制打个比方就跟生产车间的流水线一样，一个工艺完毕，才可以交给下一个工艺。例如生产啤酒，只有先把啤酒装入啤酒瓶中，然后才能把盖封上。如果不这样那就是空瓶了，最终消费者会退货，所产生的代价反而更大。在网络通信中，流控制就是防止源端的发送速率超过目标段的接受速率的一种机制。但是它和拥塞控制又不同，拥塞控制的一个前提就是拥塞已经发生了，然后是如何去解决拥塞的一种机制。一句话流量控制是限制，而拥塞控制是疏导，这又是题外话了。如果接受端的流量远大于发送端的流量或者接受端的处理能力远小于发送端，那么这个时候就需要用到流量控制了。所以流量控制就分为了发送端流量控制（我们用tx来表示）以及接受端流量控制（我们用rx来表示）。
我们能从Oracle官方的文档中找到Oracle是否推荐打开流量控制。
在MOS 400959.1 LINUX: POOR RAC-INTERCONNECT PERFORMANCE AFTER UPGRADE FROM RHEL3 TO RHEL4/OEL4中我们找到了这么一句话：
TX flow control in both Linux 2.4 and 2.6.9 are disabled (by default). It is not advised enabling TX flow control.
在MOS 563566.1 Troubleshooting gc block lost and Poor Network Performance in a RAC Environment中我们可以找到这么一句话：
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)
在 Barb Lundhild的 Oracle Cache fusion, private inter connects and practical performance management considerations in Oracle RAC中（Barb是当时RAC的product manager，现在X team的manager），我们可以找到：
Oracle recommeds that for the flow control Rx=on tx=off
/sbin/ethtool -A eth0 autoneg on tx off rx on
在Red Hat的white paper Tuning and Optimizing Red Hat Enterprise Linux for Oracle 9i
and 10g Databases 提到千兆以太网在2.6内核上可能无法使用流量控制，在高流量的情况下可能造成RAC私网发生丢包。
The e1000 network interface card family do not have flow control enabled in the 2.6 kernel on Red Hat Enterprise Linux 4 and 5. If you have heavy traffic, then the RAC interconnects may lose blocks, see Metalink Bug:5058952. For more information on flow control, see Wikipedia Flow control.
To enable Receive flow control for e1000 network interface cards, add the following line to the
/etc/m odprobe.conf file:
options e1000 FlowControl=1
没个推荐似乎并不一致，那么流量控制到底应该是打开还是关闭呢？
MOS 400959.1针对的是早期的RHEL例如4和早期的5版本，建议关闭tx，MOS 563566.1则是针对比较新的RHEL/OL，建议都打开流量控制。而默认就是都打开的。建议关闭tx的理由主要是通常发送端的流量控制是无关紧要的，因为这个交给操作系统本身机制更合适。如果源端发现无法到达目标段，则网络协议协议本身会重传，而加上tx控制则会对传输效率有一定影响。
通常情况下，我们打开或者关闭流量控制对系统的影响并不是太明显，但是如果出现了heavy traffic则可能流量控制的作用就体现出来了。如果在awr中发现RAC的私网发生了大量的gc block lost，并且在网络设备层面检测到有UDP checksum错误或者发送/接受端的传输错误时，这个时候可能就与流控制有关系了， 但是通常我们会先建议去调整udp的buffer，而非调整流量控制的开关。
综上，最佳实践是打开接受端的流控制而关闭发送段的流控制。 如果默认的流量控制都已经打开，并且系统运行一些正常，那么则无需去理会它。如果出现了gc cr/current block lost这样的等待事件，则我们先建议调整udp的send/receive buffer，如果不管用，才应该考虑调整流量控制是否管用。例如下面的这种情况流量控制就可能需要进行调整：
ifconfig –a
eth0 Link encap:Ethernet
HWaddr 00:0B:DB:4B:A2:04
inet addr:130.35.25.110
Bcast:130.35.27.255
UP BROADCAST RUNNING MULTICAST
MTU:1500
Mask:255.255.252.0
Metric:1
RX packets:21721236 errors:135 dropped:0 overruns:0 frame:95
TX packets:273120 errors:0 dropped:0 overruns:0 carrier:0
...
以上，下一篇将介绍如何诊断gc cr/current block lost等待事件。
Comment