我是否正確地在Heroku + Unicorn中預載應用程序？

在Heroku上使用獨角獸時。擴大規模將會產生問題，因爲新的縮放網絡動態碼可以通過請求訪問，當它仍在加載應用程序時。這主要導致Timeout錯誤。我是否正確地在Heroku + Unicorn中預載應用程序？

我沒有使用preload_app true在http://codelevy.com/2010/02/09/getting-started-with-unicorn.html和https://github.com/blog/517-unicorn

的兩篇文章有點閱讀建議。和after_fork和before_fork塊。

在Rails 3+，是before_block的代碼仍然需要？我在某處讀過，否則。誰曾經有過這樣的經歷並願意分享？

我錯過了什麼嗎？我是否正確預裝應用程序？

# config/initializers/unicorn.rb 
# Read from: 
# http://michaelvanrooijen.com/articles/2011/06/01-more-concurrency-on-a-single-heroku-dyno-with-the-new-celadon-cedar-stack/ 
worker_processes 3 # amount of unicorn workers to spin up 
timeout 30   # restarts workers that hang for 90 seconds 

# Noted from http://codelevy.com/2010/02/09/getting-started-with-unicorn.html 
# and https://github.com/blog/517-unicorn 
preload_app true 

after_fork do |server, worker| 
    ActiveRecord::Base.establish_connection 
end 

before_fork do |server, worker| 
    ## 
    # When sent a USR2, Unicorn will suffix its pidfile with .oldbin and 
    # immediately start loading up a new version of itself (loaded with a new 
    # version of our app). When this new Unicorn is completely loaded 
    # it will begin spawning workers. The first worker spawned will check to 
    # see if an .oldbin pidfile exists. If so, this means we've just booted up 
    # a new Unicorn and need to tell the old one that it can now die. To do so 
    # we send it a QUIT. 
    # 
    # Using this method we get 0 downtime deploys. 

    old_pid = Rails.root + '/tmp/pids/unicorn.pid.oldbin' 
    if File.exists?(old_pid) && server.pid != old_pid 
    begin 
     Process.kill("QUIT", File.read(old_pid).to_i) 
    rescue Errno::ENOENT, Errno::ESRCH 
     # someone else did our job for us 
    end 
    end 
end

來源

2012-02-18 Christian Fazzini

你在這裏看到的是預期的。當你通過測功機擴大規模時，Heroku平臺會將這個slu deploy部署到一個新的測功機，這個測功機完全與其他的dynos（即另一個獨角獸大師）隔離。

一旦dyno被部署並運行（有效啓動），路由網格將開始向該dyno發送請求，這是Rails將在Unicorn上啓動的服務器，或者其他設置的服務器。

然而，一旦請求到達時，你有30秒的窗口，返回數據或請求將在路由網（誤差H12）超時。

因此，總結一下，你的問題不是做與派生，它的應用程序可以在30秒，因此早期的超時內啓動。擔心分叉和PID文件不是您在Heroku平臺上需要擔心的問題。

來源

2012-02-20 09:19:25

嗨尼爾。解決方案是預裝應用程序，以防止請求進入，直到dyno（獨角獸主機）完全加載應用程序。我關心的是我是否需要'before_fork'塊中的代碼？ – 2012-02-20 09:31:39

你的before_fork將無法實現。正如我之前所說的，問題在於Heroku路由網格將在您的Unicorn啓動之前向您發送請求。預加載應用程序不會解決此問題。 – 2012-02-20 11:07:53

如果是這樣的話。如何防止在Heroku上旋轉/放大新的Web dynos時發生超時錯誤？ – 2012-02-20 14:08:18

只是部分的答案，但我能減少這種獨角獸配置這些討厭的比例超時：

worker_processes 3 # amount of unicorn workers to spin up 
timeout 30   # restarts workers that hang for 30 seconds 
preload_app true 

# hack: traps the TERM signal, preventing unicorn from receiving it and performing its quick shutdown. 
# My signal handler then sends QUIT signal back to itself to trigger the unicorn graceful shutdown 
# http://stackoverflow.com/a/9996949/235297 
before_fork do |_server, _worker| 
    Signal.trap 'TERM' do 
    puts 'intercepting TERM and sending myself QUIT instead' 
    Process.kill 'QUIT', Process.pid 
    end 
end 

# Fix PostgreSQL SSL error 
# http://stackoverflow.com/a/8513432/235297 
after_fork do |server, worker| 
    defined?(ActiveRecord::Base) and 
    ActiveRecord::Base.establish_connection 
end

還有，我用heroku labs:enable preboot（見https://devcenter.heroku.com/articles/labs-preboot/）。不幸的是，當擴展Web dynos時，我仍然看到一些超時。

這裏是在HireFire支持論壇的討論，我開始：http://hirefireapp.tenderapp.com/discussions/problems/205-scaling-up-and-down-too-quickly-provoking-503s

來源

2012-07-16 14:30:10

遵循相同的方法，並沒有幫助。看來，即使預加載，獨角獸開始「聆聽」和分叉工作人員「準備就緒」之間有一段時間的延遲，對我來說，這是> 30秒，所以即使所有*和*預啓動我都會得到H12錯誤。 – 2012-08-21 23:43:46

preload_app true有助於爲我們的應用程序，所以不要給它一個鏡頭，如果你看到有部署/重新啓動期間超時的問題。評論說這沒有幫助，我認爲這不值得嘗試，然後意識到這確實是我們需要的修復。

我們的情況是使用preboot的緩慢啓動的Rails應用程序。在某些部署和重新啓動時，我們會收到很多超時，直到該網站被我們的正常運行時間監控所認爲的爲止。

我們感悟到與preload_app false，麒麟將首先結合它的端口，然後加載應用程序。只要綁定端口，Heroku就開始發送流量。但是這需要花費一段時間才能加載這個緩慢的應用程序，這樣流量就會超時。

這很容易通過在dev中運行Unicorn來驗證，嘗試在啓動Unicorn後立即訪問站點，並檢查是否在該端口上出現「沒有服務器」類型錯誤（合意）或非常慢的請求希望的）。

如果我們改爲設置preload_app true，那麼直到Unicorn綁定端口需要更長的時間，但一旦它完成並且Heroku發送流量，就可以做出響應。

來源

2017-06-16 07:09:27

我是否正確地在Heroku + Unicorn中預載應用程序？

回答

相關問題