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

imd*_*rek 22 ruby-on-rails heroku unicorn

我的Unicorn配置(从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
Run Code Online (Sandbox Code Playgroud)

但每次重新启动dyno时,我们都会得到:

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

Ruby 2.0,Rails 3.2,Unicorn 4.6.3

bcb*_*bcb 10

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

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

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

这是我们正在使用的美洲狮设置.我们正在使用"集群模式".

procfile:

web: bundle exec puma -p $PORT -C ./config/puma.rb
Run Code Online (Sandbox Code Playgroud)

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
Run Code Online (Sandbox Code Playgroud)

我们目前WEB_CONCURRENCY设置为4并PUMA_THREADS设置为5.

我们没有使用DB_POOL的初始化程序,只使用默认的DB_POOL设置5(因此5个线程).

我们WEB_CONCURRENCY用作环境变量名称的唯一原因是log2viz报告正确的工作人员数量.宁愿叫它,PUMA_WORKERS但无论如何,不​​是一个大问题.

希望这可以帮助 ...如果我们发现Puma有任何问题,请再次通知您.

  • 为了记录,我使用Puma,我有同样奇怪的超时和R12错误.没错,比其他服务器更少,但仍然如此. (3认同)

bcb*_*bcb 6

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

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

希望这可以帮助.如果有人想在我的理论中挖洞,请随意!