我正在运行一个 nginx 服务器,它充当上游 unix 套接字的代理,如下所示:
upstream app_server {
server unix:/tmp/app.sock fail_timeout=0;
}
server {
listen ###.###.###.###;
server_name whatever.server;
root /web/root;
try_files $uri @app;
location @app {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://app_server;
}
}
反过来,一些应用服务器进程会在请求/tmp/app.sock
可用时将其拉出。这里使用的特定应用服务器是 Unicorn,但我认为这与这个问题无关。
问题是,似乎超过一定负载量后,nginx 就无法以足够快的速度通过套接字获取请求。无论我设置了多少个应用服务器进程,都没有用。
我在 nginx 错误日志中收到大量此类消息:
connect() to unix:/tmp/app.sock failed (11: Resource temporarily unavailable) while connecting to upstream
许多请求都会导致状态代码 502,而那些不需要很长时间才能完成的请求也是如此。nginx 写入队列统计徘徊在 1000 左右。
无论如何,我觉得我在这里忽略了一些明显的东西,因为这种 nginx 和应用服务器的特定配置非常常见,尤其是对于 Unicorn(事实上这是推荐的方法)。是否有任何需要设置的 Linux 内核选项,或者 nginx 中的某些内容?关于如何增加上游套接字的吞吐量有什么想法吗?我明显做错了什么?
有关环境的其他信息:
$ uname -a
Linux servername 2.6.35-32-server #67-Ubuntu SMP Mon Mar 5 21:13:25 UTC 2012 x86_64 GNU/Linux
$ ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
$ unicorn -v
unicorn v4.3.1
$ nginx -V
nginx version: nginx/1.2.1
built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
TLS SNI support enabled
当前内核调整:
net.core.rmem_default = 65536
net.core.wmem_default = 65536
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_mem = 16777216 16777216 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.core.somaxconn = 8192
net.netfilter.nf_conntrack_max = 524288
nginx 用户的 ulimit 设置:
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 20
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65535
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
答案1
听起来瓶颈在于为套接字供电的应用程序,而不是 Nginx 本身。我们在使用套接字而不是 TCP/IP 连接时经常看到这种情况。在我们的案例中,PHP 的瓶颈比 Nginx 出现得早得多。
您是否检查过 sysctl.conf 连接跟踪限制、套接字积压限制
net.core.somaxconn
net.core.netdev_max_backlog
答案2
总结
- 确保 Unicorn 积压量很大(使用套接字,比 TCP 更快)
listen("/var/www/unicorn.sock", backlog: 1024)
- 优化NGINX 性能设置, 例如
worker_connections 10000;
讨论
我们遇到了同样的问题——Unicorn 在 NGINX 反向代理后面提供 Rails 应用程序。
我们在 Nginx 错误日志中收到如下行:
2019/01/29 15:54:37 [error] 3999#3999: *846 connect() to unix:/../unicorn.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: xx.xx.xx.xx, request: "GET / HTTP/1.1"
阅读其他答案后,我们还认为 Unicorn 可能是罪魁祸首,因此我们增加了它的积压,但这并没有解决问题。监控服务器进程后,很明显 Unicorn 没有得到要处理的请求,因此 NGINX 似乎是瓶颈。
正在搜索要调整的 NGINXnginx.conf
设置性能调优文章指出了几个可能影响 NGINX 处理并行请求数量的设置,特别是:
user www-data;
worker_processes auto;
pid /run/nginx.pid;
worker_rlimit_nofile 400000; # important
events {
worker_connections 10000; # important
use epoll; # important
multi_accept on; # important
}
http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
keepalive_requests 100000; # important
server_names_hash_bucket_size 256;
include /etc/nginx/mime.types;
default_type application/octet-stream;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
gzip on;
gzip_disable "msie6";
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
答案3
你可以尝试 unix_dgram_qlen
看看程序文档。虽然这可能会通过在队列中指向更多内容而使问题更加复杂?您必须查看(netstat -x...)
答案4
在 Unicorn 配置中,backlog 的默认值是 1024。
http://unicorn.bogomips.org/Unicorn/Configurator.html
listen "/path/to/.unicorn.sock", :backlog => 1024
1024 客户端是 unix 域套接字限制。