<div dir="ltr">Hi again!<div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 17, 2013 at 2:17 AM, Jason Oster <span dir="ltr"><<a href="mailto:jay@kodewerx.org" target="_blank">jay@kodewerx.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hello Andrew,<div><br></div><div><div><div class="im"><div>On Mar 16, 2013, at 8:05 AM, Andrew Alexeev <<a href="mailto:andrew@nginx.com" target="_blank">andrew@nginx.com</a>> wrote:</div>
<blockquote type="cite"><div style="word-wrap:break-word">Jay,<br><div>
</div>
<div><div><br></div>You mean you keep seeing SYN-ACK loss through loopback?</div></div></blockquote><div><br></div></div><div>That appears to be the case, yes. I've captured packets with tcpdump, and load them into Wireshark for easier visualization. I can see a very clear gap where no packets are transmitting for over 500ms, then a burst of ~10 SYN packets. When I look at the TCP stream flow on these SYN bursts, it shows an initial SYN packet almost exactly 1 second earlier without a corresponding SYN-ACK. I'm taking the 1-second delay to be the RTO. I can provide some pieces of the tcpdump capture log on Monday, to help illustrate.</div>
</div></div></div></blockquote><div><br></div><div style>I double-checked, and the packet loss does *not* occur on loopback interface. It does occur when hitting the network with a machine's own external IP address, however. This is within Amazon's datacenter; the packets bounce through their firewall before returning to the VM.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="im"><blockquote type="cite"><div style="word-wrap:break-word">
<div><div>That might sound funny, but what's the OS and the overall environment of that strangely behaving machine with nginx? Is it a virtualized one? Is the other machine any different? The more details you can provide, the better :)</div>
</div></div></blockquote><div><br></div></div><div>It's a 64-bit Ubuntu 12.04 VM, running on an AWS m3.xlarge. Both VMs are configured the same.</div><div class="im"><br><blockquote type="cite"><div style="word-wrap:break-word">
<div><div>Can you try the same tests on the other machine, where you originally didn't have any problems with your application? That is, can you repeat nginx+app on the other machine and see if the above strange behavior persists?</div>
</div></div></blockquote><div><br></div></div><div>Same configuration. I'm investigating this issue because it is common across literally dozens of servers we have running in AWS. It occurs in all regions, and on all instance types. This "single server" test is the first time the software has been run with nginx load balancing to upstream processes on the same machine.</div>
</div></div></div></blockquote><div><br></div><div style>Here is some additional information in the form of screenshots from Wireshark!</div><div style><br></div><div style>10.245.2.254 is the VM's eth0 address. 50.112.82.196 is the VM's external IP, as assigned by Amazon. All of these packets are being routed through Amazon's firewall.</div>
<div style><br></div><div style>This first screenshot shows the "gap" that ends with a SYN burst. This was all captured during a single run of AB.</div></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">
<img src="cid:ii_13d7f66ca9302690" alt="Inline image 1" width="809" height="238"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra" style>The gap is about 500ms where the server is idle. :(</div><div class="gmail_extra" style>
<br></div><div class="gmail_extra" style>If I use "follow TCP stream" on the highlighted packet, I get this:</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style><img src="cid:ii_13d7f67dd1a4d1ec" alt="Inline image 2" width="809" height="373"><br>
</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>The initial SYN packet was sent almost exactly 1 second prior, and a SYN-ACK was not received for it.</div></div>