_ [PC][解析] WHR-G54Sルータ内にマジなサーバを立てるとき 注意事項 あやふやな知識ですから，鵜呑みにするのは推奨出来ません． ツッコミ歓迎． 結論（やるべきこと） ルータのNATは最低限に留める． NATしたポートには，「接続を受け入れる」「接続を拒否する」いずれかの応答を必ず行う． ファイアウォールのステルス機能によって「無応答」になることは避ける． クライアントに切断処理をさせる． 接続数が増えたと思ったら，ポートを閉じてしまう． Webサーバなら，同時接続数を制限したり，Keep-alive timeoutを延ばしたりする． ただし期待薄． はじめに P2P地震情報サーバを運営していますが，その追加機能であるPRCP情報共有プラグインの設計が大変悪く，結構本気で接続を仕掛けてきます．そのために，メンテナンス明けにはアクセスが集中し，ルータには決まって次のようなメッセー
今回はネットワーク周りのチューニングのお話。 ＷＥＢサーバにアクセスが集中した時、サーバを監視している時は一般的には以下の４点を見ていると思います。 CPU負荷 メモリ状況 ディスクIO コネクション状況 まぁ見ていたところでできることはかなり限られているのですが、次回の対策の目安になります。 とはいえ、前者３つについてはチューニングと言っても増設以外の処置の効果は薄いでしょう。 ただ、４つ目の「コネクション状況」については設定次第で劇的にパフォーマンスが上がったりします。 今回はそのあたりについて書いていきたいと思います。 ・基本的なTCP通信の話ここではコネクションのクローズのことだけ書きましょう。一般的にアプリケーションレベルでは通常コネクションをオープンした方からクローズの要求を発行します。しかし、TCPレベルの通信ではどちらからという決まりは無く、データを送り終わった
図5●プラットフォームの違いによる，コネクション確立の所要時間の差異<BR>TCPコネクションが確立するまでの時間を調べた。TUX 3.2はチューニング前後の数値にそれほど大きな違いはなく，比較的安定している。一方でApacheは標準設定時に扱えるプロセス/スレッド数が小さいため，Fedora Core 2.0とApache 2.0の組み合わせにおいてコネクション確立に要した最大時間が3009ミリ秒に達した。チューニングによって扱えるコネクション数を増やしたApacheでは，コネクション確立までの平均時間と最大時間が，いずれもTUX 3.2の性能をしのいでいる カーネル・モードで高速に動作するオープンソースのWebサーバー「TUX Web Server」（以下，TUX）の性能を，現在主流の「Apache」と比較した。静的コンテンツに大量のアクセスが集まる用途で，TUX 3.2はApache
コネクションがtime_waitステータスになってから実際に切断されるまでの時間はデフォルトでは60秒なので、それを短くするとコネクション保持に必要なCPUパワーを節約できるらしいです。 即効性があるのでLoad Averageを少しでも下げたい方は試す価値ありです。 参考記事 ・『TIME_WAITとMSL』 ・『http://itpro.nikkeibp.co.jp/article/COLUMN/20051115/224580/』 実際にテストしてみましたが、time_waitコネクションが118から0になりましたので、確かにtime_wait状態のコネクションを大幅に削減できました。 --------------------- [root@WWW1 ~]# netstat -a | wc -l 263 [root@WWW1 ~]# netstat -a | grep TIME_WAI
◎ TIME_WAIT MySQLで、TCPステータスがTIME_WAITのコネクションが増殖するため、かなり悩まされている。http://dev.mysql.com/doc/refman/5.1/ja/can-not-connect-to-server.htmlの問題。 TIME_WAITのタイムアウトを短く出来ないか、調べている。 TCPのコネクションの状態は、以下が詳しい http://www.atmarkit.co.jp/fwin2k/win2ktips/234netstat/netstat.html そこで、 http://itpro.nikkeibp.co.jp/article/COLUMN/20051115/224580/ を見ると、sysctlの net.ipv4.tcp_fin_timeout の値(デフォルト値60)がTIME_WAITのタイムアウト時間で、この値を小さ
異常にwebの表示が遅くなった時の原因が TIME_WAIT の大量発生だった。PHP だと生じやすいなぁ。CentOS 4.5 finall にて TIME_WAIT を短くするための方法。 状況 web と DB を別サーバでネットワーク経由のデータやりとりDB サーバ側は TIME_WAIT ほとんどなしweb(phpで作ったもの) にて TIME_WAIT 多めに残る それでも 150セッションくらいか 確認 # netstat -an | grep -i time_ (状況確認) # netstat -an | grep -i time_ | wc (行数として確認) 作業 # cd /proc/sys/net/ipv4/ # more tcp_tw_recycle 0 # echo '1' > tcp_tw_recycle特に再起動などいらず即反映される。重めなページを読み込ま
# 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_
2008年4月21日(月) ■ 無題 _ 今朝の電車でおっさんが読んでたスポーツ新聞からちょっと見えてた見出し。頭のおかしい人が新幹線で全裸になってタイーホ。春だなぁ。 _ 出社してからニュースサイトを巡回して、それが ファーストサーバの社長だったと知る。あぁ。 _ ち、ちがうよっ、春だから頭のおかしい人が湧いてきたんじゃないよっ。だってレンタルサーバ会社の社長だよ？ 頭がおかしいなんてことはないよ。最近のデータセンターは電力問題とか熱問題とかいろいろ大変だからね、きっと陽気がよくなってあったかくなったから熱暴走を起こして、その冷却のために大事なところを放熱してただけなんだよっ。 _ てか、ファーストサーバっていつのまにか yahoo の系列になってたのか。昔はクボタ(もちろん農業機械のクボタのことだ)の子会社だったよね、たしか。 2008年4月28日(月) ■ 無題 _ メール屋を廃業し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
