Perlu meningkatkan nginx throughput ke hulu unix socket - linux tuning kernel?


28

Saya menjalankan server nginx yang bertindak sebagai proxy ke soket unix hulu, seperti ini:

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;
        }
}

Beberapa server aplikasi memproses, pada gilirannya, menarik permintaan /tmp/app.socksaat tersedia. Server aplikasi tertentu yang digunakan di sini adalah Unicorn, tapi saya pikir itu tidak relevan dengan pertanyaan ini.

Masalahnya adalah, sepertinya melewati jumlah beban tertentu, nginx tidak bisa mendapatkan permintaan melalui soket dengan kecepatan yang cukup cepat. Tidak masalah berapa banyak proses server aplikasi yang saya atur.

Saya menerima banjir pesan ini di log kesalahan nginx:

connect() to unix:/tmp/app.sock failed (11: Resource temporarily unavailable) while connecting to upstream

Banyak permintaan menghasilkan kode status 502, dan permintaan yang tidak butuh waktu lama untuk diselesaikan. Stat antrian nginx write berkisar sekitar 1000.

Bagaimanapun, saya merasa seperti kehilangan sesuatu yang jelas di sini, karena konfigurasi khusus ini dari nginx dan server aplikasi cukup umum, terutama dengan Unicorn (sebenarnya metode yang disarankan). Apakah ada opsi kernel linux yang perlu diatur, atau sesuatu di nginx? Adakah ide tentang cara meningkatkan throughput ke hulu soket? Sesuatu yang saya jelas salah lakukan?

Informasi tambahan tentang lingkungan:

$ 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

Tweak kernel saat ini:

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

Pengaturan Ulimit untuk pengguna nginx:

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

Apakah Anda memeriksa output ulimit, khususnya jumlah file yang terbuka?
Khaled

@ Tertidur, ulimit -nkata 65535.
Ben Lee

Jawaban:


16

Kedengarannya seperti hambatan adalah aplikasi yang memberi daya pada soket alih-alih Nginx itu sendiri. Kami melihat ini banyak dengan PHP ketika digunakan dengan soket versus koneksi TCP / IP. Dalam kasus kami, kemacetan PHP jauh lebih awal daripada Nginx.

Sudahkah Anda memeriksa batas pelacakan koneksi sysctl.conf, batas simpanan soket

  • net.core.somaxconn
  • net.core.netdev_max_backlog

2
Saya telah memahami permasalahannya. Lihat jawaban yang saya posting. Sebenarnya itu adalah bottlenecking aplikasi, bukan soket, seperti yang Anda duga. Saya telah mengesampingkan ini sebelumnya karena kesalahan diagnosa, tetapi ternyata masalahnya adalah throughput ke server lain. Menemukan ini beberapa jam yang lalu. Saya akan memberikan hadiah kepada Anda, karena Anda cukup banyak menemukan sumber masalahnya meskipun saya salah diagnosa dalam pertanyaan; namun, akan memberikan tanda centang pada jawaban saya, karena jawaban saya menjelaskan keadaan yang tepat sehingga dapat membantu seseorang di masa depan dengan masalah yang sama.
Ben Lee

Punya server baru pindah ke lokasi untuk memberikan throughput yang memadai, sepenuhnya membangun kembali sistem, dan masih memiliki masalah yang sama. Jadi ternyata masalah saya belum terselesaikan ... = (Saya masih berpikir ini khusus untuk aplikasi, tetapi tidak dapat memikirkan apa pun. Server baru ini diatur persis seperti server lain di mana ia berfungsi dengan baik. Ya, somaxconn dan netdev_max_backlog berjalan dengan benar
Ben Lee

Masalah Anda bukan nginx, itu lebih dari mampu - tetapi itu tidak berarti Anda mungkin tidak memiliki pengaturan jahat. Soket sangat sensitif di bawah beban tinggi ketika batas tidak dikonfigurasi dengan benar. Bisakah Anda mencoba aplikasi Anda dengan tcp / ip saja?
Ben Lessani - Sonassi

masalah yang sama bahkan dengan besaran yang lebih buruk menggunakan tcp / ip (tulis antrian naik lebih cepat). Saya memiliki nginx / unicorn / kernel yang semuanya sama persis (sejauh yang saya tahu) pada mesin yang berbeda, dan mesin lain tidak menunjukkan masalah ini. (Saya dapat beralih dns antara dua mesin, untuk mendapatkan pengujian beban langsung, dan memiliki dns pada ttl 60 detik)
Ben Lee

Throughput antara masing-masing mesin dan mesin db adalah sama sekarang, dan latensi antara mesin baru dan mesin db sekitar 30% lebih dari antara mesin lama dan db. Tapi 30% lebih dari sepersepuluh milidetik bukan masalah.
Ben Lee

2

Anda dapat mencoba melihat unix_dgram_qlen, lihat dokumen proc . Meskipun ini dapat menambah masalah dengan menunjuk lebih banyak dalam antrian? Anda harus melihat (netstat -x ...)


Adakah kemajuan dengan ini?
jmw

1
Terima kasih atas idenya, tetapi ini tampaknya tidak membuat perbedaan.
Ben Lee

0

Saya dipecahkan dengan menambah jumlah backlog di config / unicorn.rb ... Saya dulu punya backlog 64.

 listen "/path/tmp/sockets/manager_rails.sock", backlog: 64

dan saya mendapatkan kesalahan ini:

 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"

Sekarang, saya meningkat menjadi 1024 dan saya tidak mendapatkan kesalahan:

 listen "/path/tmp/sockets/manager_rails.sock", backlog: 1024

0

tl; dr

  1. Pastikan Unicorn backlog besar (gunakan socket, lebih cepat dari TCP) listen("/var/www/unicorn.sock", backlog: 1024)
  2. Optimalkan pengaturan kinerja NGINX , misalnyaworker_connections 10000;

Diskusi

Kami memiliki masalah yang sama - aplikasi Rails dilayani oleh Unicorn di belakang proxy terbalik NGINX.

Kami mendapatkan baris seperti ini di log kesalahan 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"

Membaca jawaban lain, kami juga menduga bahwa mungkin Unicorn yang harus disalahkan, jadi kami menambah simpanannya, tetapi ini tidak menyelesaikan masalah. Memantau proses server, sudah jelas bahwa Unicorn tidak mendapatkan permintaan untuk bekerja, sehingga NGINX tampaknya menjadi penghambat.

Mencari pengaturan nginx untuk Tweak di nginx.confini kinerja artikel tala menunjuk keluar beberapa setting yang bisa berdampak berapa banyak parallel permintaan nginx dapat memproses, terutama:

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/*;
}

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.