何の連絡もなしに大量のアクセスが押し寄せてきたので、IRCで問い合わせたところ理由はわかりました。それと同時に、このことがミラーネットワークの管理者に直前まで伝えられなかったため、事前の連絡ができなかったこともわかりました。
今回のアクセスは定例のアップデート以上でした。それを伝えたら、「アップグレードが進んでうれしいよ」みたいな返事が返ってきて切れそうになりました。そうじゃねー、これだけのアクセスが予告もなしに来たら困るんだっつーの…とはさすがに言いませんでしたが。
今回のトラフィックのグラフはこんな感じです。2.26Gbpsが最高でした。何度も出力パケットが詰まる症状に悩まされていたため、ところどころトラフィックがガクッと減っています。
この現象は前回のアップデートでも観測されていました。そのときはLSOとJumbo Frameを切って解決したかと思っていたのですが、3月7日の2時半から完全にパケットが流れなくなる症状が生じました。そのときにはLACP (Link Aggregation Control Protocol)によってインターフェイスが1つ殺されていたので、LACPを切って様子を見ることにしました。
ところが犯人はLSOでもJumbo FrameでもLACPでもありませんでした。これらの要因を取り除いても発生してしまいます。4つのインターフェイスを束ねたうちのどれかが死んでいるわけでもなく、4つ均等に流れてはいるのですが、全体としては1本分も出ないのです。
リンクアグリゲーションのバグの可能性があるので、関係するパッチがないか探したところ、あまり関係があるとは思えないもののaggrドライバのパッチがありました。わらにもすがる気持ちで当ててみたのですが、残念ながら本当に関係ありませんでした。
こうなるとできることは、現象が起きてから復帰までの時間を短縮することだけです。この現象が起きるとdld_tx_enqueueのロックで詰まることはわかっているので、lockstatで詰まっていないかを調べて、詰まっていたらaggr1を再plumbするという手を考えて、仕込んだところで寝たのですが、幸か不幸か現象は再現しませんでした。
以前紹介したときはftp.jaist.ac.jpは、e1000gを2本ずつ束ねて別のルータに接続していました。この構成では着信パケットの処理を2つのコアで行わなければならないので、ここが律速になる可能性があります。そこで4本を全部束ねることにしたのですが、全部束ねて全開でパケットの送受信をすると、リンクアグリゲーションのバグを踏んでしまうようです。
0 件のコメント:
コメントを投稿