我的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
答案 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。 。 。因此与我以前的答案相矛盾:)
希望这会有所帮助。如果有人想在我的理论中挖洞,请随意!