QA@IT

Docomoサーバとの接続プロセスがウェブサーバに CLOSE_WAIT のステータスで残る

4016 PV
$netstat -tp

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name   
tcp        1      0 XXXXXXXXXXXXXXXXXXXXXX:http s1117227.xgsspn.imtp.:54021 CLOSE_WAIT  -
tcp        1      0 XXXXXXXXXXXXXXXXXXXXXX:http s1117227.xgsspn.imtp.:47115 CLOSE_WAIT  -
tcp        0      0 XXXXXXXXXXXXXXXXXXXXXX:http s1117227.xgsspn.imtp.:50955 CLOSE_WAIT  -
tcp        1      0 XXXXXXXXXXXXXXXXXXXXXX:http s1117227.xgsspn.imtp.:43272 CLOSE_WAIT  -
tcp        1      0 XXXXXXXXXXXXXXXXXXXXXX:http s1117227.xgsspn.imtp.:54024 CLOSE_WAIT  -
tcp      913      0 XXXXXXXXXXXXXXXXXXXXXX:http s1117227.xgsspn.imtp.:50953 CLOSE_WAIT  -
tcp        1      0 XXXXXXXXXXXXXXXXXXXXXX:http s1117227.xgsspn.imtp.:53769 CLOSE_WAIT  -
tcp        1      0 XXXXXXXXXXXXXXXXXXXXXX:http s1117227.xgsspn.imtp.:54793 CLOSE_WAIT  -
tcp        1      0 XXXXXXXXXXXXXXXXXXXXXX:http s1117227.xgsspn.imtp.:54031 CLOSE_WAIT  -
tcp        1      0 XXXXXXXXXXXXXXXXXXXXXX:http s1117227.xgsspn.imtp.:54029 CLOSE_WAIT  -
tcp        1      0 XXXXXXXXXXXXXXXXXXXXXX:http s1117227.xgsspn.imtp.:53517 CLOSE_WAIT  -
tcp        1      0 XXXXXXXXXXXXXXXXXXXXXX:http s1117227.xgsspn.imtp.:54034 CLOSE_WAIT  -
tcp        1      0 XXXXXXXXXXXXXXXXXXXXXX:http s1117227.xgsspn.imtp.:54035 CLOSE_WAIT  -
tcp        1      0 XXXXXXXXXXXXXXXXXXXXXX:http s1117227.xgsspn.imtp.:54032 CLOSE_WAIT  -

運営中のサービスに上記のようなプロセスが溜まって、ApacheのMaxClients値を超えてしまう現象が起こることがあります。当然ながらサービスは停止して、ウェブサーバ再起動により復旧しています。現象の直前にアクセスや負荷が高まった形跡は無く、単純にプロセスが終了しないことで新たなプロセスが待ち状態となるようです。

Foreign Address の文字列は下記だと予測しています。
s1117227.xgsspn.imtp.tachikawa.spmode.ne.jp

つまり、スマートフォンからDocomoのアクセスポイントを経由したアクセスがプロセスを握ったままタイムアウト待ちになっている、と判断していますが、なぜそれが起こるのか、他のサーバにも一般的に起こっていることなのかがわかりません。

何か同様の事象の経験や、分析のアイディアをお持ちではないでしょうか?

回答

あまり参考にはならないですが、

CLOSE_WAITは相手側はCLOSE済みでこちらからFINを送っていない状態ですよね。
なにか受信待ちになっている可能性もあります。(だからといってアプリケーションが原因とは言いきれませんが)

いろいろ見てましたが
Googleからのアクセスで同じような状態になった人もいるようです。
クローラといってますが、アクセスログはないので実際のアクセス元は何とも言えませんね。
http://oshiire.to/archives/1091

docomoのスマホで一般的に起こっているならもう少し報告されててもいいような気がしますが、検索にはあまり引っかかりませんでしたね。
一応ブログにdocomoのスマホからの(CLOSE_WAITとは関係なく)連続アクセスがあるというページを見かけましたが、ホスト名がすべて同じということはありませんでした。本当に全て s1117227.* からのアクセスであればマルウェアの影響というのもあるかもしれません。

余談ですが keep_aliveで対処する場合はretryの方も調整した方がいいと思います。

編集 履歴 (0)
  • >CLOSE_WAITは相手側はCLOSE済みでこちらからFINを送っていない状態ですよね。

    そうなんでしょうか?
    私の理解では、こちらか送ろうとしているACKを相手が受信できないため、FINを送って通信をCLOSEすることができない状態だと思いました。
    -
  • 認識が違ってたらすいませんがACKに対する確認応答はないので自分が切断出来る状態ならcloseに移ると思うんですが違いましたっけ。それともFINが来続けてるという事ですか? -

たしかデフォルトは2時間のこるから
/proc/sys/net/ipv4/tcp_keepalive_time の値を小さいものに変更するとかしてみては如何?
単位は秒だったはず。

編集 履歴 (0)
  • ご回答ありがとうございます。
    確かにその方法で潜在化させることができると思います。

    ただそれだと個人的にモヤモヤが残ってしまうので、
    原因特定へのアプローチを何か出来ないかと思っております。
    -
ウォッチ

この質問への回答やコメントをメールでお知らせします。