diaryこの広告は、90日以上更新していないブログに表示しています。2009-10-13ローカルポートを食いつぶしていた話ここのところ、お仕事で管理しているシステムで、夜中に負荷が急上昇する事象が発生しており、夜な夜な対応に追われていました。(このブログ書いている今も、負荷がじわじわ上昇中なんですが・・・)で、いろいろと調査した結果、ようやく糸口がわかってきました。結論から言うと、ローカルポートなどのネットワーク資源を食いつぶしていたようです。以下、調べていってわかったことなどのメモです。webサーバで、リスティング広告システムの配信系です。リスティング広告の配信のシステムって一般的にロジックが複雑でいやーな感じなんですが、このシステムもご他聞に漏れずかなりのひねくれ者で、しかもトラヒックは結構多めです。システム全体で、日に1000万〜2000万クエリくらいかな。幸か不幸か、このご時勢においてもトラヒック的には成長し続けております。(99)みたいなログが出始めます。「99ってなんのエラーだ?」ということで調べてみました。perrorコマンドを使います。addressほっほう。OSレベルの問題、かつネットワーク系の問題らしいですね。調べていったら以下のことがわかってきました。/proc/sys/net/ipv4の下にある設定項目がとっても大事なようです。これは「ローカルポートとして利用できるアドレスの範囲」のことらしいです。自分の環境はCentOSなんですが、それだとデフォルトで32768から61000となっています。個しかローカルポートとして使えないようです。してみたら、28000件を超えていました。なっているじゃありませんか!つまりTIME_WAITのまま解放されない大量のコネクションがローカルポートを掴んでしまい、利用できるレンジのポート番号を食いつぶしていたようです。ポートのどれかが解放されるまで新しいコネクションを確立できなくなる、という状況に陥ってました。個別のローカルポートを使ってしまっていました。いうことで、まずはこのレンジを広げることにします。上限が61000となっているのを65000にしてみました。んん、微妙ぉぉ・・・焼け石に水っぽいな。いうことで、次策はtcp_tw_recycleです。これは非常に効果が大きかったです。tcp_tw_recycleはTIME_WAIT状態にあるコネクションを高速にリサイクルできるようにするためのフラグです。CentOSではデフォルトでは無効になっていたので、有効にします。ついでにtcp_fin_timeoutも変更しておきます。これはFIN_WAIT2の状態にあるコネクションの保有時間です。デフォルトでは60秒。あわせて/etc/sysctl.confの末尾にこれらを追記します。様子見・・・すると、見る見るうちにnetstatでのコネクション数が減っていき、最後には数百のレベルで落ち着きました。それと同時に、冒頭のmysqlエラー(99)はぴたっと止まったよ、ブラボー!まとめというわけで、大型トラヒックをさばくサーバを運用する場合、単にロードアベレージとかディスクIOばかりに気をとられてると、ネットワーク関係で思わぬ盲点があるよ、ということと、その対処策を知りました。最後に参考サイトを載せておきます。同じようなトラブルに見舞われた方は参考にしてみてください。==id:kdaibaさんからアドバイスもらったので追記しておきます。net.ipv4.tcp_tw_recycleを有効にすると、条件によっては、TCPセッションが脹れなくなるトラブルが発生することもありうる、とのこと。カーネル設定いじる前に以下のブログを読んで、よく理解しておいた方がよさそうです。http://d.hatena.ne.jp/nice20/20070521#p1http://d.hatena.ne.jp/nice20/20070517http://ya.maya.st/d/200804c.html台場先生、ありがとございました。AnyEvent::Workerを使ってみたperlで高速な類似検索エンジンを構築できるようにしてみた月別アーカイブはてなブログをはじめよう!download_takeshiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。