タグ

2014年5月8日のブックマーク (2件)

  • LinuxでTCP_DEFER_ACCEPTが有効でもaccept後readできない理由

    listen()のbacklogが不足した際のTCP_DEFER_ACCEPTの動作について - blog.nomadscafe.jpという記事の中で、listen backlog があふれた後に accept(2) すると、その後の read(2) が EAGAIN を返したり、接続が不安定になるという事象が説明されていました。気になったので調べてみたことをまとめます。 結論から言うとこれはLinuxの仕様です。manのtcp(7)を見ると、 TCP_DEFER_ACCEPT (since Linux 2.4) Allow a listener to be awakened only when data arrives on the socket. Takes an integer value (seconds), this can bound the maximum number of

    kazuhooku
    kazuhooku 2014/05/08
    これmanの記述古いんじゃないかな。以前調べたときは http://d.hatena.ne.jp/kazuhooku/20100327/1269682361 みたいな感じだった
  • listen()のbacklogが不足した際のTCP_DEFER_ACCEPTの動作について - blog.nomadscafe.jp

    TCP_DEFER_ACCEPTは、LinuxでサポートされているTCPのオプションで、サーバ側で使用した場合にはaccept(2)からのブロック解除をTCP接続が完了したタイミングではなく最初のデータが到着したタイミングで行ってくれるオプションです。 Webサーバ・アプリケーションサーバではリクエストが到着してからaccept(2)のブロックを解除するので、リクエストの到着をWebサーバ・アプリケーションサーバで待つ必要がなくなり、特にprefork型のサーバでは効率的にプロセスを使えるようになるという利点があります。PerlではStarletがこの機能を有効にしています ところが、某サービスでTCP_DEFER_ACCEPTが有効にも関わらず、accept後のreadでデータが読めず、最悪の場合、デフォルトのtimeoutである5分間プロセスがストールすることがありました。strace

    kazuhooku
    kazuhooku 2014/05/08
    ふむふむ。なんかLinuxのTCP_NODELAY実装のタイムアウトについてUbuntuあたりにプロキシとの絡みのissueがあった気がするけど思い出せない