アプリ版:「スタンプのみでお礼する」機能のリリースについて

webベースのロールプレイングゲームを管理している者です。
昔から、夕方から深夜にかけてなどつながりにくい状況になっておりますが、いままでデータベースの負荷とかいろんな問題を解決して現在にいたっております。最近のつながりにくい原因を調査したところ、接続数がものすごく増えてしまっているのが原因らしいとわかりました。しかし、netstat で見てみると、実際に接続している時間はすぐ終わり、そのあとの TIME_WAIT の状態が長いようなのです。この状態では接続はすでに終わっているはずですが、これを早く終わらせるにはどうしたらいいのでしょうか?

A 回答 (4件)

net.ipv4.tcp_fin_timeoutとか


net.ipv4.tcp_tw_recycleとかを調べてみては?

参考URL:http://www.linux.or.jp/JF/JFdocs/Adv-Routing-HOW …

この回答への補足

お答えありがとうございます。

tcp_fin_timeout について調べてみました。
しかし、標準で60秒になっていますが、これを10秒とかあるいはもっと短くした時に、どういう困ったことが起こるのかが、私の調べた範囲では見つかりませんでした。

短くしても全く問題ないのなら60秒にしておく意味がないと思います。単に歴史的な理由でこうなっているだけならいいのですが、ハッカー対策などで意味のある設定ならうかつに変更できないと思います。もし、どなたかこれについてお分かりの方がいらっしゃれば、お教え願えないでしょうか?

補足日時:2006/06/13 17:34
    • good
    • 0

>しかし、標準で60秒になっていますが、これを10秒とかあるいはもっと短くした時に、どういう困ったことが起こるのかが、私の調べた範囲では見つかりませんでした。



これは、TCPの状態遷移あたりのkernel処理を理解しなければピンとこないのでは?
なので「調べてみては?」と書かせて頂きました。ここで説明なんて無理ですから。

すくなくともいじっている人達がいることは確かです。参考URLみたいに。

tcp_tw_recycleは、よく分かりません。昔とdefault値は変わったみたいですしね。

>短くしても全く問題ないのなら60秒にしておく意味がないと思います。
RFC793とか読まれた上で言っているんですよね?WAITは意味もなくWAITではないかと。

参考URL:http://itpro.nikkeibp.co.jp/article/COLUMN/20051 …

この回答への補足

私の#1の補足をよく、呼んでいただくとわかりますが、おそらく何らかの意味があるはずだ、という意味で質問しました。

参考URLを見させていただきます。

補足日時:2006/06/13 23:32
    • good
    • 0

>TIME_WAIT となったセッションを早く終了させる方法


に対してではないことをご容赦ください。

解決したいこと
>夕方から深夜にかけてなどつながりにくい状況
>接続数がものすごく増えてしまっている
だということでまったく違う点ですが確認されてみられてはいかかでしょうか。
同様の問題に悩まされました。

ルーターのMAXセッション数の最大に達すると空きが出るまでまたされます。
サーバーの設定に余裕があってもここがボトルネックになることがあります。
MAXセッション数の多いルーターに交換して解決しました。

少し余談ですが、WEBサーバーのTIME_WAITを変更してみたことあります。
しかし接続数はいっこうに減らない。
原因はクライアントのブラウザ上で、マウスを動かすと
サーバーにコネクションしにいきます。
ですからユーザーがページを開いて画面上でなにかしていればコネクションがきれることはありません。
TIME_WAITを短くしてもセッション数を減らす効果はまったくなかったのです。

ご参考までに

この回答への補足

お答えありがとうございます。

テスト用サーバーで実験してみました。sysctl.confをいじって
net.ipv4.tcp_fin_timeout = 5
として
sysctl -p
とやってみたのですが、確かにぜんぜん変化しませんでした。

> 原因はクライアントのブラウザ上で、マウスを動かすとサーバーにコネクションしにいきます。

私の環境では apache のログを見た限りではそういうことはありませんでした。そのページが単なる HTML ではないのではないでしょうか?

とにかく WIME_WAIT を小さくするというのは全く意味が無いことがわかりました。また、サーバーそのものの設定ではソケット数は1000や2000では全く問題ないようにも見えますので、おっしゃる通りルーターの問題かもしれません。いろいろ当たってみます。

補足日時:2006/06/15 12:49
    • good
    • 0

>とやってみたのですが、確かにぜんぜん変化しませんでした。



確かに変化しませんねぇ。TIME_WAITについては。。。
やはり、JFにあるようにあくまでFIN_WAIT_2に絡む設定のようですね。なので#2の参考サイトの内容は微妙ですね。すみません。

ざっとCentOS4.3のkernelソース眺めた感じだと
include/net/tcp.h

#define TCP_TIMEWAIT_LEN (60*HZ)
#define TCP_FIN_TIMEOUT TCP_TIMEWAIT_LEN
となっていて、約60がデフォルトのようです。で他のソースからも二つは使い分けられているようだったので
#define TCP_TIMEWAIT_LEN (15*HZ)
としてkernelリビルドして入れ替えたらTIME_WAITステータスは約15秒で破棄されました。当然標準のnet.ipv4.tcp_fin_timeoutも短くなってましたが。(ちなみにnet.ipv4.tcp_tw_recycleは標準のまま)

ご参考まで。
    • good
    • 1
この回答へのお礼

なるほど、kernelをりビルドすれば変わるのですか。
情報ありがとうございました。
他にも、TIME_WAITを合わせても 1000個ちょっとくらいしかないのにつながりにくいというのも納得できないところです。#3さんのおっしゃるように入り口に問題があるのかもしれません。

いずれにしろ、皆様からいただいた情報を元にして試行錯誤してっみることにいたします。

皆様、ありがとうございます。

お礼日時:2006/06/17 02:56

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!