我们正在为使用 nginx/passenger 部署的 rails 应用运行一个大型服务器（12 个线程、6 个内核、64Gb 内存、2 个 SDDs raid-0）。
不幸的是，页面加载时间大约在 10 到 40 秒之间。但是，服务器的负载非常轻，平均负载为0.61 0.56 0.53。我们奇怪地使用了 ram，free -ml 报告了 57Gb（64Gb）的使用，而htop 只报告了 4Gb（64Gb）。
我们检查了生产日志，rails 请求需要大约 100/200 毫秒才能完成，所以几乎没有。
我们如何识别瓶颈？
【问题讨论】：
passenger-status 会透露一些有用的信息。 modrails.com/documentation/…
标签： ruby-on-rails ruby nginx passenger
这个问题比较模糊，但我看看能不能给你一些指点。
我的第一个猜测是您的应用程序花费大量时间来处理与数据库相关的事情，请参阅下面的建议。
至于奇怪的内存使用情况，您是否查看了free -ml 输出的正确部分？澄清一下，您希望查看-/+ buffers/cache: 行以获得准确的输出。
您还可以检查是否有任何乘客工作人员被吊死，因为这是乘客相当普遍的问题。您可以通过在您的乘客工作人员上运行 strace -p $pid 来做到这一点。如果它挂了，它会明显缺乏“做任何事情”
至于解决 Rails 本身的响应时间问题，我强烈建议考虑使用 newrelic(http://newrelic.com/)。您通常可以通过分解应用程序每个部分花费的时间来准确地查看应用程序的哪个部分导致了糟糕的响应时间。这是一个安装简单的 gem，一旦您开始报告工作，它对于此类问题非常宝贵。
【讨论】：
最后，瓶颈是乘客，passenger-status 在显示左侧队列时非常有用。
我们的服务器非常新，所以我们只是将nginx.conf 中的乘客进程数增加到 600，结果：
passenger_root /usr/local/rvm/gems/ruby-2.0.0-p195/gems/passenger-4.0.5;
passenger_ruby /usr/local/rvm/wrappers/ruby-2.0.0-p195/ruby;
passenger_max_pool_size 600;
【讨论】：