以下の状況に置いて、クライアントからのリクエスデータがサーバ側のTCPバッファーに詰ま る。TCPバッファーが一杯になると、パケットがdropされるのでクライアントからのデータ再 送が発生する。

• CPU高負荷時、Acceptorスレッドが回らない状況
• GCによって、Acceptorスレッドの働きが良くない状況
• CPU高負荷時、ワーカスレッドがリクエストデータ受信処理で止まっている
• GCによって、ワーカスレッドがリクエストデータ受信処理で止まっている

また、Acceptorスレッドが止まる場合新規接続(3WHS完了)がbacklogキューに溜まるので backlogキューが溢れる可能性もあります。

上記に関して、Threadサブシステム利用時も同様です。

TCPバッファーがについて、TCP接続単位にTCPバッファーが持っている、デフォルト値は net.ipv4.tcp_rmem カーネルパラメータ値の1/2になります、約42KB。

CPU高負荷でAcceptorスレッドが止まってかつbacklogキューが溢れた場合、コネクションの確立 ができない、クライアントからのsyn(1)やack(3)の再送が起きる。 TCP SYNの再送間隔は以下の通り、約64秒でタイムアウトになる。

1回目 +1秒
2回目 +2秒
3回目 +4秒
4回目 +8秒
5回目 +16秒
6回目 +32秒  タイムアウト

クライアントからすると応答が激遅いと感じることがある。

※上記に関して、Threadサブシステム利用時も同様です。

同時接続数がmax-connections値を超えた場合、Acceptorスレッドが新規コネクションを受付し、 その後のワーカースレッド割り当て処理でワーカースレッドがないことを気付き、ソケットをク ローズする(FINパケットを送出)。

注意： このケースに置いて必ずじもCPU高負荷とは限らない、ワーカスレッドがアプリに掴み放しの場 合も起こりえる。