Hi Ok, I'll try to disable this option anyway to dig up more clues of this issue.
:-) -- Best Regards BaiYang baiy...@gmail.com http://baiy.cn **** < END OF EMAIL > **** From: Willy Tarreau Date: 2015-11-25 21:07 To: CyrilBonté CC: Lukas Tribus; haproxy; baiyang Subject: Re: CPU 100% when waiting for the client timeout On Wed, Nov 25, 2015 at 01:56:29PM +0100, Cyril Bonté wrote: > Hi all, > > ----- Mail original ----- > > De: "Willy Tarreau" <w...@1wt.eu> > > À: "baiyang" <baiy...@gmail.com> > > Cc: "Lukas Tribus" <luky...@hotmail.com>, "haproxy" <haproxy@formilux.org>, > > "Cyril Bonté" <cyril.bo...@free.fr> > > Envoyé: Mercredi 25 Novembre 2015 12:52:03 > > Objet: Re: Re: CPU 100% when waiting for the client timeout > > > > (...) > > > > Cyril, I would appreciate it if you could check whether your affected > > config also uses abort-on-close. > > I've just rechecked our configuration but no, we're not using "option > abortonclose", and we didn't in the past for those servers. OK thanks, that will help me get the more global figure. Given that the server and client timeout have not stroke in Baiyang's traces, and that the write expire delay is in the past for the request channel and the read expire delay as well for the response channel, I suspect that it's the server-fin timeout which has woken the task up here, and I even suspect that the loop continues for almost 15 minutes (till the client and/or server timeout strikes). I think I have enough elements to analyse this specific case and maybe we'll find a situation where it can happen without abortonclose. Cheers, Willy
