- ベストアンサー
TIME_WAIT となったセッションを早く終了させる方法はありませんか？
webベースのロールプレイングゲームを管理している者です。 昔から、夕方から深夜にかけてなどつながりにくい状況になっておりますが、いままでデータベースの負荷とかいろんな問題を解決して現在にいたっております。最近のつながりにくい原因を調査したところ、接続数がものすごく増えてしまっているのが原因らしいとわかりました。しかし、netstat で見てみると、実際に接続している時間はすぐ終わり、そのあとの TIME_WAIT の状態が長いようなのです。この状態では接続はすでに終わっているはずですが、これを早く終わらせるにはどうしたらいいのでしょうか？
- moritan2
- お礼率46% (320/681)
- Linux系OS
- 回答数4
- ありがとう数4
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
>とやってみたのですが、確かにぜんぜん変化しませんでした。 確かに変化しませんねぇ。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は標準のまま) ご参考まで。
その他の回答 (3)
- cocom32
- ベストアンサー率58% (75/129)
>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では全く問題ないようにも見えますので、おっしゃる通りルーターの問題かもしれません。いろいろ当たってみます。
- anights
- ベストアンサー率72% (35/48)
>しかし、標準で60秒になっていますが、これを10秒とかあるいはもっと短くした時に、どういう困ったことが起こるのかが、私の調べた範囲では見つかりませんでした。 これは、TCPの状態遷移あたりのkernel処理を理解しなければピンとこないのでは？ なので「調べてみては？」と書かせて頂きました。ここで説明なんて無理ですから。 すくなくともいじっている人達がいることは確かです。参考URLみたいに。 tcp_tw_recycleは、よく分かりません。昔とdefault値は変わったみたいですしね。 >短くしても全く問題ないのなら60秒にしておく意味がないと思います。 RFC793とか読まれた上で言っているんですよね？WAITは意味もなくWAITではないかと。
補足
私の#1の補足をよく、呼んでいただくとわかりますが、おそらく何らかの意味があるはずだ、という意味で質問しました。 参考URLを見させていただきます。
- anights
- ベストアンサー率72% (35/48)
net.ipv4.tcp_fin_timeoutとか net.ipv4.tcp_tw_recycleとかを調べてみては？
補足
お答えありがとうございます。 tcp_fin_timeout について調べてみました。 しかし、標準で60秒になっていますが、これを10秒とかあるいはもっと短くした時に、どういう困ったことが起こるのかが、私の調べた範囲では見つかりませんでした。 短くしても全く問題ないのなら60秒にしておく意味がないと思います。単に歴史的な理由でこうなっているだけならいいのですが、ハッカー対策などで意味のある設定ならうかつに変更できないと思います。もし、どなたかこれについてお分かりの方がいらっしゃれば、お教え願えないでしょうか？
関連するQ&A
- 【ソケット通信】TIME_WAITを0にする方法
【現状】 VC#でソケット通信のソフトを作成しています。 【問題】 クライアント―サーバ型のソケット通信をしようとしているのですが、切断後すぐに再接続できないという問題が生じております。 【調査結果】 調べたところ、TCP/IPの状態遷移でアクティブクローズ側がTIME_WAIT状態になることが分かっています。TIME_WAITの設定値には意味合いがあり、漂流中の重複パケットの問題を回避するためや最後のACK再送のためであることは理解しております。 【やりたいこと】 今回は基本的に1:1通信でルータを挟まずにやりとりするネットワークなので、TIME_WAITを0、もしくは数msecにしたいと考えています。 ※ 同じIPアドレス、ポート番号で接続したい為（ポート固定での再接続） 【自分で出した解決案の一つ】 どうもサーバ(Listenする側)からアクティブクローズすると、TIME_WAITは生じるもののクライアントから接続要求を出すと同じポートからでももう一度接続できてしまうというのは判明したので、必ずサーバから切断要求を出す仕様にすればTIME_WAITが0になるように思われます。 ただし、なぜ再接続できるのかは不明のため、すっきりしない（＆環境や設定が異なると再接続できない可能性あり） 【質問】 (1) クライアント側からアクティブクローズする場合に、TIME_WAIT状態を1秒未満に設定する方法はありますか？（VC＃で） (2) サーバからアクティブクローズした場合に、なぜ再接続できてしまうのでしょうか？ 以上の2点の質問に、どうかご回答のほどよろしくお願いいたします。
- 締切済み
- C・C++・C#
- 大量のTCPセッションについて
最近パソコンにてブラウザでのウェブ表示がいつまで経っても表示されないという事象が発生しております。パソコンを再起動した際に、表示されたり、同じ状況が繰り返されていたりします。そこで、netstat -n を確認してみたところ、大量の localhost間でのTCPセッションがはられており、TIME_WAITとなっていることがわかりました。 この事象が最近発生したものかは分からないのですが、表示できない問題に関係ありますでしょうか？ また、なぜ、localhost間で大量のTCPセッションを貼ろうとするのかお分かりの方がいらっしゃればおしえていただきたいと思います。 なお、Norton Internet Securityでは、ウィルス検知はしていません。 パソコンを起動しただけで、下記のセッションが張られている様です。 ＯＳはWindows8 Fujitsu LIFEBOOK AH45/J を使用しております。 TCP 127.0.0.1:53643 127.0.0.1:59201 TIME_WAIT TCP 127.0.0.1:53650 127.0.0.1:59201 TIME_WAIT TCP 127.0.0.1:53656 127.0.0.1:59201 TIME_WAIT TCP 127.0.0.1:53657 127.0.0.1:59201 TIME_WAIT ・ ・ TCP 127.0.0.1:53738 127.0.0.1:59201 TIME_WAIT TCP 127.0.0.1:53740 127.0.0.1:59201 TIME_WAIT TCP 127.0.0.1:53741 127.0.0.1:59201 TIME_WAIT
- 締切済み
- ネットトラブル
- netstatで接続先がいっぱい
Windows2000のコマンドプロンプトでnetstatを実行すると TCP ****:2437 ads.web.aol.com:http TIME_WAIT TCP ****:2438 ads.web.aol.com:http TIME_WAIT TCP ****:2439 ads.web.aol.com:http TIME_WAIT TCP ****:2440 ads.web.aol.com:http TIME_WAIT TCP ****:2441 ads.web.aol.com:http TIME_WAIT （****は私のPC名） というように、たくさんの接続（大体８個前後）が 次から次へと出現してきます。 ブラウザやICQ等、何も立ち上げていない状態でも 出てくるので気持ち悪いのですが、これで正常なんでしょうか？ ウィルスチェックもしていますが、特に検出されてません。 何かご存知の方おりましたら、よろしくお願いします。
- ベストアンサー
- ネットワーク
- TCPセッション状態「CLOSE_WAIT」につい
TCPセッション状態「CLOSE_WAIT」について質問です。 ■事象 WEBサーバを運営していて、 画像ファイルのアクセスが10リクエスト/1秒 程度あるのですが、 Apacheの「http://localhost/server-status?refresh=1」で状況を確認すると、 "W" Sending Replyがどんどん増加していき、 準備していた1024スレッドを全て使い果たしてしてサーバダウンとなる事象が発生しています。 サーバダウン時に「netstat -an」でTCPセッションを確認したのですが、 「CLOSE_WAIT」が大量に(950程度)残っていました。 TCP通信が完全に終了していないく、 不完全なTCP通信がプロセスを圧迫して、新しいリクエストを受け付けられない、 という状況です。 ちなみに、 画像ファイルのアクセスは他サイトからの直リンクになります。 他サイトに<img src="http://質問者のサイト.com/image.jpg">という直リンクがあり、 他サイトのPVが10アクセス/1秒あるということです。 ■環境 OS : Windows 7 64bit WEB : Apache/2.2.27 (Win64) PHP/5.4.26 ■質問 なぜ「CLOSE_WAIT」が大量に残ってしまうのか、理由を教えて下さい。 また、具体的な解決方法(オペレーション付きが望ましいです)を教えて下さい。 ■備考 ネットワーク機器が影響かと思い、別の製品にしたのですが、 解決せずでした。 サーバのKeepAlive系の設定かな？と思っています。
- 締切済み
- ネットワーク
- netstat が変です。
パソコンの挙動が不審なのでnetstatしました。 すると不審なアクセスが見えます。これはハイジャックされている状態ですか? C:\Users\user>netstat アクティブな接続 プロトコル ローカル アドレス 外部アドレス 状態 TCP 127.0.0.1:49260 www:49261 ESTABLISHED TCP 127.0.0.1:49261 www:49260 ESTABLISHED TCP 127.0.0.1:49872 www:21332 TIME_WAIT TCP 127.0.0.1:49873 www:21332 TIME_WAIT TCP 127.0.0.1:49874 www:21332 TIME_WAIT TCP 127.0.0.1:49875 www:21332 TIME_WAIT TCP 127.0.0.1:49876 www:21332 TIME_WAIT TCP 127.0.0.1:49877 www:21332 TIME_WAIT TCP 127.0.0.1:49878 www:21332 TIME_WAIT TCP 127.0.0.1:49879 www:21332 TIME_WAIT TCP 127.0.0.1:49880 www:21332 TIME_WAIT TCP 127.0.0.1:49881 www:21332 TIME_WAIT TCP 127.0.0.1:49882 www:21332 TIME_WAIT TCP 127.0.0.1:49883 www:21332 TIME_WAIT TCP 127.0.0.1:49884 www:21332 TIME_WAIT TCP 127.0.0.1:49885 www:21332 TIME_WAIT TCP 127.0.0.1:49886 www:21332 TIME_WAIT TCP 127.0.0.1:49887 www:21332 TIME_WAIT TCP 127.0.0.1:49889 www:21332 TIME_WAIT TCP 127.0.0.1:49890 www:21332 TIME_WAIT TCP 127.0.0.1:49891 www:21332 TIME_WAIT TCP 127.0.0.1:49892 www:21332 TIME_WAIT TCP 127.0.0.1:49893 www:21332 TIME_WAIT TCP 127.0.0.1:49894 www:21332 TIME_WAIT TCP 127.0.0.1:49898 www:21332 TIME_WAIT TCP 192.168.11.3:49168 17.167.137.42:https CLOSE_WAIT TCP 192.168.11.3:49175 17.167.137.39:https CLOSE_WAIT TCP 192.168.11.3:49282 ec2-54-214-248-72:http ESTABLISHED TCP 192.168.11.3:49780 tf-in-f95:http TIME_WAIT TCP 192.168.11.3:49781 nrt19s02-in-f16:http TIME_WAIT TCP 192.168.11.3:49802 210.158.146.137:http TIME_WAIT TCP 192.168.11.3:49803 210.158.146.137:http TIME_WAIT TCP 192.168.11.3:49804 210.158.146.137:http TIME_WAIT TCP 192.168.11.3:49805 210.158.146.137:http TIME_WAIT TCP 192.168.11.3:49806 210.158.146.137:http TIME_WAIT TCP 192.168.11.3:49829 74.125.203.157:http TIME_WAIT TCP 192.168.11.3:49839 nrt19s12-in-f6:http TIME_WAIT TCP 192.168.11.3:49844 nrt04s08-in-f2:http TIME_WAIT TCP 192.168.11.3:49895 tf-in-f84:https ESTABLISHED TCP 192.168.11.3:49896 nrt19s02-in-f15:https ESTABLISHED TCP 192.168.11.3:49897 nrt19s01-in-f14:https ESTABLISHED あまりにwwwとか怖いので、hostsに 127.0,.0.1 www としてみたり、ファイアーウォールの設定のin-bound,out-boundの設定に49000-49999でブロックとしたのですが、netstat -naoで見ると49000番台にアクセスしているアプリケーションのpidがsystem32のsvchost.exeらしく、このアプリケーションの設定では任意のポートがオープンになっているようで、ブロックされていないようです。 システムファイルが書き換えられているのか? と思い、sfc.exe /scannow として復旧してみたのですが変わりませんでした。 どうしたらこの危険な?? 状態 を普通に近い状態に直せるのでしょうか。 アドバイスを下さい。 よろしくお願いいたします
- ベストアンサー
- ネットワーク
- Windowsログイン後にnetstat -n を実行すると・・・
Windowsログイン直後にコマンドプロンプトを立ち上げて netstat -n を実行すると インターネットエクスプローラーを開いていないのに ------------------------------------- C:\>netstat -n Active Connections Proto Local Address Foreign Address State TCP 192.168.1.2:1027 211.10.xxx.xxx:80 TIME_WAIT TCP 192.168.1.2:1036 210.148.xxx.xxx:80 TIME_WAIT ------------------------------------- とインタネットエクスプローラーを使用している時と 同じ表示になります。 これはなぜでしょうか？ ちなみにWeb閲覧してすぐ再起動して netstat -n を実行したときに上記の接続が確認されます。 セキュリティソフト Norton InterNetSecurity2005
- 締切済み
- Windows XP
- 同じ環境から一回のアクセスにより多数の通信状況が開かれる
サイト担当の前任者がいなく、資料も残されていない状態で、下記の問題に遭遇しました。お知恵を貸していただきたいです。 Linux8 + Apache2 + PHP4.3.1 + MySQL3 で構築されたWebサイトがあります。 毎日午後になるとサーバのパフォーマンスが落ち、困っています。 netstatで確認すると、同じ環境から一回のアクセスにより多数の通信状況が開かれていることが分かりました： tcp 0 0 xxx.xxx.234.204:80 xxx.xxx.115.93:62191 TIME_WAIT tcp 0 0 xxx.xxx.234.204:80 xxx.xxx.115.93:63471 TIME_WAIT tcp 0 0 xxx.xxx.234.204:80 xxx.xxx.115.93:63724 TIME_WAIT ・・・ ・・・ これは、パフォーマンスを低下させる原因でしょうか。もしそうでしたら、PHPのコードの書き方に問題があるのでしょうか？ お手数ですが、教えていただければ幸いです。 どうぞ、よろしくお願いいたします。
- ベストアンサー
- PHP
- NTで、「netstat」？？？
分からない事があるので、質問させて頂きます。 現在、システムに障害が発生し調査をしています。 システムの環境構成は以下の通りです。 ■WEBサーバ OS ：Solaris2.6 WEBサーバ：iPlanet EnterpriseWebServer4.1 ■DBサーバ OS ：WindowsNT Server 4.0 DBサーバ：Oracle WorkgroupServer8.0.6 WEBとDB間には、firewallがあります。 そこで、原因調査の為にWEB側で、「netstat」コマンドを使って 通信の状態を調べてくれと言われて、調べました。 そして、その後、更なる調査の為にDB側で「netstat」の結果が必要 と言われたのですが、NTで「netstat」コマンドなんて、使えませんよね？？ なんか、NTで通信の状態を調べる方法って、あるのでしょうか？？ （DBサーバ側のnetstatが必要と言う意味が理解できず＾＾;;） ＃どなたか、アドバイスよろしくお願い致します。
- ベストアンサー
- Windows NT・2000
- netstat、netstat -a のState
netstat オプションなしと、netstat -a の表示されるStateの種類の違いについて教えてください（Linux) # netstat # netstat -a を実行したときに表示されるStateの種類の違いは、オプションなしは下記StateのLISTEN以外が表示対象で、-a オプション指定時は下記Stateの全てが表示対象である認識で間違っていないでしょうか。 State ESTABLISHED ソケットは確立した接続状態にある。 SYN_SENT ソケットは接続を確立しようと試みている。 SYN_RECV 接続要求をネットワークから受信している。 FIN_WAIT1 ソケットはクローズされており、接続は切断中である。 FIN_WAIT2 接続はクローズされ、ソケットはリモート側からの切断を待っている。 TIME_WAIT ソケットは、クローズ後にリモートからの切断が再送されるのを待っている。 CLOSED ソケットは使用されていない。 CLOSE_WAIT リモート側は既に切断され、ソケットがクローズされるのを待っている。 LAST_ACK リモート側は既に切断され、ソケットもクローズされている。 確認 (acknowledgement) を待っている。 LISTEN ソケットは接続待ち (listen) である。 このようなソケットは、 --listening (-l) または --all (-a) オプションを指定しない限り、出力には含まれない。 CLOSING 両方のソケットが切断されているが、まだ全てのデータが送られていない。 UNKNOWN ソケットの状態は不明である。
- ベストアンサー
- ネットワーク
- オプションなしnetstatのStateについて
netstat オプションなしと、netstat -a の表示されるStateの種類の違いについて教えてください。 # netstat # netstat -a を実行したときに表示されるStateの種類の違いは、オプションなしは下記StateのLISTEN以外が表示対象で、-a オプション指定時は下記Stateの全てが表示対象である認識でいます。 では、netstat オプションなしで実行した場合、LISTEN以外が表示であることを裏付けるには、ソースを追うしかないでしょうか？ netstat オプションなしで実行した場合、LISTEN以外が表示であることを裏付ける方法について教えてください。 State ESTABLISHED ソケットは確立した接続状態にある。 SYN_SENT ソケットは接続を確立しようと試みている。 SYN_RECV 接続要求をネットワークから受信している。 FIN_WAIT1 ソケットはクローズされており、接続は切断中である。 FIN_WAIT2 接続はクローズされ、ソケットはリモート側からの切断を待っている。 TIME_WAIT ソケットは、クローズ後にリモートからの切断が再送されるのを待っている。 CLOSED ソケットは使用されていない。 CLOSE_WAIT リモート側は既に切断され、ソケットがクローズされるのを待っている。 LAST_ACK リモート側は既に切断され、ソケットもクローズされている。 確認 (acknowledgement) を待っている。 LISTEN ソケットは接続待ち (listen) である。 このようなソケットは、 --listening (-l) または --all (-a) オプションを指定しない限り、出力には含まれない。 CLOSING 両方のソケットが切断されているが、まだ全てのデータが送られていない。 UNKNOWN ソケットの状態は不明である。
- ベストアンサー
- Linux系OS
お礼
なるほど、kernelをりビルドすれば変わるのですか。 情報ありがとうございました。 他にも、TIME_WAITを合わせても 1000個ちょっとくらいしかないのにつながりにくいというのも納得できないところです。#3さんのおっしゃるように入り口に問題があるのかもしれません。 いずれにしろ、皆様からいただいた情報を元にして試行錯誤してっみることにいたします。 皆様、ありがとうございます。