리눅스 커널 튜닝-업스트림 유닉스 소켓으로 nginx 처리량을 늘려야합니까?

다음과 같이 업스트림 유닉스 소켓에 프록시 역할을하는 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 (사실 권장되는 방법)과 같이 일반적이기 때문에 여기에 분명한 것이 빠져 있다고 생각합니다. 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의 문서를 . 이것은 대기열에서 더 많은 것을 가리켜 서 문제를 악화시킬 수 있습니까? 당신은 봐야 할 것입니다 (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. 유니콘 백 로그가 큰지 확인하십시오 (TCP보다 빠른 소켓 사용) listen("/var/www/unicorn.sock", backlog: 1024)
2. 예를 들어 NGINX 성능 설정 최적화worker_connections 10000;

토론

NGINX 리버스 프록시 뒤에 Unicorn이 제공하는 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이 요청을 처리하지 않는 것이 분명했기 때문에 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 클라이언트는 유닉스 도메인 소켓 제한입니다.