webサーバをチューニング
# sysctl -w net.ipv4.tcp_fin_timeout=30 # sysctl -w net.ipv4.tcp_tw_reuse=1 # sysctl -w net.ipv4.tcp_tw_recycle=0 ↑なんか勘違いしていた可能性があるので修正。現状では大きな問題は起きていないですが、tcp_tw_recycleはNATで問題が起きることがあるようなので最終手段です。 @2008/12/11追記 ↑tcp_tw_recycleを1にすると問題が多くて地雷祭りなので、基本0にしておきます。 @2010/10/29追記 いまさらですけど、tcp_fin_timeoutはtime_waitの数と関係ありません(60秒でハードコードされているとのこと)。tcp_fin_timeoutが関係あるのはFIN_WAIT_2の数で、FIN_WAIT_2が多い場合はtcp_fin_
kernel: TCP: time wait bucket table overflow の解消とTIME_WAITを減らすチューニング - 気ままにインフラエンジニア
整理がてら。 httpdが動いているあるホスト上で、 /var/log/messages に以下のようなメッセージが出ていた。 kernel: TCP: time wait bucket table overflow kernel: printk: 50078 messages suppressed. "netstat -tna |grep TIME_WAIT"すると、10万以上の数でTIME_WAITが出ている。これを解消するまでの流れ。 そもそもこの値は、カーネルパラメータの net.ipv4.tcp_max_tw_buckets で設定されている。デフォルトは16384。 （↑の通り、エラーが出た環境では既にかなり大きな値が設定されていたのだが。） /proc/sys/net/ipv4/tcp_max_tw_buckets システムが同時に保持する time-wait ソケットの最大
CLOSE_WAITのセッションを早く消す方法 - つれづれなる・・・
原因はおそらくwebサーバ〜DBサーバ間のセッションがネットワーク的に不安定だったからだと思うけど、DBサーバで netstat -an すると 大量の CLOSE_WAIT のセッションが残ってしまって、MySQL の最大コネクション数にまで達してしまってwebの表示が出来なかった。CLOSE_WAIT をいきなり消すことは出来ないので、早めに消えるようにしたいときは tcp_keepalive_time TCPセッションが確立されて検査が実施されるまでの時間 時間になると tcp_keepalive_intvl と tcp_keepalive_probes の値にしたがって検査を実施する tcp_keepalive_intvl 次の検査を実行するときの待ち時間 tcp_keepalive_probes 検査の回数のそれぞれの値を小さくしてあげればよい。変更方法は vi で :wq する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
