ruby-on-rails-3 – 在nginx Unicorn上加载错误的网关错误(Rails 3 app)

前端之家收集整理的这篇文章主要介绍了ruby-on-rails-3 – 在nginx Unicorn上加载错误的网关错误(Rails 3 app)前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有一个Rails(3.2)应用程序,它运行在云平台上的Nginx和unicorn上. “盒子”在Ubuntu 12.04上运行.

当系统负载大约为70%或更高时,Nginx突然(并且看似随机)开始抛出502 Bad网关错误;当负载较小时,没有什么比这更好的了.我已经尝试了不同数量的核心(4,6,10 – 我可以“改变硬件”,因为它在云平台上),情况总是一样的. (cpu负载类似于系统负载,用户空间为55%,其余为系统和被盗,有足够的可用内存,没有交换.)

502通常分批进行,但并非总是如此.

(我每个核心运行一个独角兽工作者,以及一个或两个Nginx工作者.当在10个核心上运行时,请参阅下面配置的相关部分.)

我真的不知道如何跟踪这些错误的原因.我怀疑它可能与麒麟工人无法服务(及时?)有关但它看起来很奇怪,因为它们似乎没有使cpu饱和,我认为他们没有理由等待IO(但我不喜欢不知道如何确保这一点.

请你帮我看看如何找到原因?

Unicorn config(unicorn.rb):

  1. worker_processes 10
  2. working_directory "/var/www/app/current"
  3. listen "/var/www/app/current/tmp/sockets/unicorn.sock",:backlog => 64
  4. listen 2007,:tcp_nopush => true
  5. timeout 90
  6. pid "/var/www/app/current/tmp/pids/unicorn.pid"
  7. stderr_path "/var/www/app/shared/log/unicorn.stderr.log"
  8. stdout_path "/var/www/app/shared/log/unicorn.stdout.log"
  9. preload_app true
  10. GC.respond_to?(:copy_on_write_friendly=) and
  11. GC.copy_on_write_friendly = true
  12. check_client_connection false
  13.  
  14. before_fork do |server,worker|
  15. ... I believe the stuff here is irrelevant ...
  16. end
  17. after_fork do |server,worker|
  18. ... I believe the stuff here is irrelevant ...
  19. end

和ngnix配置:

/etc/Nginx/Nginx.conf:

  1. worker_processes 2;
  2. worker_rlimit_nofile 2048;
  3. user www-data www-admin;
  4. pid /var/run/Nginx.pid;
  5. error_log /var/log/Nginx/Nginx.error.log info;
  6.  
  7. events {
  8. worker_connections 2048;
  9. accept_mutex on; # "on" if Nginx worker_processes > 1
  10. use epoll;
  11. }
  12.  
  13. http {
  14. include /etc/Nginx/mime.types;
  15. default_type application/octet-stream;
  16. log_format main '$remote_addr - $remote_user [$time_local] "$request" '
  17. '$status $body_bytes_sent "$http_referer" '
  18. '"$http_user_agent" "$http_x_forwarded_for"';
  19. access_log /var/log/Nginx/access.log main;
  20. # optimialization efforts
  21. client_max_body_size 2m;
  22. client_body_buffer_size 128k;
  23. client_header_buffer_size 4k;
  24. large_client_header_buffers 10 4k; # one for each core or one for each unicorn worker?
  25. client_body_temp_path /tmp/Nginx/client_body_temp;
  26.  
  27. include /etc/Nginx/conf.d/*.conf;
  28. }

/etc/Nginx/conf.d/app.conf:

  1. sendfile on;
  2. tcp_nopush on;
  3. tcp_nodelay off;
  4. gzip on;
  5. gzip_http_version 1.0;
  6. gzip_proxied any;
  7. gzip_min_length 500;
  8. gzip_disable "MSIE [1-6]\.";
  9. gzip_types text/plain text/css text/javascript application/x-javascript;
  10.  
  11. upstream app_server {
  12. # fail_timeout=0 means we always retry an upstream even if it Failed
  13. # to return a good HTTP response (in case the Unicorn master nukes a
  14. # single worker for timing out).
  15. server unix:/var/www/app/current/tmp/sockets/unicorn.sock fail_timeout=0;
  16. }
  17.  
  18. server {
  19. listen 80 default deferred;
  20. server_name _;
  21. client_max_body_size 1G;
  22. keepalive_timeout 5;
  23. root /var/www/app/current/public;
  24.  
  25. location ~ "^/assets/.*" {
  26. ...
  27. }
  28.  
  29. # Prefer to serve static files directly from Nginx to avoid unnecessary
  30. # data copies from the application server.
  31. try_files $uri/index.html $uri.html $uri @app;
  32.  
  33. location @app {
  34. proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  35. proxy_set_header Host $http_host;
  36. proxy_redirect off;
  37.  
  38. proxy_pass http://app_server;
  39.  
  40. proxy_connect_timeout 90;
  41. proxy_send_timeout 90;
  42. proxy_read_timeout 90;
  43.  
  44. proxy_buffer_size 128k;
  45. proxy_buffers 10 256k; # one per core or one per unicorn worker?
  46. proxy_busy_buffers_size 256k;
  47. proxy_temp_file_write_size 256k;
  48. proxy_max_temp_file_size 512k;
  49. proxy_temp_path /mnt/data/tmp/Nginx/proxy_temp;
  50.  
  51. open_file_cache max=1000 inactive=20s;
  52. open_file_cache_valid 30s;
  53. open_file_cache_min_uses 2;
  54. open_file_cache_errors on;
  55. }
  56. }

解决方法

在谷歌搜索Nginx错误日志中找到的表达式后,结果证明这是一个与Nginx无关的已知问题,与unicorn关系不大,并且根植于OS(linux)设置.

问题的核心是套接字积压太短.各种考虑因素应该是多少(您是否要尽快检测集群成员故障或保持应用程序推送负载限制).但无论如何,listen:backlog需要调整.

我发现在我的情况下听一听……:backlog => 2048就足够了. (我没有多少实验,尽管如果你愿意,可以通过两个套接字在Nginx和unicorn之间进行通信,使用不同的积压和更长的备份;但是在Nginx日志中查看更短的队列失败的频率.)请注意,这不是科学计算和YMMV的结果.

但请注意,许多操作系统(大多数Linux发行版,包括Ubuntu 12.04)在套接字积压大小(低至128)上具有低得多的操作系统级默认限制.

您可以按如下方式更改操作系统限制(以root用户身份):

  1. sysctl -w net.core.somaxconn=2048
  2. sysctl -w net.core.netdev_max_backlog=2048

将这些添加到/etc/sysctl.conf以使更改成为永久更改. (/ etc / sysctl.conf可以重新加载而无需使用sysctl -p重新启动.)

有人提到您可能必须增加进程可以打开的最大文件数(使用ulimit -n和/etc/security/limits.conf来保持永久性).由于其他原因,我已经这样做了,所以我不知道它是否有所作为.

猜你在找的Ruby相关文章