From: Willy Tarreau Date: Wed, 1 Jul 2020 16:30:16 +0000 (+0200) Subject: DOC: configuration: fix alphabetical ordering for tune.pool-{high,low}-fd-ratio X-Git-Tag: v2.1.8~49 X-Git-Url: http://git.haproxy.org/?a=commitdiff_plain;h=22114dc13a3cb16aaae320c2b2be224cdaf5e721;p=haproxy-2.1.git DOC: configuration: fix alphabetical ordering for tune.pool-{high,low}-fd-ratio In addition they were in the wrong alphabetical order in the doc. They were added in 2.0 by commit 88698d966 ("MEDIUM: connections: Add a way to control the number of idling connections.") so this must be backported to 2.0. (cherry picked from commit 83ca305ddc2222ec269e18a9df6d519ed0f08ae8) Signed-off-by: Christopher Faulet --- diff --git a/doc/configuration.txt b/doc/configuration.txt index 6295359..d2e7f3e 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -1909,12 +1909,6 @@ tune.pipesize performed. This has an impact on the kernel's memory footprint, so this must not be changed if impacts are not understood. -tune.pool-low-fd-ratio - This setting sets the max number of file descriptors (in percentage) used by - haproxy globally against the maximum number of file descriptors haproxy can - use before we stop putting connection into the idle pool for reuse. The - default is 20. - tune.pool-high-fd-ratio This setting sets the max number of file descriptors (in percentage) used by haproxy globally against the maximum number of file descriptors haproxy can @@ -1924,6 +1918,12 @@ tune.pool-high-fd-ratio keep an idle connection behind, anything beyond this probably doesn't make much sense in the general case when targeting connection reuse). +tune.pool-low-fd-ratio + This setting sets the max number of file descriptors (in percentage) used by + haproxy globally against the maximum number of file descriptors haproxy can + use before we stop putting connection into the idle pool for reuse. The + default is 20. + tune.rcvbuf.client tune.rcvbuf.server Forces the kernel socket receive buffer size on the client or the server side