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. > 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. We'll keep you updated. Willy
