On Wed, Apr 25, 2018 at 12:20:57PM +0200, Willy Tarreau wrote: > On Wed, Apr 25, 2018 at 01:12:25PM +0300, Slawa Olhovchenkov wrote: > > My issuse don't originate in ordinary run time: if issuse don't exist > > now -- issuse don't exist in future until reload. > > Slawa, Olivier managed to reproduce something very similar to your > description on his box, and your observation makes sense. We now > understand who it happens (a race condition on startup when the DNS > resolution is enabled), and we're trying to find the best way to solve > it. We'll likely come with different fixes for 1.9 and 1.8, expect a > patch soon.
10x! > > PS: I am try to distribute frontend to cores and failed: > > > > global > > nbproc 1 > > nbthread 16 > > cpu-map auto:1/1-16 0-15 > > > > listen stats > > bind :9999 > > > > frontend balancer > > bind x.x.x.221:80 > > bind x.x.x.221:443 ssl crt xxxx > > bind-process 1/1-1/8 > > > > frontend tcp1 > > bind x.x.x.206:443 > > bind-process 1/9-1/16 > > mode tcp > > > > frontend tcp2 > > bind x.x.x.207:443 > > bind-process 1/9-1/16 > > mode tcp > > > > frontend tcp3 > > bind x.x.x.208:443 > > bind-process 1/9-1/16 > > mode tcp > > > > No addtional configuration in backends sections and I am not show backend > > configuration. > > > > 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? > We'll keep you updated. Thanks so much
