当系统负载大约为70%或更高时,Nginx突然(并且看似随机)开始抛出502 Bad网关错误;当负载较小时,没有什么比这更好的了.我已经尝试了不同数量的核心(4,6,10 – 我可以“改变硬件”,因为它在云平台上),情况总是一样的. (cpu负载类似于系统负载,用户空间为55%,其余为系统和被盗,有足够的可用内存,没有交换.)
502通常分批进行,但并非总是如此.
(我每个核心运行一个独角兽工作者,以及一个或两个Nginx工作者.当在10个核心上运行时,请参阅下面配置的相关部分.)
我真的不知道如何跟踪这些错误的原因.我怀疑它可能与麒麟工人无法服务(及时?)有关但它看起来很奇怪,因为它们似乎没有使cpu饱和,我认为他们没有理由等待IO(但我不喜欢不知道如何确保这一点.
请你帮我看看如何找到原因?
Unicorn config(unicorn.rb):
worker_processes 10 working_directory "/var/www/app/current" listen "/var/www/app/current/tmp/sockets/unicorn.sock",:backlog => 64 listen 2007,:tcp_nopush => true timeout 90 pid "/var/www/app/current/tmp/pids/unicorn.pid" stderr_path "/var/www/app/shared/log/unicorn.stderr.log" stdout_path "/var/www/app/shared/log/unicorn.stdout.log" preload_app true GC.respond_to?(:copy_on_write_friendly=) and GC.copy_on_write_friendly = true check_client_connection false before_fork do |server,worker| ... I believe the stuff here is irrelevant ... end after_fork do |server,worker| ... I believe the stuff here is irrelevant ... end
和ngnix配置:
worker_processes 2; worker_rlimit_nofile 2048; user www-data www-admin; pid /var/run/Nginx.pid; error_log /var/log/Nginx/Nginx.error.log info; events { worker_connections 2048; accept_mutex on; # "on" if Nginx worker_processes > 1 use epoll; } http { include /etc/Nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/Nginx/access.log main; # optimialization efforts client_max_body_size 2m; client_body_buffer_size 128k; client_header_buffer_size 4k; large_client_header_buffers 10 4k; # one for each core or one for each unicorn worker? client_body_temp_path /tmp/Nginx/client_body_temp; include /etc/Nginx/conf.d/*.conf; }
/etc/Nginx/conf.d/app.conf:
sendfile on; tcp_nopush on; tcp_nodelay off; gzip on; gzip_http_version 1.0; gzip_proxied any; gzip_min_length 500; gzip_disable "MSIE [1-6]\."; gzip_types text/plain text/css text/javascript application/x-javascript; upstream app_server { # fail_timeout=0 means we always retry an upstream even if it Failed # to return a good HTTP response (in case the Unicorn master nukes a # single worker for timing out). server unix:/var/www/app/current/tmp/sockets/unicorn.sock fail_timeout=0; } server { listen 80 default deferred; server_name _; client_max_body_size 1G; keepalive_timeout 5; root /var/www/app/current/public; location ~ "^/assets/.*" { ... } # Prefer to serve static files directly from Nginx to avoid unnecessary # data copies from the application server. try_files $uri/index.html $uri.html $uri @app; location @app { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; proxy_pass http://app_server; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 128k; proxy_buffers 10 256k; # one per core or one per unicorn worker? proxy_busy_buffers_size 256k; proxy_temp_file_write_size 256k; proxy_max_temp_file_size 512k; proxy_temp_path /mnt/data/tmp/Nginx/proxy_temp; open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; } }
解决方法
问题的核心是套接字积压太短.各种考虑因素应该是多少(您是否要尽快检测集群成员故障或保持应用程序推送负载限制).但无论如何,listen:backlog需要调整.
我发现在我的情况下听一听……:backlog => 2048就足够了. (我没有多少实验,尽管如果你愿意,可以通过两个套接字在Nginx和unicorn之间进行通信,使用不同的积压和更长的备份;但是在Nginx日志中查看更短的队列失败的频率.)请注意,这不是科学计算和YMMV的结果.
但请注意,许多操作系统(大多数Linux发行版,包括Ubuntu 12.04)在套接字积压大小(低至128)上具有低得多的操作系统级默认限制.
您可以按如下方式更改操作系统限制(以root用户身份):
sysctl -w net.core.somaxconn=2048 sysctl -w net.core.netdev_max_backlog=2048
将这些添加到/etc/sysctl.conf以使更改成为永久更改. (/ etc / sysctl.conf可以重新加载而无需使用sysctl -p重新启动.)
有人提到您可能必须增加进程可以打开的最大文件数(使用ulimit -n和/etc/security/limits.conf来保持永久性).由于其他原因,我已经这样做了,所以我不知道它是否有所作为.