エラーR12（出口タイムアウト）（<a href="https://devcenter.heroku.com/articles/rails-unicorn#adding-unicorn-to-your-application">Heroku's docs</a>からコピー）

Question

私のユニコーンの設定Herokuのの推奨ユニコーンの設定を使用して：

# config/unicorn.rb 
worker_processes Integer(ENV["WEB_CONCURRENCY"] || 3) 
timeout 30 
preload_app true 

before_fork do |server, worker| 
    Signal.trap 'TERM' do 
    puts 'Unicorn master intercepting TERM and sending myself QUIT instead' 
    Process.kill 'QUIT', Process.pid 
    end 

    defined?(ActiveRecord::Base) and 
    ActiveRecord::Base.connection.disconnect! 
end 

after_fork do |server, worker| 
    Signal.trap 'TERM' do 
    puts 'Unicorn worker intercepting TERM and doing nothing. Wait for master to send QUIT' 
    end 

    defined?(ActiveRecord::Base) and 
    ActiveRecord::Base.establish_connection 
end 

しかし、ダイノが再起動されるたびに、私たちはこれを取得：

heroku web.5 - - Error R12 (Exit timeout) -> At least one process failed to exit within 10 seconds of SIGTERM 

ルビー2.0、Rails 3.2、Unicorn 4.6.3

Answer 1

私たちはしばらくUnicornでこのような問題を抱えていました。 。 。たとえ多くの負荷がかかっていなくても、4人の作業員がそれぞれ4つのdynosを持っていても（私たちは決して待ち行列を要求していませんが）、一見無作為なタイムアウトエラーが発生します。ヘロクの助けを借りても、これらのエラーを取り除く運がなかった。私はHerokuのUnicornの最適な設定で100％自信がないと感じています。

私はちょうど最近プーマに切り替えましたが、これまでのところ非常に優れたパフォーマンスと優れたタイムアウトはありませんでした。私がプーマに切り替えた理由の1つは、ランダムタイムアウトの一部が「遅いクライアント」に由来すると思われることです。 。 。 Unicornは遅いクライアントを扱うようには設計されていません。

私は、プーマとの継続的な成功を見ても、それほど良いことを知らせます。あなたのアプリがスレッドセーフであることを前提とすると、スイッチはかなり無痛です。

私たちが使用しているプーマの設定は次のとおりです。私たちは "Clustered Mode"を使用しています。

procfile：

web: bundle exec puma -p $PORT -C ./config/puma.rb 

puma.rb：

environment ENV['RACK_ENV'] 
threads Integer(ENV["PUMA_THREADS"] || 5),Integer(ENV["PUMA_THREADS"] || 5) 

workers Integer(ENV["WEB_CONCURRENCY"] || 4) 
preload_app! 

on_worker_boot do 
    ActiveSupport.on_load(:active_record) do 
    ActiveRecord::Base.establish_connection 
    end 
end 

我々が現在持っているWEB_CONCURRENCYセットセット4へとPUMA_THREADS 5に

我々はDB_POOLのための初期化子を使用していない

5のデフォルトのDB_POOL設定（したがって5つのスレッド）を使用するだけです。

WEB_CONCURRENCYを環境変数名として使用している唯一の理由は、log2vizが正しいワーカー数を報告するためです。むしろそれをPUMA_WORKERSと呼ぶでしょうが、それは大したことではありません。

これが役に立ちます。 。 。また、私たちがプーマに問題があるかどうかを知らせます。

Answer 2

もう1つの回答、特にこの1つを追加するのは嫌いですが、最終的にはこの問題は「ラックタイムアウト」の宝石を取り除くために修正されました。これはおそらくベストプラクティスではないが、ラックタイムアウトとUnicornやPumaの間に矛盾があるのは不思議です（HerokuはUnicornでの使用のためにラックタイムアウトを推奨しているので奇妙です）。

とにかくプーマは私たちのためにうまくいっていますが、プーマのアップグレード後もまだ説明できないタイムアウトがあります。 。 。ラックタイムアウトを取り除くと問題は完全に解消されました。明らかにタイムアウトが発生しますが、最適化されていないコードや、使用量が多くなっている場合（基本的にタイムアウトが発生すると予想される場合）に限ります。したがって、私はこの問題をUnicornではなく、ラックタイムアウトに責めます。 。 。私の前の答えと矛盾しています:)

これは役に立ちます。他の誰かが私の理論に穴をあけたいと思ったら、自由に感じてください！