Question

我们有一个流行的iPhone应用程序，人们互相决斗一个Wordfeud。我们今天拥有近1M注册用户。

在高峰时段，应用程序的响应时间非常长，而且还有很多时间。我们试图找到瓶颈，但是很难这样做。所有服务器上的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中的超时和独角兽的超时，看看问题所在的位置？

Answer 1

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

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

worker_processes设置（应该等于核心数/ cpus）
worker_connections设置（如果您在峰值处有很多连接，则应该非常高）
设置multi_accept on;
如果在linux上，在nginx中确保你使用的是epoll（use epoll; - 指令）

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

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

更新

所以你有16个工人和每个工人4096个连接
表示最多4096 * 16 = 65536个并发连接
你可能每个浏览器有多个请求（ajax，css，js，页面本身，页面上的任何图像，......），假设每个浏览器有4个请求

允许略高于16k的并发用户，这对你的峰值是否足够？

Answer 2

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

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

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

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

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

2 个答案: