On Wed, Apr 25, 2018 at 03:49:09PM +0200, Willy Tarreau wrote: > On Wed, Apr 25, 2018 at 04:24:42PM +0300, Slawa Olhovchenkov wrote: > > > > TCP load rise CPU use on all core (0-15), I am expect rise CPU use > > > > only on 8-15 core. What I am miss? > > > > > > It's unrelated to the frontend's bindings but to the way the socket's fd > > > is registered with pollers, which is why you still have the problem here. > > > We're still surprized it doesn't happen with other pollers, which is why > > > we need to dig deeper as it could cover another issue. > > > > Pollers distinct from frontend? > > Can I bind pollers to CPU? > > Each thread has its own poller. Since you map threads to CPUs you indeed > have one poller per CPU.
Each pooler pool all sockets or only sockets from binded frontends? > > > We'll keep you updated. > > > > Thanks so much > > Please try this patch. It works for me. I finally managed to reproduce > the issue even with epoll(), it's just that it's much harder to see it, > but after trying multiple times eventually you see it as well. Under > poll() however the issue occasionally happens and disappears by itself. Like work for me too, thank > Olivier found that we have a race condition in the way we update FDs that > are polled by multiple pollers. This is a side effect of the per-thread > poller change that we had to do recently to fix other issues. The good > news is that in 1.8, only listeners should be present on multiple threads > so it is not dramatic. The DNS has no reason for being present anywhere > but on the thread that creates the outgoing connection. It's what this > patches does. However now we have a painful job of trying to address > the listener case, as I think there are definitely races there that are > quite hard to reach but we don't want to leave them. > > Willy > > diff --git a/src/dns.c b/src/dns.c > index b1fac10..d3b2c10 100644 > --- a/src/dns.c > +++ b/src/dns.c > @@ -195,7 +195,7 @@ static int dns_connect_namesaver(struct dns_nameserver > *ns) > dgram->t.sock.fd = fd; > fdtab[fd].owner = dgram; > fdtab[fd].iocb = dgram_fd_handler; > - fd_insert(fd, (unsigned long)-1); > + fd_insert(fd, tid_bit); > fd_want_recv(fd); > return 0; > }
