上流のUNIXソケットへのnginxスループットを増やす必要があります— Linuxカーネルのチューニング？

私は、次のように、上流の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が利用可能になったときに順番にプルします。ここで使用している特定のアプリサーバーは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

ボトルネックは、Nginx自体ではなく、ソケットに電力を供給しているアプリのようです。これは、ソケットとTCP / IP接続を併用した場合にPHPでよく見られます。私たちの場合、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

1. Unicornバックログが大きいことを確認してください（TCPよりも高速のソケットを使用してください） listen("/var/www/unicorn.sock", backlog: 1024)
2. たとえば、NGINXパフォーマンス設定を最適化するworker_connections 10000;

討論

同じ問題がありました-Unicornが提供するRailsアプリは、NGINXリバースプロキシの背後にあります。

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がボトルネックのように見えました。

nginx.confこのパフォーマンスチューニングの記事で微調整するためにNGINX設定を検索すると、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/*;
}

バックログのデフォルト値はユニコーン設定で1024です。

http://unicorn.bogomips.org/Unicorn/Configurator.html

listen "/path/to/.unicorn.sock", :backlog => 1024

1024クライアントはUNIXドメインソケットの制限です。