Hi Lukas,
Same with nbthread 1.
I gave my first try to git bisect and it looks like the offending commit is :
ab160a47acde9dc9c341b328c8716a721a389ab4 is the first bad commit
commit ab160a47acde9dc9c341b328c8716a721a389ab4
Author: Willy Tarreau <w...@1wt.eu>
Date: Thu Sep 5 17:38:40 2019 +0200
BUG/MINOR: checks: do not uselessly poll for reads before the connection is
up
It's pointless to start to perform a recv() call on a connection that is
not yet established. The only purpose used to be to subscribe but that
causes many extra syscalls when we know we can do it later.
This patch only attempts a read if the connection is established or if
there is no write planed, since we want to be certain to be called. And
in wake_srv_chk() we continue to attempt to read if the reader was not
subscribed, so as to perform the first read attempt. In case a first
result is provided, __event_srv_chk_r() will not do anything anyway so
this is totally harmless in this case.
This fix requires that commit "BUG/MINOR: checks: make __event_chk_srv_r()
report success before closing" is applied before, otherwise it will break
some checks (notably SSL) by doing them again after the connection is shut
down. This completes the fixes on the checks described in issue #253 by
roughly cutting the number of syscalls in half. It must be backported to
2.0.
(cherry picked from commit c5940392255e5a5a7eb0d27be62e155f1aec26c6)
Signed-off-by: Christopher Faulet <cfau...@haproxy.com>
:040000 040000 4cd93f8ab452b7092e56620c4a9f7672a3f9cd85
cc618d82eea0b8e421274410c61dc579a68cf7ce M src
--
Ionel GARDAIS
Tech'Advantage CIO - IT Team manager
----- Mail original -----
De: "Lukas Tribus" <li...@ltri.eu>
À: "Ionel GARDAIS" <ionel.gard...@tech-advantage.com>, "haproxy"
<haproxy@formilux.org>
Envoyé: Dimanche 15 Septembre 2019 20:37:09
Objet: Re: Issue with checks after 2.0.6
Hello,
On Sat, Sep 14, 2019 at 4:58 PM GARDAIS Ionel
<ionel.gard...@tech-advantage.com> wrote:
> > What was the previous release that worked for you? 2.0.5 or something older?
>
> 2.0.5 worked well from the checks point of vue.
Ok, so this is a regression in 2.0.6.
Please try whether limiting the threads to 1 (global section: nbthread
1) changes something for you.
Also I suggest you file a bug on github:
https://github.com/haproxy/haproxy/issues/new/choose
Lukas
--
232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON
Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
