ruby-on-rails - 确定乘客的瓶颈

Question

我们正在为使用 nginx/passenger 部署的 Rails 应用程序运行一个大型服务器(12 线程、6 核、64Gb 内存、2 个 SDD raid-0)。

不幸的是，页面永远需要 10 到 40 秒才能加载。但是，服务器的负载非常轻，平均负载为 0.61 0.56 0.53。我们奇怪地使用了 ram，free -ml 报告使用了 57Gb(共 64Gb)，而 htop 报告仅使用了 4Gb(共 64Gb)。

我们检查了我们的生产日志，rails 请求需要大约 100/200 毫秒才能完成，所以几乎没有。

我们如何识别瓶颈？

Answer 1

这个问题比较含糊，但我看看能不能给你一些指点。

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

至于奇怪的内存使用情况，您是否查看了 free -ml 输出的正确部分？澄清一下，您需要查看 -/+ buffers/cache: 行以获得准确的输出。

您还可以检查是否有乘客工作人员被吊死，因为这对乘客来说是一个相当普遍的问题。您可以通过在乘客工作人员上运行 strace -p $pid 来完成此操作。如果挂了，就会明显缺乏“做任何事”

至于在 rails 本身内解决响应时间问题，我强烈建议考虑使用 newrelic( http://newrelic.com/ )。通过分解应用程序每个部分花费的时间，您通常可以准确地看到应用程序的哪个部分导致了糟糕的响应时间。它是一个易于安装的 gem，一旦您开始使用报告，它对于此类问题的值(value)将是无可估量的。