識別乘客的瓶頸

我們正在爲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/200ms之類的東西來完成，所以幾乎沒有。

我們如何識別瓶頸？

來源

2013-06-28 Hartator

也許'乘客status'就會發現一些有用的信息。 http://www.modrails.com/documentation/Users%20guide%20Apache.html#%5Finspecting%5Fphusion%5Fpassenger%5F8217%5Fs%5Finternal%5Fstatus – acw

這個問題相當含糊，但我會看看我是否可以給你一些指示。

我的第一個猜測是你的應用程序花了很多時間做數據庫相關的東西，請參閱下面的我的建議。

至於奇怪的內存使用情況，您是否正在查看free -ml輸出的正確部分？只是爲了澄清，你想看看-/+ buffers/cache:行來獲得準確的輸出。

您可能還會檢查是否有任何乘客正在懸掛，因爲這是乘客的一個相當普遍的問題。您可以通過在您的乘客上運行strace -p $pid來完成此操作。如果掛起來，它會明顯缺乏「做任何事情」

至於排除在rails本身內的響應時間，我會強烈建議看看使用newrelic（http://newrelic.com/）。通常，您可以通過分解應用程序的每個部分花費多少時間來確定應用程序的哪一部分導致了糟糕的響應時間。這是一個簡單的寶石安裝，一旦你得到報告工作，這對於這樣的問題是非常寶貴的。

來源

2013-06-28 16:30:03 Eugene

最後，瓶頸是乘客，passenger-status是相當有用，顯示隊列左側。

我們的服務器是非常precent所以我們只是增加了乘客的進程數在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-08 14:23:55 Hartator

識別乘客的瓶頸

回答

相關問題