我有一个运行在作为反向代理运行的nginx实例后面的Web服务。 Nginxconfiguration为在两台独立主机上运行的10个应用服务器进程之间进行负载平衡。
我看到的问题是，大约150个并发连接nginx开始拒绝所有新的传入连接。 在140个连接处，所有的连接都是快速和稳定的，只需要再加几个服务器就可以开始拒绝所有连接到150以上的连接。一旦所有的连接都断开了，它将再次开始接受连接。
这似乎并没有改变，因为我修改了worker_processes，worker_connections或multi_accept设置。 当拒绝开始时，CPU负载（> 10％）非常less，可用的networking带宽也很多。 错误日志中没有消息。
我在这里做错了什么？
这是configuration：
worker_processes 8; worker_rlimit_nofile 65536; events { worker_connections 8192; multi_accept on; use epoll; } http { include /etc/nginx/mime.types; access_log /var/log/nginx/access.log; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; tcp_nodelay on; gzip on; gzip_disable "MSIE [1-6]\.(?!.*SV1)"; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; } 在conf.d目录中，只有从主机名到后端服务器的映射。 喜欢这个：
upstream api { server 10.0.0.1:8000; server 10.0.0.1:8001; server 10.0.0.2:8000; server 10.0.0.2:8001; } server { listen 80; server_name api.example.com; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; location / { proxy_set_header X-Real-IP $remote_addr; proxy_redirect off; proxy_pass http://api; } }
这是EC2上的一个微观实例吗？
我上周遇到这个问题，发现这篇文章： http : //gregsramblings.com/2011/02/07/amazon-ec2-micro-instance-cpu-steal/
情况通过去一个小的实例types解决了。
也许这将有助于！
那么打开文件限制呢？ 即使1024的默认限制也没有达到150，但是检查ulimit -n输出。 您可能需要增加init.d脚本（使用ulimit命令）或/etc/security/limits.conf中的限制
那么，我有两个主要的想法。 我的第一个select是检查系统限制。 可能是因为nginx的文件描述符已经用完，或者内核可能禁止nginx使用超过一定数量的连接。 如果在内核级别发生什么事，nginx可能不知道。 你有没有检查所有通常的守护进程日志？
但是，老实说，我怀疑它更可能与你的fastcgi比较有关。 所以，对于一个非常简单的testing，使用ab（apachebench）打到nginx代理上的一个静态文件，并用几百个同时连接点击几千次。 我的猜测是，它会做到这一点，没有任何麻烦。 这意味着你可能在fastcgi上遇到了排队问题，而nginx只是把连接放在地板上而不是等待fastcgi返回。
我有同样的问题，并在这里find类似的问题 。
build议的解决scheme为我工作后，重新启动nginx。
vmstat 1在发生问题时说什么？ 服务器在故障期间是否以任何方式加载？
还要检查服务器上打开连接的实际数量（lsof -i | grep nginx或netstat -atnp | grep nginx）。 这可能是连接到应用程序服务器的问题（也许某种连接溢出到后端）
这可能是ulimit问题（你会看到使用lsof | grep nginx打开文件的数量）。
最后，我会尝试在发生问题的时候使nginx进程处于停滞状态。