Rails 为什么 unicorn 重启会有一段时间无法正常访问

suupic · 2012年04月05日 · 最后由 hayeah 回复于 2012年04月06日 · 4477 次阅读

unicorn 正常的时候应该能做到无缝重启吧? 为什么我的 unicorn 每次重启时会有近半分钟无法访问,页面呈现空白的正在连接状态?

控制脚本 unicorn.sh

#!/bin/sh 
case "$1" in
  start)         
    unicorn_rails -c config/unicorn.rb -E production -D         
    ;; 
  restart)         
    kill  -USR2 $(cat /var/run/unicorn.pid)         
    ;; 
  stop)         
    kill $(cat /var/run/unicorn.pid)         
    ;; 
  *)         
    echo "Usage:unicorn.sh{start|restart|stop}"        
    ;; 
esac


配置 config/unicorn.rb

# Sample verbose configuration file for Unicorn (not Rack)
#
# This configuration file documents many features of Unicorn
# that may not be needed for some applications. See
# http://unicorn.bogomips.org/examples/unicorn.conf.minimal.rb
# for a much simpler configuration file.
#
# See http://unicorn.bogomips.org/Unicorn/Configurator.html for complete
# documentation.

# Use at least one worker per core if you're on a dedicated server,
# more will usually help for _short_ waits on databases/caches.
worker_processes 4
APP_PATH = "/opt/dev/xxx/"
# Since Unicorn is never exposed to outside clients, it does not need to
# run on the standard HTTP port (80), there is no reason to start Unicorn
# as root unless it's from system init scripts.
# If running the master process as root and the workers as an unprivileged
# user, do this to switch euid/egid in the workers (also chowns logs):
# user "unprivileged_user", "unprivileged_group"

# Help ensure your application will always spawn in the symlinked
# "current" directory that Capistrano sets up.
working_directory APP_PATH # available in 0.94.0+

# listen on both a Unix domain socket and a TCP port,
# we use a shorter backlog for quicker failover when busy
listen "/tmp/.sock", :backlog => 64
listen 8080, :tcp_nopush => false

# nuke workers after 30 seconds instead of 60 seconds (the default)
timeout 30

# feel free to point this anywhere accessible on the filesystem
pid "/var/run/unicorn.pid"

# By default, the Unicorn logger will write to stderr.
# Additionally, ome applications/frameworks log to stderr or stdout,
# so prevent them from going to /dev/null when daemonized here:
stderr_path "/opt/App/unicorn/logs/unicorn.stderr.log"
stdout_path "/opt/App/unicorn/logs/unicorn.stdout.log"

# combine REE with "preload_app true" for memory savings
# http://rubyenterpriseedition.com/faq.html#adapt_apps_for_cow
#preload_app true  #comment this in order to restart unicorn
GC.respond_to?(:copy_on_write_friendly=) and
  GC.copy_on_write_friendly = true

before_fork do |server, worker|
  # the following is highly recomended for Rails + "preload_app true"
  # as there's no need for the master process to hold a connection
  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.connection.disconnect!

  # The following is only recommended for memory/DB-constrained
  # installations.  It is not needed if your system can house
  # twice as many worker_processes as you have configured.
  #
  # # This allows a new master process to incrementally
  # # phase out the old master process with SIGTTOU to avoid a
  # # thundering herd (especially in the "preload_app false" case)
  # # when doing a transparent upgrade.  The last worker spawned
  # # will then kill off the old master process with a SIGQUIT.
  # old_pid = "#{server.config[:pid]}.oldbin"
  old_pid = "#{server.config[:pid]}.oldbin"
   if old_pid != server.pid
     begin
       sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
       Process.kill(sig, File.read(old_pid).to_i)
     rescue Errno::ENOENT, Errno::ESRCH
     end
   end

  # Throttle the master from forking too quickly by sleeping.  Due
  # to the implementation of standard Unix signal handlers, this
  # helps (but does not completely) prevent identical, repeated signals
  # from being lost when the receiving process is busy.
   sleep 1
end

after_fork do |server, worker|
  # per-process listener ports for debugging/admin/migrations
  # addr = "127.0.0.1:#{9293 + worker.nr}"
  # server.listen(addr, :tries => -1, :delay => 5, :tcp_nopush => true)

  # the following is *required* for Rails + "preload_app true",
  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.establish_connection

  # if preload_app is true, then you may also want to check and
  # restart any other shared sockets/descriptors such as Memcached,
  # and Redis.  TokyoCabinet file handles are safe to reuse
  # between any number of forked children (assuming your kernel
  # correctly implements pread()/pwrite() system calls)
end


无缝重启 还是重启了啊.

匿名 #2 · 2012年04月06日

kill -USR2 `cat #{deploy_to}/current/tmp/pids/unicorn.pid` 这样重启后,一会是新部署的页面,一会是老的页面,间歇性的出现,还在调查是什么原因。

我也碰到过这个问题,不知道是啥原因,只能每次部署后手动把原来的 unicorn 进程 kill 掉

kill -QUIT cat ~/application/current/tmp/pids/unicorn.pid.oldbin

http://unicorn.bogomips.org/SIGNALS.html

unicorn 无缝重启有三个步骤

1)kill -USR2 cat ~/application/current/tmp/pids/unicorn.pid

更新应用

2)kill -WINCH cat ~/application/current/tmp/pids/unicorn.pid.oldbin

暂时停止旧的版本。测试更新应用没问题

3) kill -QUIT cat ~/application/current/tmp/pids/unicorn.pid·oldbin

确认后,停止旧的版本

3b) kill -HUP cat ~/application/current/tmp/pids/unicorn.pid.oldbin kill -QUIT cat ~/application/current/tmp/pids/unicorn.pid

如发布失败恢复旧版本

简化重启步骤

kill -USR2 cat ~/application/current/tmp/pids/unicorn.pid kill -QUIT cat ~/application/current/tmp/pids/unicorn.pid·oldbin

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册