我有一台 nginx 服务器（CentOS 5.3，Linux），用作 8 台 ruby on rails 应用服务器前的反向代理负载平衡器。随着这些服务器上的负载增加，我开始怀疑 nginx 服务器什么时候会成为瓶颈？CPU 几乎不使用，但这是意料之中的。内存似乎没问题。没有 IO 可言。
那么我唯一的限制是 NIC 上的带宽吗？目前，根据一些 Cacti 图表，服务器在高负载期间在每个 NIC 上的带宽达到约 700Kbps（5 分钟平均值）。我认为这仍然很低。
或者，限制是在套接字或操作系统中的其他资源中？
感谢您的任何想法和见解。
编辑：
racyclist：
感谢您的见解。我做了一些深入研究。我有 1 个工作线程允许 1024 个 worker_connections。假设 95% 的请求都是针对少量数据。对于 512MB 的系统应该能够处理什么连接，有什么建议吗？
另外，有什么好方法来计算连接数？ 像这样的方法准确吗？
netstat -np | grep ESTABLISHED | grep nginx | wc -l
结束编辑
亚伦
答案1
目前，根据带宽利用率来看，负载相当低。存在许多可能的瓶颈，仅举几例：
网络相关
随着连接数的增加，您可能会达到worker_connectionsNginx 工作进程的限制。racyclist 的描述非常好，我只想补充几点。实际上，您拥有的工作进程越多，您达到worker_connections某个特定工作进程限制的可能性就越大。原因是 Nginx 主进程无法保证工作进程之间的连接均匀分布——其中一些工作进程可以比其他工作进程更快地处理请求，因此最终可能会超出限制。
我的建议是使用尽可能少的 worker 和大量的worker_connections。但是，如果您有 IO（请参阅下文），则必须增加 worker 的数量。使用 nginx 的status模块来监视它使用的套接字数量。
您可能会达到操作系统（Linux 或 FreeBSD）对每个进程打开文件描述符数量的限制。Nginx 不仅会将描述符用于传入请求，还会用于与后端的传出连接。最初，此限制设置为非常低的值（例如 1024）。Nginx 会在error.log此事件中发出抱怨。
如果你正在使用iptables及其 conntrack 模块（Linux），你也应该超出表的大小conntrack。注意dmesg或/var/log/messages。根据需要增加此限制。
一些经过很好优化的应用程序占用了 100% 的带宽。我敢打赌你以前一定遇到过类似的问题。
IO相关
事实上，Nginx 工作进程会在 IO 上阻塞。因此，如果您的网站提供静态内容，则需要增加 Nginx 工作进程的数量以解决 IO 阻塞问题。这里很难给出解决方案，因为它们会根据文件的数量和大小、加载类型、可用内存等而有很大差异。
如果您通过 Nginx 代理连接到某些后端，则应考虑到它会创建临时文件来存储后端的答案，并且在流量较大的情况下，这会导致文件系统负载过大。请留意 Nginx 中的消息error.log并进行相应的调整proxy_buffers（或fastcgi_buffers）。
如果你有一些后台 IO（例如 MySQL），它也会影响静态文件服务。注意IO 等待百分比
答案2
这不仅仅是 NIC 的带宽。Nginx 具有它可以处理的最大连接数。最大连接数可以通过一个简单的公式计算出来：“worker_processes”*“worker_connections”。瓶颈将取决于您的应用程序。如果您有许多使用低带宽的连接，则在填满管道之前您更有可能用完连接。相反，少量使用大量带宽的连接可能会填满您的管道而不会达到最大连接数。
答案3
关于打开的连接，跟踪它们的最佳方法是检查 /proc/net/ip_conntrack。
cat /proc/net/ip_conntrack | egrep 'dport=(80|443)'| wc -l
现在，关于您的 nginx 问题，没有真正的答案。您只需要对您的设置进行基准测试（使用 httperf 等工具）并查看您可以处理的负载是多少。