浏览
帮助
登录
此帖子已超过 5 年
Solved!
king61_87f3c2
18 消息
0
6767
2013年10月13日 20:00
Jumbo frame能够用更少更大的frame来传输相同的数据量
理论上可以降低带宽的消耗，提升性能
现发现某些情况下，使用JF后，读写能否反而有了相应的下降
想请教各位，该如何去排错从而性能优化呢？
或者说在何种情况下才适合使用JF？
回复(5)
o17Uu33DCF12520
1.1K 消息
2013年10月14日 19:00
在实际环境中部署巨帧包前看看是不是已经满足这些必须条件：
»在网络中的所有服务器目前拥有相同的MTU »网卡必须支持MTU超过1500 »交换机必须支持MTU超过1500 » VLAN上的交换机必须支持MTU超过1500
然后核实下这些步骤和注意事项：
编辑网卡配置，并追加MTU = 9000 。
不要忘了，也对你的交换机/路由器！
# vi /etc/sysconfig/network-script/ifcfg- # ex. eth0 MTU=9000
# vi /etc/sysconfig/network-script/ifcfg- # ex. eth0
MTU=9000
然后重新启动单一界面...…
ifdown eth0; ifup eth0
…或整个网络服务
service network restart
服务网络重新启动,确认已正确应用新的配置： :
# ifconfig eth0
如果配置OK，你会看到这样的回应：
eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xxinet addr:x.x.x.x Bcast:x.x.x.x Mask:x.x.x.xUP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
如果你使用的bonding，您只需要在bond的设备配置启用巨型帧, :
# vi /etc/sysconfig/network-script/ifcfg-bond0 MTU=9000
# vi /etc/sysconfig/network-script/ifcfg-bond0
Roger_Wu
4K 消息
2013年10月13日 22:00
楼主是在存储的框架内讨论吧？首先jumbo frame一般只能提升iSCSI性能，对Server/Client这样的模式提升不大，甚至还会影响到应用。因此通常建议主机至少要两块网卡，一块给应用，一块给iSCSI存储。
另外调整jumbo frame需要在整个I/O链路上的所有设备上（end to end）都进行调整，包括主机、iSCSI HBA卡(如有)、交换机/路由器、存储iSCSI端口。
以前新部署ESX的时候我就直接设一个9000的MTU，倒也没试一下和其他大小的MTU做一下对比（VNX支持1260, 1448, 1500, 1548, 2000, 2450, 3000, 4000, 4080, 4470, 5000, 6000, 7000, 8000, 9000）。不过由于iSCSI走TCP/IP，可以很方便的抓包，因此真出了问题可以抓些包来分析一下看看。
1
2013年10月13日 23:00
大致想了下适用于jumbo frame的应用，主要是大文件、长时间的传输，比如数据备份、音频/视频流媒体和视频/图像编辑。
不适用jumbo frame的情形主要是大小封包共存的环境，这个就主要看对自己应用的了解程度了。
2013年10月15日 05:00
多谢指点
感觉需要结合网络带宽等综合考量才能判定
bairichard1
107 消息
2013年10月15日 18:00
无论文件大小，往返时间长短，何种应用，理论上都可以启用Jumbo Frame的。不过实施时要确保每一个端口都启用。
如果说实施正确的Jumbo Frame反而起了负面作用，我只能想到丢包处理时的不同状况。举个例子，假如现在有8000字节的数据要传，在Jumbo Frame和非Jumbo情况下都有丢包现象，会出现这样的状况：
Jumbo的情况:
source --> dest 巨帧丢失
source陷入等待，这段时间会很长，发送窗口会置为1个MSS。
source --> dest 重传巨桢。
非Jumbo的情况：
Source-->dest 第一个小包
Source-->dest 第二个小包 小包丢失
Source-->dest 第三个小包
Source-->dest 第四个小包
Source-->dest 第五个小包
Source-->dest 第六个小包
dest-->source ack 2号包
Source-->dest 第二个小包 重传二号小包
这种情况下实现了快速重传，所以不需要等待，发送窗口也没有减小得那么厉害。总体来说在这种状况下非jumbo frame性能更好。
戴尔支持资源
查看更多
查看全部
Top
o17Uu33DCF12520
1.1K 消息
0
2013年10月14日 19:00
在实际环境中部署巨帧包前看看是不是已经满足这些必须条件：
»在网络中的所有服务器目前拥有相同的MTU
»网卡必须支持MTU超过1500
»交换机必须支持MTU超过1500
» VLAN上的交换机必须支持MTU超过1500
然后核实下这些步骤和注意事项：
编辑网卡配置，并追加MTU = 9000 。
不要忘了，也对你的交换机/路由器！
然后重新启动单一界面...…
…或整个网络服务
服务网络重新启动,确认已正确应用新的配置：
:
如果配置OK，你会看到这样的回应：
eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:x.x.x.x Bcast:x.x.x.x Mask:x.x.x.x
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
如果你使用的bonding，您只需要在bond的设备配置启用巨型帧, :
Roger_Wu
4K 消息
0
2013年10月13日 22:00
楼主是在存储的框架内讨论吧？首先jumbo frame一般只能提升iSCSI性能，对Server/Client这样的模式提升不大，甚至还会影响到应用。因此通常建议主机至少要两块网卡，一块给应用，一块给iSCSI存储。
另外调整jumbo frame需要在整个I/O链路上的所有设备上（end to end）都进行调整，包括主机、iSCSI HBA卡(如有)、交换机/路由器、存储iSCSI端口。
以前新部署ESX的时候我就直接设一个9000的MTU，倒也没试一下和其他大小的MTU做一下对比（VNX支持1260, 1448, 1500, 1548, 2000, 2450, 3000, 4000, 4080, 4470, 5000, 6000, 7000, 8000, 9000）。不过由于iSCSI走TCP/IP，可以很方便的抓包，因此真出了问题可以抓些包来分析一下看看。
Roger_Wu
4K 消息
1
2013年10月13日 23:00
大致想了下适用于jumbo frame的应用，主要是大文件、长时间的传输，比如数据备份、音频/视频流媒体和视频/图像编辑。
不适用jumbo frame的情形主要是大小封包共存的环境，这个就主要看对自己应用的了解程度了。
king61_87f3c2
18 消息
0
2013年10月15日 05:00
多谢指点
感觉需要结合网络带宽等综合考量才能判定
bairichard1
107 消息
0
2013年10月15日 18:00
无论文件大小，往返时间长短，何种应用，理论上都可以启用Jumbo Frame的。不过实施时要确保每一个端口都启用。
如果说实施正确的Jumbo Frame反而起了负面作用，我只能想到丢包处理时的不同状况。举个例子，假如现在有8000字节的数据要传，在Jumbo Frame和非Jumbo情况下都有丢包现象，会出现这样的状况：
Jumbo的情况:
source --> dest 巨帧丢失
source陷入等待，这段时间会很长，发送窗口会置为1个MSS。
source --> dest 重传巨桢。
非Jumbo的情况：
Source-->dest 第一个小包
Source-->dest 第二个小包 小包丢失
Source-->dest 第三个小包
Source-->dest 第四个小包
Source-->dest 第五个小包
Source-->dest 第六个小包
dest-->source ack 2号包
dest-->source ack 2号包
dest-->source ack 2号包
dest-->source ack 2号包
Source-->dest 第二个小包 重传二号小包
这种情况下实现了快速重传，所以不需要等待，发送窗口也没有减小得那么厉害。总体来说在这种状况下非jumbo frame性能更好。