<div dir="ltr">Ok,<div><br></div><div>I have found it to be a configuration bug. With a fresh configuration (default configuration from package, with reuseport added) and reuseport enabled the feature works (same 3.18 kernel, same nginx binary).</div><div><br></div><div>Now I just need to identify which line of our production configuration creates this bug.</div><div><br></div><div>I will update when I know more.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 25, 2015 at 12:42 AM, Valentin V. Bartenev <span dir="ltr"><<a href="mailto:vbart@nginx.com" target="_blank">vbart@nginx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wednesday 25 November 2015 00:25:19 SplitIce wrote:<br>
> Hi all,<br>
><br>
> I couldn't find anything in the mailing list about this issue, surely we<br>
> are not the only one?<br>
><br>
> When activating reuseport I am seeing all requests be served from a single<br>
> nginx process. All others are just idling (SIGALARM interruption of<br>
> epoll_wait / epoll_wait timeout according to strace).<br>
><br>
> Process 442 attached - interrupt to quit<br>
> epoll_wait(60, 8225010, 512, 4294967295) = -1 EINTR (Interrupted system<br>
> call)<br>
> --- SIGALRM (Alarm clock) @ 0 (0) ---<br>
> rt_sigreturn(0xe)                       = -1 EINTR (Interrupted system call)<br>
> epoll_wait(60, 8225010, 512, 4294967295) = -1 EINTR (Interrupted system<br>
> call)<br>
> --- SIGALRM (Alarm clock) @ 0 (0) ---<br>
><br>
><br>
><br>
> This only occurs with reuseport, as soon as it is disabled the load is<br>
> correctly distributed again.<br>
><br>
> Configuration:<br>
> worker_processes 12; # 2x8 cores on server<br>
> multiple server blocks on different IP's and ports with reuseaddr.<br>
> Linux kernel: 3.18.20<br>
><br>
> Server nic has interrupts over all cores:<br>
><br>
> # sudo ethtool -S eth0 |grep rx | grep pack<br>
>      rx_packets: 11244443305<br>
>      rx_queue_0_packets: 1381842455<br>
>      rx_queue_1_packets: 1373383493<br>
>      rx_queue_2_packets: 1490287703<br>
>      rx_queue_3_packets: 1440591930<br>
>      rx_queue_4_packets: 1378550073<br>
>      rx_queue_5_packets: 1373473609<br>
>      rx_queue_6_packets: 1437806438<br>
><br>
><br>
> We have also experimented with disabling iptables and anything else on the<br>
> server that could be interfering. I have also loaded it onto three other<br>
> fresh servers with the same kernel (same OS image), but with different nic<br>
> cards (with and without multiple rx queues) with no changes.<br>
><br>
> This has me stumped. Ideas?<br>
><br>
<br>
</div></div>You should try another kernel.<br>
<br>
  wbr, Valentin V. Bartenev<br>
<br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</blockquote></div><br></div>