Intel I350の受信バッファが最大値の4096でも溢れた

夏休みもいよいよ最終日となり、一息ついたところでI350の受信側のリングバッファが溢れた事象についてまとめます。

以前より3560Xのアップリンクポートでわずかながらパケット破棄が発生していました。
おそらくマイクロバーストによるものですが、最近新しいArista Networksのスイッチを導入したため、この症状自体は改善しました。

しかし上記の症状が安全装置になっていたのか、DMZ側でトラフィックを受けているLVSのパケット破棄が大量に発生するという現象が発生しました。
以下はその時のグラフです。

lv1

気づいた時にはドキっとしましたが、以前よりnet_devやigbのソースを一通り読んでいたため、カーネル側のキューか、NIC側のリングバッファ溢れだということはすぐ予想できました。
すぐにどちら側の問題か切り分けにはいりました。

まずキュー側です。
/proc/sys/net/core/netdev_max_backlog を超える値はキューイングされず、破棄されます。
影響範囲も少ないのでまずは何も考えずにふわっと増やしてみましたが、効果はありませんでした。

次にバッファ側を調べてみました。

このようにifconfigのoverrunsというなかなか上がらないカウンターが昇竜拳していました。

RX packets:1215382409979 errors:0 dropped:9836789 overruns:9836789 frame:0

値の元になっている/proc/net/devをみてみます。

$ cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
 bond1: 301302257145320 1242460031644    0 50134427 19769362     0          0  94522289 59829397999 1104977661    0    0    0     0       0          0
 bond0: 266789966151393 978716441978    0 95911204    0     0          0 142912972 564647908448725 2213999050962    0    0    0     0       0          0
  eth0: 266784042597227 978620538142    0 7402    0     0          0 142780453 564647908459099 2213999050966    0    0    0     0       0          0
  eth1: 5923561185 95903847    0 95903801    0     0          0    132519     1302      31    0    0    0     0       0          0
  eth2: 301300435242358 1242429666624    0 19769362 19769362     0          0  94522274 59829396211 1104977621    0    0    0     0       0          0
  eth3: 1821914034 30365078    0 30365065    0     0          0        15     1788      40    0    0    0     0       0          0
    lo: 6027064668 68489292    0    0    0     0          0         0 6027064668 68489292    0    0    0     0       0          0
bond0.11: 208950786744728 614004718922    0    0    0     0          0  88018817 487194387836941 1723708710469    0    0    0     0       0          0
bond0.12: 41205097680103 308328470394    0    0    0     0          0  50947732 72909647177800 412801455153    0    0    0     0       0          0

対応するカラムはfifoのところです。

fifoって意味はわかるけど、なんぞいやと調べたところFIFOバッファエラーということらしいです。
ethtool -Sでもエラーカウンターとして確認できます。

rx_no_buffer_count: 220474

参考サイト
https://nuclearcat.com/mediawiki/index.php/Intel_Gigabit_Performance#FIFO_buffer

つまり受信バッファが溢れているので、開けてやればいいということですね。
どうやるかというとNAPIはドライバが定期的にポーリングしてバッファの中身をとりにいくため、ポーリング頻度を上げるか、一度で処理する量を増やしてあげればバッファに空きができるはずです。
ただしCPUの負荷は上がります。
自社の場合NW I/O周りはひたすらCPUバウンドという経験がすでにあるため、LVSを新しく作る段階でCPUはXeon E5-1650v2というクロックの高いCPUを採用していたので余裕はまだまだあります。

以下の2がNAPIのバッファポーリングに関するパラメータです。

net.core.netdev_budget
net.core.dev_weight

テスト環境がない一発勝負なので、安全そうなnetdev_buger(処理数の上限アップ)を試してみたところ、見事にパケット破棄が消えてなくなりました。
また何故かわかりませんが、LAN側からのping監視に結構ジッターがあったのがなくなりました。
症状が改善した上に余計調子よくなってしまいました。
CPU負荷も目立って上昇はしていませんでした。

lv2

lv3

まあIntelのNICとはいえ、L3スイッチから全力で投げつけられたパケットを処理するのは箱出しパラメータだときつそうですね。
むしろよく動いてたと思います。

この勢いで10GネットワークでもLVSがまだまだ活躍することでしょう。

コメントを残す

メールアドレスが公開されることはありません。


*