linux – 使用intel igb(已解决)在3/5 raid6 iSCSI NAS设备上的第一个RX队列上丢弃100%数据包

前端之家收集整理的这篇文章主要介绍了linux – 使用intel igb(已解决)在3/5 raid6 iSCSI NAS设备上的第一个RX队列上丢弃100%数据包前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
编辑:问题已解决.有问题的队列已用于流控制数据包.为什么igb驱动程序传播FC数据包以使其丢弃(并计数)是另一个问题.但解决方案是,数据丢失的方式没有任何损失.

非常感谢syneticon-dj,你指向dropwatch的指针是黄金!

===原始问题供进一步参考===

我们有以下情况:

系统:
有问题的服务器是dell poweredge,带有4个四核氙气,128GB ECC RAM,运行debian linux.内核是3.2.26.
有问题的接口是特殊的iSCSI卡,有四个接口,每个接口使用Intel 82576千兆以太网控制器.

背景:在我们的一台服务器上,很多NAS(Thecus N5200和Thecus XXX)在专用的1GB / s接口上使用iSCSI连接.我们有5张卡,每张卡有4个端口. NAS文件管理器直接连接,两者之间无切换.

两周前,我们设法清除了四个NAS文件管理器,并使用它们使用mdadm构建raid6.使用LVM,我们可以为各种项目动态创建,缩小和/或增加存储空间,而不是每隔一段时间就搜索所有NAS文件管理器以获取可用空间.

然而,我们在几乎每个接口上都有很多超支,并且丢失了很多数据包.调查显示,必须增加网络堆栈的默认设置.我使用sysctl来调整所有设置,直到不再发生溢出.

不幸的是,用于NAS raid的接口仍然丢弃了很多数据包,但只有RX.

搜索之后(这里,google,Metager,intel,无处不在,无处不在),我们发现有关intel igb驱动程序的信息存在一些问题,并且必须完成一些工作.

因此我下载了最新版本(igb-4.2.16),用LRO编译模块并支持单独的队列,并安装了新模块.

使用此驱动程序的所有20(!)接口现在都有8个RxTx队列(未配对)并启用了LRO.具体的选项是:

options igb InterruptThrottleRate=1 RSS=0 QueuePairs=0 LRO=1

irqbalancer很好地分配了所有接口的队列,一切都很棒.

那我为什么要写作呢?我们有以下奇怪的情况,根本无法解释:

NAS raid的五个接口中的三个(我们已经添加了一个备用NAS,并且一旦mdadm完成其当前重新形成就应该进行raid)显示大量(数百万!)的数据包丢弃.

使用ethtool的调查现在显示,由于新的多队列启用驱动程序,每个接口大量使用一个队列,这将是我们猜测的重塑.

但是有三个使用另一个队列,其中包含数百万个崩溃的数据包.至少展示了利用“监视”的调查,这些队列上的数据包号码与丢弃的包裹相关联.

我们将NAS上的MTU和接口从9000更改为1500,但丢包率增加,mdadm性能下降.因此它看起来不像MTU问题.此外,网络堆栈具有疯狂的内存量,这也不应该是一个问题.积压足够大(实际上很大)我们完全在海上.

这里有示例输出

~ # for nr in 2 3 4 5 9 ; do eth="eth1${nr}" ; echo " ==== $eth ==== " ; ethtool -S $eth | \
> grep rx_queue_._packet | grep -v " 0" ; ifconfig $eth | grep RX | grep dropped ; \
> echo "--------------" ; done
==== eth12 ==== 
    rx_queue_0_packets: 114398096
    rx_queue_2_packets: 189529879
          RX packets:303928333 errors:0 dropped:114398375 overruns:0 frame:0
--------------
==== eth13 ==== 
    rx_queue_0_packets: 103341085
    rx_queue_1_packets: 163657597
    rx_queue_5_packets: 52
          RX packets:266998983 errors:0 dropped:103341256 overruns:0 frame:0
--------------
==== eth14 ==== 
    rx_queue_0_packets: 106369905
    rx_queue_4_packets: 164375748
          RX packets:270745915 errors:0 dropped:106369904 overruns:0 frame:0
--------------
==== eth15 ==== 
    rx_queue_0_packets: 161710572
    rx_queue_1_packets: 10
    rx_queue_2_packets: 10
    rx_queue_3_packets: 23
    rx_queue_4_packets: 10
    rx_queue_5_packets: 9
    rx_queue_6_packets: 81
    rx_queue_7_packets: 15
          RX packets:161710730 errors:0 dropped:4504 overruns:0 frame:0
--------------
==== eth19 ==== 
    rx_queue_0_packets: 1
    rx_queue_4_packets: 3687
    rx_queue_7_packets: 32
          RX packets:3720 errors:0 dropped:0 overruns:0 frame:0
--------------

新的备用驱动器连接到eth15.
如您所见,没有超支,也没有错误.并且适配器报告,他们没有丢弃一个数据包.因此,内核将数据丢弃.但为什么?

编辑:我忘了提到eth12到eth15都位于同一张卡片上. eth19对另一个.

有没有人见过这种奇怪的行为,是否有解决问题的办法?

即使没有,有没有人知道一种方法,我们至少可以找出哪个进程占用了丢弃的队列?

非常感谢你提前!

解决方法

您有足够的接口来构建工作组交换机.由于这种配置并没有经常使用,因此没有经过彻底的测试,因此可能会出现奇怪的现象.

此外,由于您的设置非常复杂,您应该尝试通过简化它来隔离问题.这就是我要做的:

>排除简单的情况,例如通过发出/ sbin / ethtool -S< interface>来检查链接统计信息查看滴是否是与链接相关的问题
>因为NIC正在使用中断合并,increase the ring buffer并查看它是否有用
>使用dropwatch可以更好地了解是否可以增加任何其他缓冲区
>再次禁用多队列网络 – 有20个活动接口,几乎不会出现每个接口有多个队列可以获得任何性能的情况,根据您的描述,这可能是与排队相关的问题
>减少接口数量,看看问题是否仍然存在
>如果没有别的帮助,请向Kernel netdev mailing list发一个问题

猜你在找的Linux相关文章