Heroku路由器錯誤記錄由LogEntries記錄H13

Question

我想弄清楚我從LogEntries定期獲得的這些錯誤值得擔心。我有一個iPhone應用程序與Heroku上的Rails API進行對話。我使用HireFire來自動增加和減少應用程序需要的dynos和工作器的數量。

我認爲這些erros是由dynos縮小，然後調用該dyno並因此導致H13錯誤引起的。如果是這樣，是否有辦法阻止它？用戶的請求肯定不會不再存在？

這裏是最常見的日誌我在上下文中得到：

2012-10-18 10:01:15.170 209 <13>1 2012-10-18T10:01:14+00:00 app web.1 - - Started GET "/hirefireapp/xxxxxxxxxxxxxxxx/info" for 23.22.73.241 at Thu Oct 18 03:01:14 -0700 2012 
2012-10-18 10:01:15.170 162 <13>1 2012-10-18T10:01:14+00:00 app web.1 - - cache: [GET /hirefireapp/xxxxxxxxxxxxxxxx/info] miss 
2012-10-18 10:01:22.147 146 <13>1 2012-10-18T10:01:22+00:00 app web.2 - - Connected to NewRelic Service at collector-2.newrelic.com:80 
2012-10-18 10:01:22.308 217 <13>1 2012-10-18T10:01:22+00:00 app web.2 - - ** [NewRelic][10/18/12 03:01:22 -0700 xxxxxxxxxxxxxxxx (2)] INFO : Reporting performance data every 60 seconds. 
2012-10-18 10:01:38.118 86 <13>1 2012-10-18T10:01:38+00:00 app web.2 - - 
2012-10-18 10:01:38.212 86 <13>1 2012-10-18T10:01:38+00:00 app web.2 - - 
2012-10-18 10:01:38.212 154 <13>1 2012-10-18T10:01:38+00:00 app web.2 - - Started GET "/" for 204.93.223.151 at Thu Oct 18 03:01:38 -0700 2012 
2012-10-18 10:01:38.212 128 <13>1 2012-10-18T10:01:38+00:00 app web.2 - - Processing by CmsController#index as */* 
2012-10-18 10:01:38.212 148 <13>1 2012-10-18T10:01:38+00:00 app web.2 - - Rendered cms/index.html.erb within layouts/application (4.8ms) 
2012-10-18 10:01:41.291 124 <40>1 2012-10-18T10:01:41+00:00 heroku web.2 - - Stopping all processes with SIGTERM 
2012-10-18 10:01:42.243 217 <158>1 2012-10-18T10:01:42+00:00 heroku router - - Error H13 (Connection closed without response) -> GET my-api.heroku.com/ dyno=web.2 queue= wait= service= status=503 bytes= 

2.

2012-10-16 17:31:25.184 189 <13>1 2012-10-16T17:31:25+00:00 app web.2 - - ** [NewRelic][10/16/12 10:31:25 -0700 (2)] INFO : Dispatcher: thin 
2012-10-16 17:31:25.184 197 <13>1 2012-10-16T17:31:25+00:00 app web.2 - - ** [NewRelic][10/16/12 10:31:25 -0700 (2)] INFO : Application: my-api 
2012-10-16 17:31:25.184 220 <13>1 2012-10-16T17:31:25+00:00 app web.2 - - ** [NewRelic][10/16/12 10:31:25 -0700 (2)] INFO : New Relic Ruby Agent 3.3.1 Initialized: pid = 2 
2012-10-16 17:31:25.585 265 <13>1 2012-10-16T17:31:25+00:00 app web.2 - - ** [NewRelic][10/16/12 10:31:25 -0700 (2)] INFO : NewRelic::Agent::Samplers::DelayedJobLockSampler sampler not available: No DJ worker present 
2012-10-16 17:31:37.068 217 <13>1 2012-10-16T17:31:37+00:00 app web.2 - - ** [NewRelic][10/16/12 10:31:36 -0700 (2)] INFO : Reporting performance data every 60 seconds. 
2012-10-16 17:31:39.786 86 <13>1 2012-10-16T17:31:39+00:00 app web.2 - - 
2012-10-16 17:31:39.884 86 <13>1 2012-10-16T17:31:39+00:00 app web.2 - - 
2012-10-16 17:31:39.884 154 <13>1 2012-10-16T17:31:39+00:00 app web.2 - - Started GET "/" for xxx.xx.xxx.xxx at Tue Oct 16 10:31:39 -0700 2012 
2012-10-16 17:31:39.884 128 <13>1 2012-10-16T17:31:39+00:00 app web.2 - - Processing by CmsController#index as */* 
2012-10-16 17:31:39.981 149 <13>1 2012-10-16T17:31:39+00:00 app web.2 - - Rendered cms/index.html.erb within layouts/application (18.1ms) 
2012-10-16 17:31:46.082 217 <158>1 2012-10-16T17:31:46+00:00 heroku router - - Error H13 (Connection closed without response) -> GET my-api.heroku.com/ dyno=web.2 queue= wait= service= status=503 bytes= 

任何建議，將不勝感激！

感謝 皮特

的H13問題

Answer 1

的一個潛在原因是機架密鑰空間。 Rack通過發送帶有HTTP請求的大量參數密鑰來防止潛在的惡意攻擊。

Rack Utils對65536的密鑰空間設置了一個限制，如果您使用大型參數集發送HTTP請求，該密鑰空間可能不夠大。

您可以通過添加以下到Rails的初始化文件更改此限制：

if Rack::Utils.respond_to?("key_space_limit=") 
    Rack::Utils.key_space_limit = 262144 
end 

我發現這個數字（4倍標準）足夠大，以解決H13問題，但對我來說，你可能需要測試不同根據您自己的個人要求進行設置。

這可能不是您特定H13問題的原因，但值得檢查作爲可能的解決方案。