ruby on rails - rails - Error R12(Tiempo de espera de salida) usando la configuración Unicornio recomendada de Heroku

heroku dashboard login

Question

Configuración de Mi Unicornio (copiada de los documentos de 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

Pero cada vez que se reinicia un banco de pruebas, obtenemos esto:

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

Answer 1

Hemos tenido problemas como este con Unicornio por algún tiempo. . . también obtenemos errores de tiempo de espera aparentemente aleatorios, a pesar de que nunca vemos mucha carga y tenemos 4 dynos con 4 trabajadores cada uno (nunca tenemos ninguna cola de solicitudes). Hemos tenido 0 suerte para deshacernos de estos errores, incluso con la ayuda de Heroku. Me da la sensación de que incluso no están 100% seguros de la configuración óptima para Unicorn en Heroku.

Recientemente cambiamos a Puma y hasta ahora hemos tenido un rendimiento mucho mejor y sin tiempos de espera extraños. Una de las otras razones por las que cambiamos a Puma es porque sospecho que algunos de nuestros tiempos de espera aleatorios provienen de "clientes lentos". . . Unicorn no está diseñado para manejar clientes lentos.

Te lo haré saber si vemos un éxito continuo con Puma, pero hasta ahora todo va bien. El cambio es bastante sencillo, suponiendo que su aplicación es segura para subprocesos.

Aquí están los ajustes de puma que estamos usando. Estamos usando "Modo agrupado".

archivo de 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

Actualmente tenemos WEB_CONCURRENCY establecido en 4 y PUMA_THREADS establecido en 5.

No estamos usando un inicializador para DB_POOL, simplemente usando la configuración predeterminada DB_POOL de 5 (de ahí los 5 subprocesos).

La única razón por la que estamos usando WEB_CONCURRENCY como nuestro nombre de variable de entorno es para que log2viz informe la cantidad correcta de trabajadores. Preferiría llamarlo PUMA_WORKERS pero lo que sea, no es un gran problema.

Espero que esto ayude . . . Nuevamente, le haremos saber si vemos algún problema con Puma.

Answer 2

Odio agregar otra respuesta, especialmente una así de simple, pero al final lo que solucionó este problema para nosotros fue eliminar la gema ''rack-timeout''. Me doy cuenta de que probablemente esta no sea la mejor práctica, pero tengo curiosidad si hay algún conflicto entre rack-timeout y Unicorn y / o Puma (lo cual es extraño porque Heroku recomienda rack-timeout para usar con Unicorn).

De todos modos, Puma está funcionando muy bien para nosotros, pero aun así vimos algunos tiempos de espera aleatorios e inexplicables incluso después de la actualización de Puma. . . pero al eliminar el tiempo de espera de rack se eliminó por completo el problema. Obviamente, todavía tenemos tiempos de espera, pero solo para el código que no hemos optimizado o si estamos recibiendo un uso intensivo (básicamente, cuando esperaríamos ver tiempos de espera). Por lo tanto, culpo a este problema por el tiempo de espera de rack y no por el Unicornio. . . contradiciendo así mi respuesta anterior :)

Espero que esto ayude. Si alguien más quiere abrir agujeros en mi teoría, ¡siéntete libre!