使用Heroku推荐的Unicorn配置错误R12(退出超时)

时间:2013-07-20 15:18:36

标签: ruby-on-rails heroku unicorn

我的Unicorn配置(从Heroku's docs复制):

# 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

但每次重新启动dyno时,我们都会这样:

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

Ruby 2.0,Rails 3.2,Unicorn 4.6.3

2 个答案:

答案 0 :(得分:10)

我们已经有一段时间与Unicorn有过这样的问题了。 。 。我们也看似随机的超时错误,即使我们从来没有看到太多负载,并且每个都有4个dynos,每个4个工作者(我们从来没有任何请求排队)。即使在Heroku的帮助下,我们也没有运气摆脱这些错误。即使他们对Heroku上的Unicorn的最佳设置没有100%的信心,我也感觉到了。

我们刚刚转到Puma,到目前为止这么好,性能好得多,而且没有奇怪的超时。我们转向Puma的另一个原因是我怀疑我们的一些随机超时来自“慢客户”。 。 。 Unicorn不是为处理慢客户而设计的。

如果我们看到Puma继续取得成功,我会告诉你的,但到目前为止还是那么好。假设您的应用程序是线程安全的,那么该开关非常轻松。

以下是我们正在使用的美洲狮设置。我们正在使用“集群模式”。

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使用初始化程序,只使用默认的DB_POOL设置为5(因此是5个线程)。

我们使用WEB_CONCURRENCY作为环境变量名称的唯一原因是log2viz报告正确的工作人员数量。宁愿把它叫做PUMA_WORKERS但不管怎样,不是什么大不了的事。

希望这会有所帮助。 。 。再次,如果我们发现Puma有任何问题,请告知您。

答案 1 :(得分:6)

我讨厌添加另一个答案,尤其是这个简单的答案,但最终解决了这个问题的原因是删除了'rack-timeout'宝石。我意识到这可能不是最好的做法,但我很好奇机架超时和Unicorn和/或Puma之间是否存在冲突(这很奇怪,因为Heroku建议机架超时用于Unicorn)。

无论如何Puma对我们来说很有用,但即使在Puma升级后我们仍然会看到一些随机的莫名其妙的超时。 。 。但删除机架超时完全摆脱了这个问题。显然我们仍然会有超时但只针对我们没有优化的代码,或者我们是否正在大量使用(基本上当你期望看到超时)。因此,我会把这个问题归咎于机架超时而不是Unicorn。 。 。因此与我以前的答案相矛盾:)

希望这会有所帮助。如果有人想在我的理论中挖洞,请随意!