Thanks, will do that. On Thu, Oct 11, 2018 at 8:37 AM Willy Tarreau <[email protected]> wrote:
> On Thu, Oct 11, 2018 at 08:18:21AM +0530, Krishna Kumar (Engineering) > wrote: > > Hi Willy, > > > > Thank you very much for the in-depth analysis and configuration setting > > suggestions. > > I believe I have got the 3 key items to continue based on your mail: > > > > 1. Thread pinning > > 2. Fix system irq pinning accordingly > > 3. Listen on all threads. > > > > I will post the configuration changes and the results. > > By the way, please pull the latest master fixes. I've addressed two issues > there with locking : > - one where the scheduler work was slightly too high, increasing the time > spent on RQ lock > - another one where I messed up on a fix, causing lock-free pools to be > disabled (as seen in your output, where the POOL lock appears a lot) > > On some tests I've run here, I've found the stick-tables lock to be a > bottleneck when tracking is enabled. I don't have a short-term solution > to this, but looking at the code it's obvious that it can significantly > be improved (though it will take quite some time). I'll probably at least > try to replace it with an RW lock as I think it could improve the > situation. > > The FD lock is another one requiring some lift-up. I'm certain it's > possible, > I just don't know if it will not degrade low-thread count performance by > using too many atomic ops instead. We'll have to experiment. > > Cheers, > Willy >
