We deployed the latest and we saw throughput still dropped around peak hours a bit, then we swithed to nbproc 4 which is holding up ok. Note that 4 Cpus was not sufficient earlier, so I believe the latest version is scaling better.
Thanks Lukas and Willy. On 4/29/16, 11:09 AM, "Willy Tarreau" <w...@1wt.eu> wrote: >Hi guys, > >On Tue, Apr 26, 2016 at 08:46:37AM +0200, Lukas Tribus wrote: >> Hi Sachin, >> >> >> there is another fix Willy recently committed, its ff9c7e24fb [1] >> and its in the snapshots [2] since 1.6.4-20160426. >> >> This is supposed to fix the issue altogether. >> >> Please let us know if this works for you. > >Yes it should fix this. Please note that I've got one report in 1.5 of >some huge transfers (multi-GB) stalling after this patch, and since I >can't find any case where it could be wrong nor can I reproduce it, I >suspect we may have a bug somewhere else (at least in 1.5) that was >hidden by the bug this series of patches fix. We had no such report on >1.6 however. > >There's another case of high CPU usage which Cyril managed to isolate. >The issue has been present since 1.4 and is *very* hard to reproduce, >I even had to tweek some sysctls on my laptop to see it and am careful >not to reboot it. It is triggered by *some* pipelined requests. We're >currently working on fixing it, there are several ways to fix it but >all of them come with their downsides for now (one of them being a >different code path between 1.7 and 1.6/1.5/1.4 which doesn't appeal >me much). > >This is why I'm still waiting before issuing a new series of versions. > >In the mean time, feel free to test latest 1.6 snapshot and report any >issues you may face. I've really committed into getting these issues >fixed once for all, it's getting irritating to see such bugs surviving >but I never give up the fight :-) > >Best regards, >Willy >
