Fehler R12 (Exit Timeout) mit Heroku empfohlenen Unicorn Config

Question

My Unicorn config (kopiert von 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 

Aber jedes Mal, wenn ein dyno neu gestartet wird, bekommen wir diese:

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

Rubin 2.0, Schienen 3.2, Einhorn 4.6.3

Answer 1

Wir hatten solche Probleme mit Unicorn für einige Zeit. . . Wir bekommen auch scheinbar zufällige Timeout-Fehler, obwohl wir nie viel Last sehen und 4 Dynos mit je 4 Arbeitern haben (wir haben nie eine Anfrage in der Warteschlange). Wir hatten Glück, diese Fehler loszuwerden, selbst mit Hilfe von Heroku. Ich habe das Gefühl, selbst wenn sie nicht auf die optimalen Einstellungen für Unicorn auf Heroku vertrauen.

Wir sind erst kürzlich zu Puma gewechselt und bisher so gut, viel bessere Leistung und keine merkwürdigen Timeouts. Einer der anderen Gründe, warum wir zu Puma gewechselt haben, ist, dass ich vermute, dass einige unserer zufälligen Timeouts von "langsamen Clients" kommen. . . Unicorn wurde nicht für langsame Clients entwickelt.

Ich werde Sie wissen lassen, wenn wir weiterhin Erfolg mit Puma sehen, aber so weit so gut. Der Switch ist ziemlich schmerzlos, vorausgesetzt, Ihre App ist Thread-sicher.

Hier sind die Puma-Einstellungen, die wir verwenden. Wir verwenden den "Clustered Mode".

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 

Wir haben derzeit WEB_CONCURRENCY Satz 4 und PUMA_THREADS Satz 5.

Wir keine Initialisierungswerte für DB_POOL verwenden Verwenden Sie einfach die Standardeinstellung DB_POOL von 5 (daher die 5 Threads).

Der einzige Grund, warum wir WEB_CONCURRENCY als Name der Umgebungsvariablen verwenden, ist, dass log2viz die korrekte Anzahl der Worker meldet. Würde es eher PUMA_WORKERS nennen, aber was auch immer, keine große Sache.

Hoffe, das hilft. . . Auch hier werden wir Sie wissen lassen, wenn wir Probleme mit Puma feststellen.

Answer 2

Ich hasse eine andere Antwort hinzuzufügen, vor allem eine dieser einfache, aber letztlich, was fixiert dieses Problem für uns war das Entfernen der ‚Rack-Timeout‘ gem. Ich weiß, dies ist wahrscheinlich nicht am beste Praxis, aber ich bin neugierig, ob es ein Konflikt zwischen Rack-Timeout und Unicorn und/oder Puma (die ungerade ist, weil Heroku Rack-Timeout für die Verwendung mit Einhorn empfiehlt).

Wie dem auch sei Puma arbeitet großartig für uns, aber wir haben noch einige zufällige unerklärliche Timeouts auch nach dem Puma-Upgrade sehen. . . aber das Entfernen der Rack-Timeout löste das Problem vollständig. Offensichtlich erhalten wir noch Timeouts aber nur für Code haben wir nicht optimiert oder, wenn wir starke Beanspruchung bekommen (im Grunde, wenn Sie es erwarten würden Timeouts zu sehen). Also würde ich dieses Problem auf Rack-Timeout und nicht auf Unicorn schieben. . . so widerspricht meine vorherige Antwort :)

Hoffe das hilft. Wenn jemand andere Löcher in meine Theorie stecken will, fühlen Sie sich frei!