イーサネットインターフェイスが約 30 秒間応答を停止し、その後受信したすべてのパッケージを確認する理由は何ですか?

2024-6-22 • tag-icon

イーサネットインターフェイスが約 30 秒間応答を停止し、その後受信したすべてのパッケージを確認する理由は何ですか?

最初の質問です！こんにちは！

Ubuntu 16.04 で実行しています。

ハードウェア情報:lspci | awk '/[Nn]et/ {print $1}' | xargs -i% lspci -ks %

00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-V
    Subsystem: ASUSTeK Computer Inc. Ethernet Connection (2) I219-V
    Kernel driver in use: e1000e
    Kernel modules: e1000e
02:00.0 Network controller: Intel Corporation Device 093c (rev 3a)
    Subsystem: Intel Corporation Device 7001

P2P アプリケーションを実行しているときに、奇妙なイーサネットストールが発生します -> より正確には:https://github.com/prysmaticlabs/prysm同じアプリケーションログによると、私のマシンには約30のピアが接続されています。帯域幅の使用率は低く（ピーク時6Mbps）、Cat6ケーブルで動作しており、ファイバーアップリンクは約120Mbpsで、ポートは正しく転送されています。私が見えますかorg。トレントなどの他の P2P アプリでは、競合する動作は見られません。

前述のとおり、症状は奇妙です。アプリケーションを実行すると、接続が失われることはありません。しかし、ネットワーク上で実行する必要がある別のアプリケーション (Web ブラウジング、チャット、ファイル転送など) を実行すると、インターフェイスが数秒、または数分間停止します。ブラウジングが頻繁にタイムアウトするため、これに気付きました。

停止が発生すると、アプリケーションは正常に実行され続けますが、他のすべてのアプリはインターネット接続を失います。ICMP (ping) トラフィックを監視します。

ホストからルータへ
別のローカルホストから停止しているホストへ

どちらのデバイスでも、いかなる種類の応答も返さなくなります (端末は出力を停止し、フィードバックもタイムアウトもありません)。長い停止の後、突然、すべてのパッケージが確認されます。次のサンプルを参照してください。

64 bytes from 192.168.1.1: icmp_seq=1122 ttl=64 time=0.304 ms
64 bytes from 192.168.1.1: icmp_seq=1123 ttl=64 time=0.303 ms
64 bytes from 192.168.1.1: icmp_seq=1124 ttl=64 time=0.313 ms
64 bytes from 192.168.1.1: icmp_seq=1125 ttl=64 time=0.263 ms
64 bytes from 192.168.1.1: icmp_seq=1126 ttl=64 time=0.266 ms
64 bytes from 192.168.1.1: icmp_seq=1127 ttl=64 time=0.273 ms
64 bytes from 192.168.1.1: icmp_seq=1128 ttl=64 time=0.289 ms
64 bytes from 192.168.1.1: icmp_seq=1129 ttl=64 time=0.276 ms
64 bytes from 192.168.1.1: icmp_seq=1130 ttl=64 time=0.280 ms
64 bytes from 192.168.1.1: icmp_seq=1131 ttl=64 time=0.635 ms
64 bytes from 192.168.1.1: icmp_seq=1132 ttl=64 time=0.292 ms
64 bytes from 192.168.1.1: icmp_seq=1133 ttl=64 time=0.537 ms
64 bytes from 192.168.1.1: icmp_seq=1134 ttl=64 time=0.299 ms
64 bytes from 192.168.1.1: icmp_seq=1135 ttl=64 time=0.272 ms
64 bytes from 192.168.1.1: icmp_seq=1136 ttl=64 time=27625 ms
64 bytes from 192.168.1.1: icmp_seq=1137 ttl=64 time=26635 ms
64 bytes from 192.168.1.1: icmp_seq=1138 ttl=64 time=25631 ms
64 bytes from 192.168.1.1: icmp_seq=1139 ttl=64 time=24640 ms
64 bytes from 192.168.1.1: icmp_seq=1140 ttl=64 time=23641 ms
64 bytes from 192.168.1.1: icmp_seq=1141 ttl=64 time=22671 ms
64 bytes from 192.168.1.1: icmp_seq=1142 ttl=64 time=21648 ms
64 bytes from 192.168.1.1: icmp_seq=1143 ttl=64 time=20652 ms
64 bytes from 192.168.1.1: icmp_seq=1144 ttl=64 time=19658 ms
64 bytes from 192.168.1.1: icmp_seq=1145 ttl=64 time=18655 ms
64 bytes from 192.168.1.1: icmp_seq=1146 ttl=64 time=17658 ms
64 bytes from 192.168.1.1: icmp_seq=1147 ttl=64 time=16659 ms
64 bytes from 192.168.1.1: icmp_seq=1148 ttl=64 time=15655 ms
64 bytes from 192.168.1.1: icmp_seq=1149 ttl=64 time=14632 ms
64 bytes from 192.168.1.1: icmp_seq=1150 ttl=64 time=13611 ms
64 bytes from 192.168.1.1: icmp_seq=1151 ttl=64 time=12588 ms
64 bytes from 192.168.1.1: icmp_seq=1152 ttl=64 time=11565 ms
64 bytes from 192.168.1.1: icmp_seq=1153 ttl=64 time=10542 ms
64 bytes from 192.168.1.1: icmp_seq=1154 ttl=64 time=9522 ms
64 bytes from 192.168.1.1: icmp_seq=1155 ttl=64 time=8501 ms
64 bytes from 192.168.1.1: icmp_seq=1156 ttl=64 time=7478 ms
64 bytes from 192.168.1.1: icmp_seq=1157 ttl=64 time=6459 ms
64 bytes from 192.168.1.1: icmp_seq=1158 ttl=64 time=5436 ms
64 bytes from 192.168.1.1: icmp_seq=1159 ttl=64 time=4415 ms
64 bytes from 192.168.1.1: icmp_seq=1160 ttl=64 time=3391 ms
64 bytes from 192.168.1.1: icmp_seq=1161 ttl=64 time=2370 ms
64 bytes from 192.168.1.1: icmp_seq=1162 ttl=64 time=1350 ms
64 bytes from 192.168.1.1: icmp_seq=1163 ttl=64 time=320 ms
64 bytes from 192.168.1.1: icmp_seq=1164 ttl=64 time=2.73 ms
64 bytes from 192.168.1.1: icmp_seq=1165 ttl=64 time=0.258 ms
64 bytes from 192.168.1.1: icmp_seq=1166 ttl=64 time=0.303 ms

その後、ネットワークはしばらくの間、正常に戻ります。

私が試したこと:

MTU を 1500 から 9000 に増やす (効果なし)
txqueuelen を 1000 から 11000 に増やす (効果なし)
接続できるピアの数を制限する（効果なし）
仮想化（効果なし）
ポート転送を削除します。これは機能しているように見えますが、アプリの目的に反し、速度が大幅に低下します。

現時点では、私には2つの理論があります。

1) ゲートウェイの動作がおかしい (確認できません)。ネットワーク内の他のデバイスはローカル接続と外部接続の両方で正常に動作しているため、この可能性は否定します。2) あるいは、何らかのメモリバッファーが詰まっている可能性がありますが、どちらかはわかりません。

インスピレーションを頂ければ幸いです!

答え1

そのカードの場合は、このカーネルパラメータを使用して起動してみてください。やり方はこうだ:

pcie_aspm=off

別の方法はを使用することですethtool。例:

sudo ethtool -G eth0 rx 256 tx 256

それはここ。

答え2

ネットワーク内のすべての要素をさらにデバッグした結果、他のデバイスへの影響はそれほど顕著ではないものの、トラフィック渋滞の影響を受けていることがわかりました。そのため、問題はルーター/スイッチにあると考えられます。ルーター/スイッチは、おそらく NAT 変換が原因で、P2P アプリケーションの要求に対応できずに詰まっている可能性があります。この問題を解決するために、より高度なハードウェアを入手してみます。

答え1

答え2

関連情報