在haproxy – > node.js – > db的负载testing期间内核丢弃

我们正在对我们的游戏服务器堆栈进行负载testing,其中包括haproxy / ssl – > node.js(应用程序服务器) – >数据库

调用get然后node.js传递给db,然后将数据返回给客户端,在不同的testing中,我们看到很多奇怪的问题,我们无法追踪到。

运行tcpdump'tcp [13]&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

退出我们看到的命令

1662286filter收到的数据包由内核丢弃

我们的负载testing应用程序也将错误返回给我们..沿着这条线

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

任何想法从哪里开始..

服务器是一个调整到sysctl的Ubuntu 12.04服务器

net.netfilter.nf_conntrack_max = 262144

tcpdump错误是一个红色的haring(意思是他们没有关系到你的问题)。 TCPDump试图阻止影响系统性能的方式。 如果系统将得到tcpdump正在做的事情的备份,那么它将简单地丢弃数据包而不是检查它。 这并不意味着系统或networking堆栈正在丢弃数据包。 尝试添加“-n”开关到tcpdump。

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

除非安装了dnsmasq之类的cachingDNS服务器,否则nscd可能会被禁用。 这意味着对于tcpdump中的每个连接都会尝试执行反向dns查找。 我敢打赌,通过添加-n你的“丢包”消失。

你真正的问题听起来像你是压倒性的系统资源(cpu,内存等),或者你超过了haproxy中的短暂端口/最大连接。 conntrack + haproxy也是非常糟糕的performance。

  1. 禁用conntrack
  2. 在haproxy中检查你的最大连接configuration
  3. 看看haproxy统计页面(如果没有configuration,configuration它 – 这太棒了!)
  4. 启用haproxy日志logging。 我使用版本1.5.19运行一个非常大的haproxy实现。 近一年来,我们一直在使用1.5.x,没有任何问题。 我学到的一件事是haproxy日志logging总是100%可靠的。 有时我误解了日志条目,但总是准确的。 在这种情况下,您试图追踪连接问题,haproxy日志logging只会告诉您为什么失败。
  5. 检查haproxy进程的最大打开文件句柄。 去做这个

cat /proc/(haproxy PID)/limits

祝你好运。

PS。 启用统计页面,这是真棒! 另外,启用haproxy日志logging,这也是真棒! 在这两者之间,您将能够快速识别连接问题。