3

我们正在为使用 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 毫秒才能完成，所以几乎没有。

我们如何识别瓶颈？

4

2 回答 2

1

这个问题相当模糊，但我会看看我是否可以给你一些指示。

我的第一个猜测是您的应用程序花费了大量时间来处理与数据库相关的事情，请参阅下面的建议。

至于奇怪的内存使用情况，您是否正在查看free -ml输出的正确部分？只是为了澄清，你想看这-/+ buffers/cache:条线以获得准确的输出。

您还可以检查是否有任何乘客工作人员被吊死，因为这是乘客相当普遍的问题。您可以通过strace -p $pid在乘客工作人员身上运行来做到这一点。如果它挂起，它将明显缺乏“做任何事情”

至于故障排除 rails 本身的响应时间，我强烈建议考虑使用newrelic( http://newrelic.com/ )。您通常可以通过分解应用程序每个部分花费的时间来准确地查看应用程序的哪个部分导致了糟糕的响应时间。这是一个安装简单的 gem，一旦您开始报告工作，它对于此类问题非常宝贵。

于 2013-06-28T16:30:03.710 回答
0

最后，瓶颈是乘客，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;
于 2013-07-08T14:23:55.630 回答