Nginx 作为负载均衡器的瓶颈？答案

【问题标题】：Nginx bottleneck as load balancer?Nginx 作为负载均衡器的瓶颈？
【发布时间】：2012-11-10 14:44:26
【问题描述】：

我们有一个流行的 iPhone 应用程序，人们可以在其中像 Wordfeud 一样互相决斗。我们今天有近 100 万注册用户。

在高峰时段，应用程序的响应时间非常长，而且超时时间也非常多。我们试图找到瓶颈，但很难做到。所有服务器上的 CPU、内存和 I/O 都低于 50%。该问题仅在高峰时段出现。

我们的设置

1 VPS with nginx (1.1.9) as load balancer
4 front servers with Ruby (1.9.3p194) on Rails (3.2.5) / Unicorn (4.3.1)
1 database server with PostgreSQL 9.1.5

数据库日志没有显示足够长的请求时间来解释 nginx 错误日志中显示的所有超时。

我们还尝试直接在前端服务器上构建和运行应用程序（在所有其他用户都在负载平衡器上运行的高峰时段）。令人惊讶的是，即使在高峰时段，绕过负载均衡器的应用程序也能如子弹般快速。

NGINX 设置

worker_processes=16
worker_connections=4096
multi_accept=on

Linux 设置

fs.file-max=13184484
net.ipv4.tcp_rmem="4096 87380 4194304"
net.ipv4.tcp_wmem="4096 16384 4194304"
net.ipv4.ip_local_port_range="32768 61000"

为什么应用如此快速地绕过负载平衡器？ nginx 作为负载均衡器会成为瓶颈吗？有什么好的方法可以比较 nginx 中的超时和 unicorns 中的超时，看看问题出在哪里？

【问题讨论】：

我理解平衡器在虚拟化下工作，而前端和数据库服务器是硬件？
所有服务器都是虚拟化的，没有一个是硬件。
性能和虚拟化是不相容的概念。 nginx 错误日志中有什么内容？

标签： ruby-on-rails performance postgresql nginx

【解决方案1】：

根据您的设置，nginx 可能是瓶颈...

在 nginx 中检查/调整以下设置：

worker_processes 设置（应该等于核心/cpu 的数量）
worker_connections 设置（如果您在高峰期有很多连接，应该非常高）
设置multi_accept on;
如果在 linux 上，在 nginx 中确保您使用的是 epoll (use epoll;-directive)

检查/调整您的操作系统的以下设置：

允许打开的文件描述符的数量（sysctl -w fs.file-max=999999 在 linux 上）
tcp 读写缓冲区（sysctl -w net.ipv4.tcp_rmem="4096 4096 16777216" 和 sysctl - net.ipv4.tcp_wmem="4096 4096 16777216" 在 Linux 上）
本地端口范围（Linux 上为sysctl -w net.ipv4.ip_local_port_range="1024 65536"）

更新：

所以您有 16 个工作人员，每个工作人员有 4096 个连接
这意味着最多 4096*16=65536 个并发连接
每个浏览器可能有多个请求（ajax、css、js、页面本身、页面上的任何图像……），假设每个浏览器有 4 个请求

允许超过 16k 并发用户，这足以满足您的峰值吗？

【讨论】：

感谢您的回答 Cobaco！我将我们的设置添加到上述问题中。看到那里有什么奇怪的东西吗？我们在 conf 文件中没有“使用 epoll”。但我无法说出我们当前使用的事件处理方式。我读到它是在启动 nginx 时作为日志通知发出的，但在 error.log 或 access.log 中找不到它。你知道如何查看 nginx 当前使用的是哪个事件处理程序吗？
只需将multi_accept on; 替换为multi_accept on; use epoll;，这样您就可以确定您使用的是epoll。 nginx.org/en/docs/events.html 没有提到任何关于日志输出的内容，我也找不到关于使用的选项的任何内容。

【解决方案2】：

您如何设置您的上游服务器组以及您使用的负载平衡方法是什么？

很难想象 Nginx 本身就是瓶颈。是否有可能某些上游应用程序服务器受到的攻击比其他应用程序服务器更多并由于积压已满而开始拒绝连接？请参阅此load balancing issue on Heroku，看看您是否可以在那里获得更多帮助。

在 nginx 1.2.2 版本之后，nginx 提供了这个least_conn。这可能是一个简单的解决方法。我自己还没试过。

指定组应使用负载平衡方法，其中请求被传递到活动数量最少的服务器连接，考虑到服务器的权重。如果有几个这样的服务器，他们尝试使用加权循环平衡法。

【讨论】：