【发布时间】:2026-02-16 10:30:01
【问题描述】:
我们已经在 Amazon EC2 中与 HAProxy 战斗了几天;到目前为止,体验非常好,但我们一直坚持从软件负载平衡器中挤出更多性能。我们并不完全是 Linux 网络专家(通常我们是一家 .NET 商店),但到目前为止,我们一直坚持自己的想法,尝试设置适当的 ulimit,检查内核消息和 tcpdump 是否存在任何违规行为。 到目前为止,我们已经达到了大约 1,700 个请求/秒的稳定期,此时客户端超时比比皆是(为此我们一直在使用和调整 httperf)。我和一位同事正在收听最新的 Stack Overflow 播客,其中 Reddit 的创始人注意到他们的整个网站都运行在一个 HAProxy 节点上,并且到目前为止还没有成为瓶颈。确认!要么以某种方式看不到那么多并发请求,要么我们做错了什么,要么 EC2 的共享特性限制了 Ec2 实例的网络堆栈(我们使用的是大型实例类型)。考虑到 Joel 和 Reddit 的创始人都同意网络可能是限制因素这一事实,这可能是我们看到的限制吗?
非常感谢任何想法!
编辑 看起来实际问题实际上与负载平衡器节点无关!在这种情况下,罪魁祸首实际上是运行 httperf 的节点。当 httperf 为每个请求构建和拆除一个套接字时,它会在内核中花费大量的 CPU 时间。当我们提高请求率时,TCP FIN TTL(默认为 60 秒)使套接字保持的时间过长,而 ip_local_port_range 的默认值对于这种使用场景来说太低了。基本上,在客户端(httperf)节点不断创建和销毁新套接字的几分钟后,未使用的端口数用完,随后的“请求”在此阶段出错,产生低请求/秒数和大量的错误。
我们也研究了 nginx,但我们一直在使用 RighScale,他们有用于 HAProxy 的插入式脚本。哦,我们的最后期限 [当然] 太紧了,除非证明绝对必要,否则无法更换组件。幸运的是,在 AWS 上,我们可以并行使用 nginx 测试另一个设置(如果有必要),并在稍后通宵进行切换。
This page 很好地描述了每个 sysctl 变量(在这种情况下调整了 ip_local_port_range 和 tcp_fin_timeout)。
【问题讨论】:
-
Marc,你应该写下你配置这些东西的经验,然后把它们贴在某个地方(你的公司有博客吗?)。听起来它可能对很多人有用。赞成您的问题。
-
您的链接已损坏。
-
@Ztyx 谢谢!刚刚更新了。我四处寻找更新、更新的资源,看起来原来的网站仍然有相当高的 PageRank,而且内容仍然不错,所以我只是更正它以反映新的 URL。跨度>
标签: amazon-ec2 load-balancing scaling haproxy