我们正在为使用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 / 200ms才能完成，所以几乎没有。
我们如何识别瓶颈？
答案 0 :(得分：1)
这个问题相当含糊，但我会看看能否给你一些指示。
我的第一个猜测是你的应用花了很多时间做数据库相关的事情，请参阅下面的建议。
至于奇数内存使用情况，您是否正在查看free -ml输出的正确部分？只是为了澄清，您希望查看-/+ buffers/cache:行以获得准确的输出。
您可能还会检查您的乘客是否有人悬挂，因为这对乘客来说是一个相当普遍的问题。您可以通过对乘客工作人员strace -p $pid运行来完成此操作。如果它悬挂，它将明显缺乏“做任何事情”
至于排除rails内部响应时间的问题，我强烈建议您使用newrelic（http://newrelic.com/）。通过分解应用程序的每个部分花费的时间，您经常可以确切地看到应用程序的哪个部分导致错误的响应时间。这是一个简单的宝石安装，一旦你报告工作，它对这样的问题非常宝贵。
答案 1 :(得分：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;