Question

我们正在加载测试我们的游戏服务器堆栈，其中包含haproxy / ssl - ＆gt; node.js（app servers） - ＆gt;数据库

调用是获取然后node.js传递给db然后将数据返回给客户端，在各种测试期间我们看到各种奇怪的问题，我们似乎无法追查。

运行tcpdump'tcp [13]＆amp; 4！= 0'| grep http-alt

我们在日志中看到了各种各样的事情：

23:35:16.049886 IP xx > xx.http-alt: Flags [R], seq 2946709660, win 0, length 0 23:35:16.668370 IP xx.62737 > xx.http-alt: Flags [R.], seq 4204676699, ack 3037703652, win 68, options [nop,nop,TS val 153103530 ecr 133109021], length 0 23:36:06.030500 IP xx.40290 > xx.http-alt: Flags [R.], seq 431162404, ack 2610577956, win 68, options [nop,nop,TS val 153115871 ecr 133121361], length 0

退出我们看到的命令

过滤器收到1662286个数据包内核丢弃了9个数据包

我们的负载测试应用程序也会将错误返回给我们..这就是

T000023 --- loop started --- 19 Aug 2013 18:09:07.975 ---r" T000023r" T000023 <<< user_id = nullr" T000023 <<< ext_userid = nullr" T000023 <<< Public_token_put = nullr" T000023 <<< Private_token_prt = nullr" T000023 >>> execute plug-in #1: GenerateRandomCharactersr" T000023r" T000023r" T000023 # Page #1: Registrationr" T000023 # ---------------------r" T000023r" T000023 [1] GET https://someurl.com:2222/?method=somemethod&type=reg=somerandomid ...r" T000023 -8 (Network Connection aborted by Server), [No Content Type], --- bytes, --- ms, * Failed at 'Open Network Connection', java.net.SocketException: Connection resetr" T000023 error: expected HTTP status: 200 <> received: -8 (Network Connection aborted by Server), [No Content Type], --- bytes, --- ms, ** Failed at 'Open Network Connection', java.net.SocketException: Connection resetr

关于从哪里开始的任何想法..

服务器是ubuntu 12.04服务器，只有一个调整到sysctl

net.netfilter.nf_conntrack_max = 262144

Answer 1

tcpdump错误是红色的（这意味着它们与您的问题无关）。 TCPDump试图避免影响系统性能。如果系统会为tcpdump正在做的事情进行备份，那么它只会丢弃数据包而不是检查数据包。这并不意味着系统或网络堆栈正在丢弃数据包。尝试将“-n”开关添加到tcpdump。

-n     Don't convert addresses (i.e.,  host  addresses,  port  numbers, etc.) to names.

除非您安装了dnsmasq等缓存DNS服务器，否则很可能禁用了nscd。这意味着对于tcpdump中的每个连接都将尝试执行反向dns查找。我打赌通过添加-n你的“丢弃的数据包”就会消失。

你真正的问题听起来像你要么压倒系统资源（cpu，内存等），要么你超过你在haproxy的短暂端口/最大连接。此外，有充分证据证明conntrack + haproxy是一种可怕的表现。

禁用conntrack
检查haproxy
查看haproxy stats页面（如果没有配置，请配置它 - 它真棒！）
启用haproxy日志记录。我使用1.5.19版本运行了一个非常大的haproxy实现。我们已经使用1.5.x近一年了，没有任何问题。我学到的一件事是haproxy日志始终是100％可靠的。有时我误解了日志条目，但它总是准确的。在您尝试追踪连接问题的情况下，haproxy日志记录将简单地告诉您失败的原因。
检查haproxy进程的最大打开文件句柄。要做到这一点

cat /proc/(haproxy PID)/limits

PS。启用统计页面，真棒！另外，启用haproxy日志记录，它也很棒！在这两者之间，您将能够非常快速地识别连接问题。

在haproxy的负载测试期间由内核丢弃的数据包 - ＆gt; node.js - ＆gt; D b

1 个答案: