使用 Heroku 推荐的 Unicorn 配置时出现错误 R12（退出超时）答案

【问题标题】：Error R12 (Exit timeout) using Heroku's recommended Unicorn config使用 Heroku 推荐的 Unicorn 配置时出现错误 R12（退出超时）
【发布时间】：2013-07-19 18:39:51
【问题描述】：

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

但是每次重新启动测功机时，我们都会得到：

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

【问题讨论】：

您的负载或请求队列很大？还是设置了一些终结器？
没有终结器。平均请求队列约为 150 毫秒。
我也有同样的问题，找到解决办法了吗？
还没有，很遗憾。我可能需要就此联系 Heroku 支持，尽管这很少被证明非常有用。
好吧。请告诉我进展如何！

标签： ruby-on-rails heroku unicorn

【解决方案1】：

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

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

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

【讨论】：

当我们推出我们的产品时，我们只使用了直接 RACK 3 个月。没有问题。我决定升级到 Unicorn 以获得更好的可扩展性，并立即表示看到超时和内存警告。我花了 2 周时间对所有内容进行微调......所有资产都来自 CDN，在部署之前进行预编译，检查 gem，针对生产数据库分析内存泄漏，缓存几乎所有内容，应用程序仍然从 Logentries 抛出这些错误。所以就像 bcb 所说，我认为它们只是有时会发生。
@bcb - 对 Puma 还满意吗？我们在 Heroku 上看到 Unicorn 出现奇怪的超时，所以我想试试 Puma。
为了记录，我使用 Puma，我有同样奇怪的超时和 R12 错误。没错，比其他服务器少，但仍然如此。
Heroku 现在推荐 Puma，请参阅：devcenter.heroku.com/articles/…github.com/heroku/ruby-getting-started/commits/master/Procfile
flask/python 上有哪些 Gunicorn 的替代品？

【解决方案2】：

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

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

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

【讨论】：