はじめに
HAProxy の最大接続するを指定するパラメータに maxconn というパラメータが指定出来ますが、この maxconn を超えた数の接続が発生した場合にどのような挙動になるのかをググりまくって grep しまくって調べてみました。間違い等あればツッコミお願い致します!
そもそも maxconn って?
The “maxconn” parameter specifies the maximal number of concurrent connections that will be sent to this server.
とあるので「HAProxy サーバーへの同時接続の最大数」となります。
maxconn を超えた場合の挙動
では、この maxconn を超えたアクセスがあった場合には HAProxy はどのような挙動となるのでしょうか?
ライバル?の Apache の場合
maxconn と同義だと思われる MaxClient ディレクティブで設定されたパラメータを超えた場合の挙動は以下の通りです。
- ListenBacklog ディレクティブで設定した数までキューイングされる
- 他のリクエストの最後まで達して子プロセスが空くと次のコネクションに応答
という挙動のようです。ちなみに MaxClient は「リクエストに応答するために作成される子プロセスの最大個数(応答することのできる同時リクエスト数(クライアントに応答できるスレッドの総数))」となります。
ほんでもって HAProxy の場合には…
If the number of incoming concurrent requests goes higher than this value, they will be queued, waiting for a connection to be released.
上記を読むと…
- maxconn を超えた場合のアクセスはキューに入る
- さらに timeout queue パラメータに設定した時間が超過した場合には順次 503 エラーを返す
1 を読むと Apache と同じような動きを見せるように読み取れます。また、2 の timeout queue は Apache の ListenBacklog と同じような機能があると読み取れます。尚、timeout queue を指定しない場合には timeout connect と同値が利用されるとのことです。
ここで疑問…(Listen Queue)
Apache でも HAProxy でも queue にキューイングされるという点… queue ってなんやねんって思ってググっていたら以下のような記事に辿り着いた次第です。
- Connections waiting in the listen queue dropped during haproxy restart?
- How to play with maxconn to avoid server slowness or crash
- Listenキューについて
- LISTEN(2)
上記の記事や man ページ、HAProxy のソースコードを斜め読みした場合には以下のように読み取れました。
- maxconn や MaxClient を超えた数のアクセスはカーネルの Listen Queue にキューイングされる
- キューイングされる量は backlog という引数の値で定義する
さらに疑問…(HAProxy には backlog を定義出来ないの?)
出来ます…。backlog パラメータがありました…orz。
In order to protect against SYN flood attacks, one solution is to increase
the system’s SYN backlog size. Depending on the system, sometimes it is just
tunable via a system parameter, sometimes it is not adjustable at all, and
sometimes the system relies on hints given by the application at the time of
the listen() syscall. By default, HAProxy passes the frontend’s maxconn value
to the listen() syscall. On systems which can make use of this value, it can
sometimes be useful to be able to specify a different value, hence this
backlog parameter.
ドキュメントの抜粋ですが、以下のように書かれています。
- SYN flood からの攻撃から防御する為には SYN backlog サイズを大きくする
- 但しシステム(OS)によっては SYN backlog サイズの調整は難しいことがある
- システムパラメータを経由して指定が可能でアプリケーションによって与えられた引数によって指定可能
- HAProxy は maxconn の設定を listen() に渡している(ということは maxconn が設定されていれば backlog パラメータは設定する必要がない)
さらに…
On Linux 2.4, the parameter is ignored by the system. On Linux 2.6, it is
used as a hint and the system accepts up to the smallest greater power of
two, and never more than some limits (usually 32768).
とあり Linux 2.4 ではこの backlog パラメータは無視されるようです。
ということで…
HAProxy の maxconn を超えた際の挙動は下記の通りかと思われます。
- 接続をいきなり破棄はしない
- OS の Listen Queue にキューイングされる
- timeout queue に指定した時間を超えたキューは破棄されクライアントに 503 エラーを返す
- maxconn パラメータは OS の listen() システムコールの backlog 引数に渡される
- OS レベルで調整する場合には /proc/sys/net/ipv4/tcp_max_syn_backlog を設定する
元記事は、こちら