23

我的独角兽配置（从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

Ruby 2.0、Rails 3.2、独角兽 4.6.3

4

2 回答 2

10

我们在 Unicorn 上遇到过这样的问题已经有一段时间了。. . 我们也得到了看似随机的超时错误，即使我们从来没有看到太多的负载并且有 4 个 dyno，每个有 4 个工人（我们从来没有任何请求排队）。即使在 Heroku 的帮助下，我们摆脱这些错误的运气也为 0。即使他们对 Heroku 上 Unicorn 的最佳设置没有 100% 的信心，我也能感觉到。

我们最近才切换到 Puma，到目前为止效果非常好，性能要好得多，而且还没有奇怪的超时。我们切换到 Puma 的其他原因之一是我怀疑我们的一些随机超时来自“慢客户端”。. . 独角兽不是为处理慢速客户而设计的。

如果我们看到 Puma 继续取得成功，我会告诉你的，但到目前为止一切都很好。假设您的应用程序是线程安全的，则切换非常轻松。

这是我们正在使用的 puma 设置。我们正在使用“集群模式”。

过程文件：

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 有任何问题，我们会再次通知您。

于 2013-09-06T04:32:45.467 回答
6

我讨厌添加另一个答案，尤其是一个这么简单的答案，但最终为我们解决了这个问题的是删除了“机架超时”宝石。我意识到这可能不是最佳实践，但我很好奇 rack-timeout 和 Unicorn 和/或 Puma 之间是否存在冲突（这很奇怪，因为 Heroku 建议将 rack-timeout 与 Unicorn 一起使用）。

无论如何，Puma 对我们来说工作得很好，但即使在 Puma 升级之后，我们仍然看到一些随机的莫名其妙的超时。. . 但是删除 rack-timeout 完全解决了这个问题。显然，我们仍然会遇到超时，但仅适用于我们尚未优化的代码或者我们使用量很大的情况（基本上是您希望看到超时的时候）。因此，我会将这个问题归咎于 rack-timeout 而不是 Unicorn 。. . 因此与我之前的回答相矛盾:)

希望这可以帮助。如果其他人想在我的理论中戳洞，请随意！

于 2014-09-05T19:47:18.070 回答