Heroku上的Rails應用程序中的隨機超時異常

我在Heroku上託管Rails 3.2應用程序，每天在Rails應用程序中獲取2-3次超時。這些是而不是 H12請求超時，而是發生在Rails棧內某處的超時。因此，他們實際上在網站上生成了例外情況，並出現在我的Airbrake日誌中。Heroku上的Rails應用程序中的隨機超時異常

在超時發生時，它似乎是完全隨機的;有時它在Formtastic之類的寶石中，或在HAML視圖內，或在ActiveRecord代碼中。你可以在這裏看到一些回溯的例子：https://gist.github.com/dpmccabe/5238273

這個網站沒有獲得很多流量，並且在兩個dynos上運行良好（儘管它們自動放大，這要歸功於Adept Scale附加組件）。 HTTP_X_HEROKU_QUEUE_WAIT_TIME標頭通常很低或爲零，所以我不認爲這是一個路由問題。我甚至嘗試從Thin轉換到Unicorn而沒有任何效果（我的unicorn.rb顯示在上面的要點中）。

事實上，這些超時異常似乎在整個應用程序中隨機發生，並沒有讓我有太多的繼續。我確實有New Relic，但我不確定如何去調試這個。有任何想法嗎？

來源

2013-03-25 Devin

這發生在我們的應用程序每天一次或兩次...希望我可以提供更多的幫助，但我在同一條船！ – stereoscott 2013-04-18 02:36:17

+1我也看到這個，在15s/Heroku Cedar的Unicorn/Rails 3.2/Rack-Timeout。如果我能發現它們，我會按照此線程發佈更多細節。 – 2013-05-15 17:56:54

只是好奇：在超時時間內你的平均吞吐量（RPM）是多少？ – KendallB 2013-06-14 16:04:59

根據Heroku Dev Center，如果路由器完成所需的時間超過30秒，路由器將終止該請求。您可以使用rack-timeout gem來查找瓶頸。只是讓你超時少於30秒

Rack::Timeout.timeout = 15 # seconds

如果您有多個並行請求，考慮使用Unicorn

來源

2013-04-20 10:07:15 dpaluy

我也已經運行到了同樣的問題。儘管我還沒有解決這個問題，但我還是認爲我會和我目前看到的一樣。我正在使用機架超時寶石（基於你的回溯，它看起來像你一樣），並將超時設置爲15秒。看看新的文物，任何請求的平均應用服務器響應時間遠低於200毫秒。然而，像你這樣，我每天都會收到看起來像這樣的錯誤2-3：發生在一個廣泛的行動

undefined method `result' for #<Timeout::Error: execution expired>

的錯誤，沒有行動似乎是特別容易產生一個。該錯誤甚至發生在簡單的CRUD DELETE操作上。我在Heroku的Cedar堆棧上運行rails 3.2應用程序。我運行了兩個網絡遊戲機，每個都有3名獨角獸工作人員。他們每個人始終保持低於512mb的限制。

我到目前爲止發現的唯一線索就是我經常看到這樣的靠近我超時以下在我的日誌：

[AMBER] LOG: process 21289 acquired ShareLock on transaction 105259 after 32366.132 ms

你看到類似的東西？數據庫操作鎖定記錄可能導致超時，但我不太確定。

來源

2013-04-26 02:51:36 middkidd

我的應用程序託管在heroku上遇到同樣的問題。

我檢查了日誌，發現很少的請求花了超過30秒的時間處理，這導致了heroku上的超時錯誤。在我的情況下，問題是打印到日誌，我有一個登臺服務器，其中有很多輸入和輸出數據打印到服務器日誌中，打印時間超過30秒，但是，heroku會認爲請求仍在處理中在從遠程API接收到響應之後，因爲它尚未完成將數據打印到日誌。

所以我刪除了所有將打印輸入（輸入由代碼構造的xml數據）和輸出（從api接收到的xml數據）數據到日誌的打印語句。

所以我建議你檢查日誌，看看是否請求時超過30秒，處理
選擇是否打印數據（用於調試目的），需要時間來打印日誌。

再次，這可能不是你的問題的答案，但這是我解決我的問題。希望它有幫助！

來源

2013-07-19 15:37:22

我使用以下關閉日誌記錄： Rack :: Timeout.unregister_state_change_observer（：logger） – 2015-01-28 15:29:42

Heroku上的Rails應用程序中的隨機超時異常

回答

相關問題