3/5 raid6 iSCSI NAS Intel igbを使用するデバイス（解決済み））の最初のRXキューで100％のパケットがドロップされました

Question

編集：問題は解決しました。問題のキューは、フロー制御パケットに使用されています。 igbドライバーがFCパケットを伝播してドロップ（およびカウント）する理由は別の質問です。しかし、解決策は、データが失われるような方法でドロップされるものは何もないということです。

Syneticon-dj、ありがとうございました。dropwatchへのポインタはゴールドでした！

===さらに参照するための元の質問===

次の状況があります。

システム：問題のサーバーは、4つのクアッドコアキセノンCPU、128GB ECC RAMを搭載し、debianlinuxを実行しているDellPowerEdgeです。カーネルは3.2.26です。
問題のインターフェイスは、それぞれIntel82576ギガビットイーサネットコントローラを使用する4つのインターフェイスを備えた特別なiSCSIカードです。

背景：サーバーの1つで、多くのNAS（ThecusN5200およびThecusXXX）が専用の1GB/sインターフェイスでiSCSIを使用して接続されています。それぞれ4つのポートを持つ5枚のカードがあります。NASファイラーは直接接続されており、間にスイッチはありません。

2週間前、4つのNASファイラーをクリアし、それらを使用してmdadmを使用してraid6を構築しました。LVMを使用すると、さまざまなプロジェクトのストレージを動的に作成、縮小、拡張できます。すべてのNASファイラーで空き領域を検索する代わりに、時々頻繁に。

ただし、ほとんどすべてのインターフェイスで多くのオーバーランが発生し、多くのパケットがドロップされました。調査の結果、ネットワークスタックのデフォルト設定を増やす必要があることがわかりました。オーバーランが発生しなくなるまで、sysctlを使用してすべての設定を微調整しました。

残念ながら、NAS RAIDに使用されるインターフェイスは、依然として多くのパケットをドロップしますが、RXのみをドロップします。

（ここでは、グーグル、メタガー、インテル、どこでも、どこでも）検索した後、インテルigbドライバーに関する情報にいくつかの問題があり、いくつかの作業を行う必要があることがわかりました。

したがって、最新バージョン（igb-4.2.16）をダウンロードし、LROと個別のキューをサポートしてモジュールをコンパイルし、新しいモジュールをインストールしました。

このドライバーを使用するすべての20（！）インターフェイスには、8つのRxTxキュー（ペアリングされていない）があり、LROが有効になっています。具体的なオプションラインは次のとおりです。

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

irqbalancerはすべてのインターフェースのキューをうまく分散しており、すべてがうまく機能しています。

それで、なぜ私は書いているのですか？次のような奇妙な状況があり、それを説明することはできません。

NAS RAIDの5つのインターフェイスのうち3つ（予備のNASを1つ追加しました。mdadmが現在の形状変更を完了したら、RAIDを拡張する必要があります）は、大量（数百万！）のパケットを示します。ドロップします。

Ethtoolを使用した調査では、新しいマルチキュー対応ドライバーのおかげで、各インターフェイスが1つのキューを大量に使用していることがわかりました。これは、私たちが推測する形の変化です。

しかし、3つは、数百万の着信パケットを含む別のキューを使用し、それらはすべてドロップされます。少なくとも、「watch」を利用した調査では、これらのキューのパケット番号がドロップされたパッケージと相関していることが示されました。

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に接続されています。
ご覧のとおり、オーバーランやエラーはありません。また、アダプタは、単一のパケットをドロップしなかったと報告しています。したがって、データを破棄するのはカーネルです。しかし、なぜ？

edit：eth12からeth15がすべて同じカードにあることを忘れました。別のeth19。

誰かがそのような奇妙な行動を目撃したことがありますか、そして状況を改善するための解決策はありましたか？

そして、そうでない場合でも、少なくともどのプロセスがドロップキューを占有しているかを見つけることができる方法を誰かが知っていますか？

事前にどうもありがとうございました！

the-wabbit · Accepted Answer

ワークグループスイッチを構築するのに十分なインターフェイスがあります。この構成はあまり使用されておらず、したがって徹底的にテストされていないため、それだけで奇妙なことが起こると予想してください。

また、セットアップは非常に複雑なので、問題を単純化して切り分けてみてください。これは私がすることです：