次のように、上流のUNIXソケットへのプロキシとして機能するnginxサーバーを実行しています。
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
利用可能になり次第。ここで使用されている特定のアプリサーバーはユニコーンですが、これはこの質問には関係ないと思います。
問題は、ある量の負荷を過ぎると、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
ボトルネックはNginx自体ではなく、ソケットに電力を供給するアプリにあるようです。これは、PHPソケットとTCP/IP接続を併用した場合によく見られます。この場合、PHPボトルネックは、Nginxよりもずっと早く発生します。
Sysctl.conf接続追跡制限、ソケットバックログ制限を確認しましたか
net.core.somaxconn
net.core.netdev_max_backlog
unix_dgram_qlen
を確認してみてください。 proc docs を参照してください。これは、キューでさらにポイントすることによって問題を悪化させるかもしれませんが?あなたは見る必要があります(netstat -x ...)
Config/Unicorn.rbのバックログ番号を増やすことで解決しました。以前は64のバックログがありました。
listen "/path/tmp/sockets/manager_Rails.sock", backlog: 64
そして私はこのエラーを受け取りました:
2014/11/11 15:24:09 [error] 12113#0: *400 connect() to unix:/path/tmp/sockets/manager_Rails.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 192.168.101.39, server: , request: "GET /welcome HTTP/1.0", upstream: "http://unix:/path/tmp/sockets/manager_Rails.sock:/welcome", Host: "192.168.101.93:3000"
今、私は1024に増やしました、そして私はエラーを得ません:
listen "/path/tmp/sockets/manager_Rails.sock", backlog: 1024
tl; dr
listen("/var/www/Unicorn.sock", backlog: 1024)
worker_connections 10000;
ディスカッション
同じ問題がありました。Railsアプリは、NGINXリバースプロキシの背後にあるUnicornによって提供されています。
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が要求を処理していないことが明らかだったため、NGINXがボトルネックになっているように見えました。
nginx.conf
this パフォーマンスチューニングの記事 でNGINX設定をTweakに検索すると、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/*;
}