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" <firstname.lastname@example.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