ruby-on-rails - 由于 Phusion Passenger 队列阻塞导致 Web 服务负载过重

转载作者：可可西里更新时间：2023-11-01 10:43:13

我们正在使用 Ruby 2 on Rails 4、Mongoid 4、MongoDB 2.6 开发 Web 服务。它使用 Sidekiq 3.3.0 和 Redis 2.8，并在 Phusion Passenger 5.0.4 + Nginx 1.7.10 上运行。它仅通过 JSON API 为移动客户端和 AngularJS 网络客户端提供服务。

通常一切正常，API 处理和响应不到 1 秒。但在高峰时段，服务负载很重(API 呈现为503 Service Unavailable)。下面是我们的 Nginx 和 Mongoid 配置:

Nginx 配置

passenger_root /home/deployer/.rvm/gems/ruby-2.1.3/gems/passenger-4.0.53;
#passenger_ruby /usr/bin/ruby;
passenger_max_pool_size 70;
passenger_min_instances 1;
passenger_max_requests 20; # A workaround if apps are mem-leaking
passenger_pool_idle_time 300;
passenger_max_instances_per_app 30;
passenger_pre_start http://production_domain/;

## Note: there're 2 apps with the same config
server {
  listen 80;
  server_name production_domain;
  passenger_enabled on;
  root /home/deployer/app_name-production/current/public;

  more_set_headers 'Access-Control-Allow-Origin: *'
  more_set_headers 'Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE, HEAD';
  more_set_headers 'Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';

  if ($request_method = 'OPTIONS') {
    # more_set_headers 'Access-Control-Allow-Origin: *';
    # add_header 'Access-Control-Allow-Origin' '*';
    # add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
    # add_header 'Access-Control-Allow-Headers' 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,X-FooA$
    # add_header 'Access-Control-Max-Age' 1728000;
    # add_header 'Content-Type' 'text/plain charset=UTF-8';
    # add_header 'Content-Length' 0;
    return 200;
  }

  access_log /var/log/nginx/app_name-production.access.log;
  error_log /var/log/nginx/app_name-production.error.log;

  error_page 404 /404.html;
  error_page 500 502 503 504 /50x.html;
  location = /50x.html {
    root /etc/nginx/html/;
  }
  rails_env production;
}

Mongoid 配置

development:
  sessions:
    default:
      another:
      uri: mongodb://127.0.0.1:27017/database_name
test:
  sessions:
    default:
      another:
      uri: mongodb://127.0.0.1:27017/database_name
      options:
        pool_size: 10
        pool_timeout: 15
        retry_interval: 1
        max_retries: 30
        refresh_interval: 10
        timeout: 15
staging:
  sessions:
    default:
      another:
      uri: mongodb://staging_domain/staging_database
      options:
        pool_size: 10
        pool_timeout: 15
        retry_interval: 1
        max_retries: 30
        refresh_interval: 10
        timeout: 15
production:
  sessions:
    default:
      another:
      uri: mongodb://production_domain/production_database
      options:
        pool_size: 30
        pool_timeout: 15
        retry_interval: 1
        max_retries: 30
        refresh_interval: 10
        timeout: 15

Sidekiq 配置

重载时的乘客日志:

Version : 5.0.4
Date    : 2015-04-04 09:31:14 +0700
Instance: MxPcaaBy (nginx/1.7.10 Phusion_Passenger/5.0.4)

----------- General information -----------
Max pool size : 120
Processes     : 62
Requests in top-level queue : 0

----------- Application groups -----------
/home/deployer/memo_rails-staging/current/public (staging)#default:
  App root: /home/deployer/memo_rails-staging/current
  Requests in queue: 0
  * PID: 20453   Sessions: 0       Processed: 639     Uptime: 14h 34m 26s
    CPU: 0%      Memory  : 184M    Last used: 14s ago
  * PID: 402     Sessions: 0       Processed: 5       Uptime: 13h 0m 42s
    CPU: 0%      Memory  : 171M    Last used: 23m 35s
  * PID: 16081   Sessions: 0       Processed: 3       Uptime: 10h 26m 9s
    CPU: 0%      Memory  : 163M    Last used: 24m 9s a
  * PID: 30300   Sessions: 0       Processed: 1       Uptime: 4h 19m 43s
    CPU: 0%      Memory  : 164M    Last used: 24m 15s

/home/deployer/memo_rails-production/current/public (production)#default:
  App root: /home/deployer/memo_rails-production/current
  Requests in queue: 150
  * PID: 25924   Sessions: 1       Processed: 841     Uptime: 20m 49s
    CPU: 3%      Memory  : 182M    Last used: 7m 58s ago
  * PID: 25935   Sessions: 1       Processed: 498     Uptime: 20m 49s
    CPU: 2%      Memory  : 199M    Last used: 5m 40s ago
  * PID: 25948   Sessions: 1       Processed: 322     Uptime: 20m 49s
    CPU: 1%      Memory  : 200M    Last used: 7m 57s ago
  * PID: 25960   Sessions: 1       Processed: 177     Uptime: 20m 49s
    CPU: 0%      Memory  : 158M    Last used: 19s ago
  * PID: 25972   Sessions: 1       Processed: 115     Uptime: 20m 48s
    CPU: 0%      Memory  : 151M    Last used: 7m 56s ago
  * PID: 25987   Sessions: 1       Processed: 98      Uptime: 20m 48s
    CPU: 0%      Memory  : 179M    Last used: 7m 56s ago
  * PID: 25998   Sessions: 1       Processed: 77      Uptime: 20m 48s
    CPU: 0%      Memory  : 145M    Last used: 7m 2s ago
  * PID: 26012   Sessions: 1       Processed: 97      Uptime: 20m 48s
    CPU: 0%      Memory  : 167M    Last used: 19s ago
  * PID: 26024   Sessions: 1       Processed: 42      Uptime: 20m 47s
    CPU: 0%      Memory  : 148M    Last used: 7m 55s ago
  * PID: 26038   Sessions: 1       Processed: 44      Uptime: 20m 47s
    CPU: 0%      Memory  : 164M    Last used: 1m 0s ago
  * PID: 26050   Sessions: 1       Processed: 29      Uptime: 20m 47s
    CPU: 0%      Memory  : 142M    Last used: 7m 54s ago
  * PID: 26063   Sessions: 1       Processed: 41      Uptime: 20m 47s
    CPU: 0%      Memory  : 168M    Last used: 1m 1s ago
  * PID: 26075   Sessions: 1       Processed: 23      Uptime: 20m 47s
    CPU: 0%      Memory  : 126M    Last used: 7m 51s ago
  * PID: 26087   Sessions: 1       Processed: 19      Uptime: 20m 46s
    CPU: 0%      Memory  : 120M    Last used: 7m 50s ago
  * PID: 26099   Sessions: 1       Processed: 37      Uptime: 20m 46s
    CPU: 0%      Memory  : 131M    Last used: 7m 3s ago
  * PID: 26111   Sessions: 1       Processed: 20      Uptime: 20m 46s
    CPU: 0%      Memory  : 110M    Last used: 7m 49s ago
  * PID: 26126   Sessions: 1       Processed: 28      Uptime: 20m 46s
    CPU: 0%      Memory  : 172M    Last used: 1m 56s ago
  * PID: 26141   Sessions: 1       Processed: 20      Uptime: 20m 45s
    CPU: 0%      Memory  : 107M    Last used: 7m 19s ago
  * PID: 26229   Sessions: 1       Processed: 20      Uptime: 20m 21s
    CPU: 0%      Memory  : 110M    Last used: 11s ago
  * PID: 26241   Sessions: 1       Processed: 9       Uptime: 20m 21s
    CPU: 0%      Memory  : 105M    Last used: 7m 47s ago
  * PID: 26548   Sessions: 1       Processed: 23      Uptime: 19m 14s
    CPU: 0%      Memory  : 125M    Last used: 7m 44s ago
  * PID: 27465   Sessions: 1       Processed: 30      Uptime: 15m 23s
    CPU: 0%      Memory  : 109M    Last used: 2m 22s ago
  * PID: 27501   Sessions: 1       Processed: 28      Uptime: 15m 18s
    CPU: 0%      Memory  : 117M    Last used: 7m 15s ago
  * PID: 27511   Sessions: 1       Processed: 34      Uptime: 15m 17s
    CPU: 0%      Memory  : 144M    Last used: 5m 40s ago
  * PID: 27522   Sessions: 1       Processed: 30      Uptime: 15m 17s
    CPU: 0%      Memory  : 110M    Last used: 26s ago
  * PID: 27533   Sessions: 1       Processed: 38      Uptime: 15m 17s
    CPU: 0%      Memory  : 110M    Last used:"4m 44s ago
  * PID: 27555   Sessions: 1       Processed: 27      Uptime: 15m 15s
    CPU: 0%      Memory  : 120M    Last used: 1m 29s ago
  * PID: 27570   Sessions: 1       Processed: 21      Uptime: 15m 14s
    CPU: 0%      Memory  : 107M    Last used: 7m 1s ago
  * PID: 27590   Sessions: 1       Processed: 8       Uptime: 15m 13s
    CPU: 0%      Memory  : 105M    Last used: 7m 34s ago
  * PID: 27599   Sessions: 1       Processed: 13      Uptime: 15m 13s
    CPU: 0%      Memory  : 107M    Last used: 7m 0s ago
  * PID: 27617   Sessions: 1       Processed: 26      Uptime: 15m 12s
    CPU: 0%      Memory  : 114M    Last used: 4m 49s ago
  * PID: 27633   Sessions: 1       Processed: 19      Uptime: 15m 11s
    CPU: 0%      Memory  : 137M    Last used: 1m 14s ago
  * PID: 27643   Sessions: 1       Processed: 15      Uptime: 15m 11s
    CPU: 0%      Memory  : 132M    Last used: 6m 19s ago
  * PID: 27661   Sessions: 1       Processed: 23      Uptime: 15m 10s
    CPU: 0%      Memory  : 112M    Last used: 9s ago
  * PID: 27678   Sessions: 1       Processed: 24      Uptime: 15m 9s
    CPU: 0%      Memory  : 108M    Last used: 6m 53s ago
  * PID: 27692   Sessions: 1       Processed: 9       Uptime: 15m 9s
    CPU: 0%      Memory  : 105M    Last used: 7m 22s ago
  * PID: 28400   Sessions: 1       Processed: 19      Uptime: 12m 45s
    CPU: 0%      Memory  : 111M    Last used: 1m 25s ago
  * PID: 28415   Sessions: 1       Processed: 26      Uptime: 12m 45s
    CPU: 0%      Memory  : 149M    Last used: 3m 45s ago
  * PID: 28439   Sessions: 1       Processed: 14      Uptime: 12m 44s
    CPU: 0%      Memory  : 106M    Last used: 59s ago
  * PID: 28477   Sessions: 1       Processed: 12      Uptime: 12m 42s
    CPU: 0%      Memory  : 108M    Last used: 1m 34s ago
  * PID: 28495   Sessions: 1       Processed: 14      Uptime: 12m 41s
    CPU: 0%      Memory  : 108M    Last used: 18s ago
  * PID: 29315   Sessions: 1       Processed: 7       Uptime: 10m 1s
    CPU: 0%      Memory  : 107M    Last used: 7m 0s ago
  * PID: 29332   Sessions: 1       Processed: 13      Uptime: 10m 0s
    CPU: 0%      Memory  : 108M    Last used: 5m 39s ago
  * PID: 29341   Sessions: 1       Processed: 7       Uptime: 10m 0s
    CPU: 0%      Memory  : 105M    Last used: 6m 53s ago
  * PID: 29353   Sessions: 1       Processed: 11      Uptime: 10m 0s
    CPU: 0%      Memory  : 119M    Last used: 5m 4s ago
  * PID: 29366   Sessions: 1       Processed: 16      Uptime: 9m 59s
    CPU: 0%      Memory  : 119M    Last used: 3m 13s ago
  * PID: 29377   Sessions: 1       Processed: 10      Uptime: 9m 59s
    CPU: 0%      Memory  : 113M    Last used: 1m 34s ago
  * PID: 29388   Sessions: 1       Processed: 2       Uptime: 9m 59s
    CPU: 0%      Memory  : 97M     Last used: 7m 28s ago
  * PID: 29400   Sessions: 1       Processed: 6       Uptime: 9m 59s
    CPU: 0%      Memory  : 103M    Last used: 6m 53s ago
  * PID: 29422   Sessions: 1       Processed: 17      Uptime: 9m 58s
    CPU: 0%      Memory  : 132M    Last used: 1m 24s ago
  * PID: 29438   Sessions: 1       Processed: 1       Uptime: 9m 57s
    CPU: 0%      Memory  : 96M     Last used: 6m 52s ago
  * PID: 29451   Sessions: 1       Processed: 21      Uptime: 9m 56s
    CPU: 0%      Memory  : 133M    Last used: 2m 10s ago
  * PID: 29463   Sessions: 1       Processed: 19      Uptime: 9m 56s
    CPU: 0%      Memory  : 111M    Last used: 27s ago
  * PID: 29477   Sessions: 1       Processed: 23      Uptime: 9m 56s
    CPU: 0%      Memory  : 117M    Last used: 14s ago
  * PID: 30625   Sessions: 1       Processed: 7       Uptime: 6m 49s
    CPU: 0%      Memory  : 106M    Last used: 1m 21s ago
  * PID: 30668   Sessions: 1       Processed: 2       Uptime: 6m 44s
    CPU: 0%      Memory  : 105M    Last used: 1m 13s ago
  * PID: 30706   Sessions: 1       Processed: 16      Uptime: 6m 43s
    CPU: 0%      Memory  : 148M    Last used: 1m 11s ago
  * PID: 30718   Sessions: 1       Processed: 12      Uptime: 6m 43s
    CPU: 0%      Memory  : 112M    Last used: 1m 16s ago

我有一些问题:

似乎是互联网连接速度较慢的人正在请求我们的服务，导致 Passenger 进程被阻止。我们必须重新启动 Nginx 才能使 Web 服务再次运行。有人有这方面的经验吗？
我们还使用 Sidekiq 作为工作队列。我们的大多数 Worker 都是在不影响 MongoDB 的情况下实现的。他们工作得很好。

但是我们使用 2 个 Worker 来更新用户的数据，它们查询、更新和插入数据到数据库中。我们尝试使用 MongoDB 批量命令(update 和 insert)优化这些所有任务。

正常情况下，当少量用户请求web服务时，Workers工作正常，繁忙队列在1分钟左右处理完毕，但当它收到更多请求时，繁忙队列会阻塞整个系统。我们必须再次重新启动 Nginx 才能使其正常工作。以下是 Sidekiq 配置:

development:
  :concurrency: 5
  :logfile: ./log/sidekiq_development.log
  :pidfile: ./log/sidekiq.pid
staging:
  :concurrency: 5
  :logfile: ./log/sidekiq_staging.log
  :pidfile: ./log/sidekiq.pid
production:
  :concurrency: 15
  :logfile: ./log/sidekiq_production.log
  :pidfile: ./log/sidekiq.pid
:queues:
  - ...

我们对这些问题没有任何经验。有人有什么想法吗？

更新 1:

在服务器负载过重时进行一些监控后，我们得到了这样的结果:MongoDB 进程有很多故障和堆积的读取队列，以下是 mongostat 在停机期间记录的内容:

insert  query update delete getmore command flushes mapped  vsize    res faults      locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn       time
    *0      2     *0     *0       0     4|0       0    79g   160g  3.36g    137   memo_v2:2.6%          0      17|0     8|0    36k     8k    61   15:05:22
    *0      6     *0     *0       0     1|0       0    79g   160g  3.38g    144   memo_v2:2.1%          0      30|0     3|0   722b    11k    61   15:05:23
  1595     15      1     *0       0     5|0       0    79g   160g  3.41g    139  memo_v2:19.7%          0      20|0     8|0   164k   179k    61   15:05:25
     1     18      2     *0       1     6|0       0    79g   160g  3.38g    198  memo_v2:14.4%          0      31|0     1|0     3k   122k    61   15:05:26
     2     20      4     *0       0     7|0       0    79g   160g  3.38g    169   memo_v2:8.6%          0      29|0     1|0     3k   157k    61   15:05:27
     1      6     23     *0       0     4|0       0    79g   160g  3.39g    190  memo_v2:18.7%          0      32|0     1|0     1k    63k    61   15:05:28
     1      4     42     *0       0     4|0       0    79g   160g   3.1g    115  memo_v2:35.9%          0      30|0     0|1     1k    20k    61   15:05:29
     1      5     51     *0       0     4|0       0    79g   160g  3.11g    177  memo_v2:30.0%          0      28|0     1|0     1k    23k    61   15:05:30
    *0      6     20     *0       0     2|0       0    79g   160g  3.12g    174  memo_v2:40.9%          0      28|0     1|0    15k     7k    61   15:05:31
     2      9     *0     *0       1     7|0       0    79g   160g   3.1g    236   memo_v2:4.4%          0      26|0     2|0     2k    31k    61   15:05:32

有人遇到过这个问题吗？

最佳答案

我没有足够的声誉来发表评论，所以我必须添加一个非常乏味的答案。

我对堆栈没有任何经验，但如果您认为缓慢的客户端是造成乘客问题的原因是正确的，那么我建议您确保乘客面前有足够的缓冲流程。

对于 nginx，重要的设置看起来是 proxy_buffers。以下文章中标题为“使用缓冲区释放后端服务器”的部分讨论了 nginx 模块:https://www.digitalocean.com/community/tutorials/understanding-nginx-http-proxying-load-balancing-buffering-and-caching

对于 mongodb 问题，听起来您只需要深入挖掘一下。如果您能在代码中找到问题发生的位置，那么解决方案可能会自行出现。 Hongli 链接的文章看起来非常好。

关于ruby-on-rails - 由于 Phusion Passenger 队列阻塞导致 Web 服务负载过重，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29442467/

文章推荐： mongodb - Mongodb find() 查询嵌套文档

文章推荐： windows - 批处理文件在 FOR/f 之后不继续

文章推荐： windows - 从 HTA 中启动批处理文件

apache - Phusion 乘客未登录
我在我的 Ubuntu 10.04 机器上启动和运行乘客时遇到问题(参见 https://stackoverflow.com/questions/9243272/passenger-ruby-on-r
ruby - Phusion 旅客不能自由港
好的，我正在独立运行乘客，犯了一个愚蠢的错误，现在我需要帮助修复。因此，一个测试应用程序目录在特定端口上运行独立的 passenger，我删除了该目录，以便我可以提取一个新的应用程序来代替它(并使用
ruby - apache、phusion 乘客和内存使用情况
我在某处读过这篇文章: “对于一个普通的 Apache 服务器，如果你运行许多子进程并不重要——每个进程大约 1 MB(大部分是共享的)，所以它们不会占用大量 RAM。情况不同mod_perl，其中进
nginx - Phusion Passenger 配置文件在哪里？
Phusion Passenger 的 Apache 模块安装在哪里？我想调整“Configuring Phusion Passenger”中的一些配置值。我不知道这个配置文件在哪里。我已经按照 N
apache - Phusion Passenger 内部服务器错误
我在我的 Linode 服务器上使用 Apache + Passenger，使用 Postgresql-9.4 数据库。每隔一段时间，我就会收到以下错误，但它是不可预测的，并且在几分钟后没有采取任何措
ruby - Phusion passenger 正在覆盖我的数据库配置
我正在使用 nginx 和 Phusion Passenger 来引导加载 ruby on rails 应用程序，如果我像这样运行应用程序 rails s -e production 它确实正确连
ruby - Phusion passenger 中的多个请求是否在各自的线程中运行？
我有一个使用 Phusion passenger + Apache 网络服务器部署的 Ruby on Rails 应用程序。每个请求是否都在由 Phusion Passenger 生成的自己的线程中运
ruby - 我如何绝对确保 Phusion Passenger 实例保持事件状态？
我遇到了一个问题，无论我尝试什么，所有乘客实例都会在空闲期(5 分钟，但有时更长)后被销毁。我已阅读 Stack Overflow 上的乘客文档和相关问题/答案。我的全局配置如下所示: Passen
ruby-on-rails - Phusion 乘客诉 WEBrick
就生产环境而言，使用 Phusion Passenger 或仅使用 WEBrick(例如 rails s)有什么区别？我知道 Phusion Passenger 在 Apache 或 Nginx 上
ruby-on-rails - 如何阻止 phusion 乘客生成服务器重新启动？
我让 Phusion Passenger 在我的本地机器上运行我的 Ruby on Rails 应用程序，但我希望能够完全终止该进程并在同一端口上运行不同的(非 Apache)服务。不幸的是，当我杀死
ruby-on-rails - 如何重启 phusion passenger？
rails@george:/srv/fsg_distro$ sudo passenger-status *** Phusion Passenger: no passenger_native_suppo
ruby-on-rails - 如何限制 Phusion 乘客内存使用量？
有没有办法限制 Phusion 乘客在提供应用程序时使用的内存量？在我获得大量流量后，我的主机过来并终止了该进程，因此我最终提供了空白页面。有什么我可以说的“嘿，不要使用超过 100Mb 的空间，并
ruby-on-rails - Phusion Passenger(傻瓜专用!)
我是一名经验丰富的 LAMP 开发人员，即将进入 Rails。我有一个非常愚蠢的问题要问:Phusion Passenger 到底是做什么的？我读过很多文档，我用 Google 搜索过，我读过 Wi
ruby-on-rails - 共享服务器上的 Phusion Passenger
有没有人对修复 Passenger 在共享服务器上缓慢的初始加载有任何建议？我通常与 engineyard 和他们可爱的 gem 一起工作，这使得部署更加容易。我想知道是否有人对如何加快 Passen
ubuntu - Phusion 乘客独立 meteor 教程因生成错误而失败
我试过教程 Quickstart: Meteor + Phusion Passenger在 Ubuntu 18.04 和 16.04 以及 Centos 7 上。在所有情况下，我都会遇到与以下 Ubu
ruby-on-rails - Phusion passenger - 安装后我要做什么？
我在 linode 上使用 Ubuntu 10.04，并且安装了 apache2 和 Rails 3.2.2。我的应用程序在 example.com:3000 上运行良好我已按照说明在此处安装 Ph
ruby-on-rails - phusion passenger 没有看到环境变量？
我们正在为我们的 rails 3.0x 应用运行带有 Nginx + Phusion Passenger 的 ubuntu 服务器。我在测试机器上的/etc/environment 中设置了一个环境
mysql - Phusion 乘客 - ActiveRecord::PendingMigrationError
我正在尝试使用 Phusion Passenger 运行简单的 RoR 应用程序。在转到本地主机的那一刻，我看到了主题的错误。事实上，我没有任何待处理的迁移: Status Migrat
ruby-on-rails - Phusion Passenger 正在终止我的进程？
As described here ，我检测到我已被 Phusion Passenger fork ，并恢复一个后台线程，该线程正在聚合一些数据，这些数据最终将在一定时间后打包并发送到远程服务器。但有
ruby-on-rails - 如何单独停止 phusion passenger？
我不知道如何单独停止 phusion passenger。我有 2 个实例，一个在 8000 端口运行，另一个在 8001 端口运行。任何人都可以告诉我如何停止每个代理上的乘客。因为我只需要一个 80

可可西里

个人简介

我是一名优秀的程序员,十分优秀！

作者热门文章

滴滴打车优惠券免费领取

全站热门文章

首页

博学

6Ren·AI

商城

ruby-on-rails - 由于 Phusion Passenger 队列阻塞导致 Web 服务负载过重

Nginx 配置

Mongoid 配置

Sidekiq 配置

更新 1: