<div dir="ltr">Hi Maxim,<div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 17, 2013 at 4:42 AM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello!<br><div class="im"><br>
</div>On "these hosts"?  Note that listen queue aka backlog size is<br>
configured in _applications_ which call listen().  At a host level<br>
you may only configure somaxconn, which is maximum allowed listen<br>
queue size (but an application may still use anything lower, even<br>
just 1).<br></blockquote><div><br></div><div style>"These hosts" means we have a lot of servers in production right now, and they all exhibit the same issue. It hasn't been a showstopper, but it's been occurring for as long as anyone can remember. The total number of upstream servers on a typical day is 6 machines (each running 3 service processes), and hosts running nginx account for another 4 machines. All of these are Ubuntu 12.04 64-bit VMs running on AWS EC2 m3.xlarge instance types.</div>
<div style><br></div><div style>I was under the impression that /proc/sys/net/ipv4/tcp_max_syn_backlog was for configuring the maximum queue size on the host. It's set to 1024, here, and increasing the number doesn't change the frequency of the missed packets.</div>
<div style><br></div><div style>/proc/sys/net/core/somaxconn is set to 500,000<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Make sure to check actual listen queue sizes used on listen<br>
sockets involved.  On Linux (you are using Linux, right?) this<br>
should be possible with "ss -nlt" (or "netstat -nlt").</blockquote><div><br></div><div style>According to `ss -nlt`, send-q on these ports is set to 128. And recv-q on all ports is 0. I don't know what this means for recv-q, use default? And would default be 1024?</div>
<div style><br></div><div style>But according to `netstat -nlt` both queues are 0?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> > 2) Some other queue in the network stack is exhausted.  This<br>
> > might be nontrivial to track (but usually possible too).<br>
><br>
> This is interesting, and could very well be it! Do you have any<br>
> suggestions on where to start looking?<br>
<br>
</div>I'm not a Linux expert, but quick search suggests it should be<br>
possible with dropwatch, see e.g. here:<br>
<br>
<a href="http://prefetch.net/blog/index.php/2011/07/11/using-netstat-and-dropwatch-to-observe-packet-loss-on-linux-servers/" target="_blank">http://prefetch.net/blog/index.php/2011/07/11/using-netstat-and-dropwatch-to-observe-packet-loss-on-linux-servers/</a></blockquote>
<div><br></div><div style>Thanks for the tip! I'll take some time to explore this some more. And before anyone asks, I'm not using iptables or netfilter. That appears to be a common cause for TCP overhead when investigating similar issues.</div>
<div> </div><div style>Jay</div><div><br></div></div></div></div>