这里有三个问题:
1)独角兽似乎正在稳定地填满所有RAM,导致我手动删除工作.
2)由于某种原因,独角兽似乎正在产生额外的工人,尽管我指定了一定数量的工人(其中7人).这部分是导致RAM累积,这也导致我手动删除工作.
3)在我的情况下,零停机部署是不可靠的.有时它会接收到更改,有时候我会出现网关超时.每个部署变得非常紧张的情况.
我不喜欢使用Monit,因为它会杀死工人,而不用等待工人完成他们的要求.
那是正常的吗?使用Unicorn部署的其他人也有同样的问题,即RAM不可控制地增长?
工人的工人人数是否与所定义的工人人数不符合?
另一个选择是独角兽工人杀手,我将在阅读Unicorn Eating Memory后尝试.
微小的更新:
所以,新遗物告诉我记忆差不多是95%.所以我不得不杀了一个工人.有趣的是,如果从下图中可以看出,那个工人的记忆力会下降很多.
怎么了?
作为参考,这里是我的unicorn.rb和unicorn_init.sh.会有人告诉我,某处有错误.
unicorn.rb
root = "/home/deployer/apps/myapp/current" working_directory root pid "#{root}/tmp/pids/unicorn.pid" stderr_path "#{root}/log/unicorn.stderr.log" stdout_path "#{root}/log/unicorn.log" listen "/tmp/unicorn.myapp.sock" worker_processes 7 timeout 30 preload_app true before_exec do |_| ENV["BUNDLE_GEMFILE"] = '/home/deployer/apps/myapp/current/Gemfile' end before_fork do |server,worker| # Disconnect since the database connection will not carry over if defined? ActiveRecord::Base ActiveRecord::Base.connection.disconnect! end old_pid = "#{root}/tmp/pids/unicorn.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 sleep 1 end after_fork do |server,worker| # Start up the database connection again in the worker if defined?(ActiveRecord::Base) ActiveRecord::Base.establish_connection end Redis.current.quit Rails.cache.reconnect end
unicorn_init.sh
#!/bin/sh set -e # Feel free to change any of the following variables for your app: TIMEOUT=${TIMEOUT-60} APP_ROOT=/home/deployer/apps/myapp/current PID=$APP_ROOT/tmp/pids/unicorn.pid CMD="cd $APP_ROOT; BUNDLE_GEMFILE=/home/deployer/apps/myapp/current/Gemfile bundle exec unicorn -D -c $APP_ROOT/config/unicorn.rb -E production" AS_USER=deployer set -u OLD_PIN="$PID.oldbin" sig () { test -s "$PID" && kill -$1 `cat $PID` } oldsig () { test -s $OLD_PIN && kill -$1 `cat $OLD_PIN` } run () { if [ "$(id -un)" = "$AS_USER" ]; then eval $1 else su -c "$1" - $AS_USER fi } case "$1" in start) sig 0 && echo >&2 "Already running" && exit 0 run "$CMD" ;; stop) sig QUIT && exit 0 echo >&2 "Not running" ;; force-stop) sig TERM && exit 0 echo >&2 "Not running" ;; restart|reload) sig USR2 && echo reloaded OK && exit 0 echo >&2 "Couldn't reload,starting '$CMD' instead" run "$CMD" ;; upgrade) if sig USR2 && sleep 2 && sig 0 && oldsig QUIT then n=$TIMEOUT while test -s $OLD_PIN && test $n -ge 0 do printf '.' && sleep 1 && n=$(( $n - 1 )) done echo if test $n -lt 0 && test -s $OLD_PIN then echo >&2 "$OLD_PIN still exists after $TIMEOUT seconds" exit 1 fi exit 0 fi echo >&2 "Couldn't upgrade,starting '$CMD' instead" run "$CMD" ;; reopen-logs) sig USR1 ;; *) echo >&2 "Usage: $0 <start|stop|restart|upgrade|force-stop|reopen-logs>" exit 1 ;; esac
解决方法
你似乎有两个问题:1)协调重新启动造成旧的独角兽工作者和老师的困难,你们有错误; 2)你的应用程序(不是独角兽)泄漏记忆.
对于前者,看看你的before_fork代码,似乎你正在使用内存限制方法从the example config但是,你有一个打字错误的.oldbin文件名(一个无关的背面滴答在最后),这意味着你永远不会信号旧进程,因为您不能从不存在的文件中读取pid.
对于以后,你将不得不进行调查和钻取.在您的应用程序中查看随时间累积数据的缓存语义;仔细检查所有使用全局变量,类变量和类实例变量,可以从请求请求中保留数据引用.运行一些内存配置文件来表征您的内存使用情况.你可以通过杀死工作人员,当它们长大于某个上限时,来缓解内存泄漏; unicorn-worker-killer使这很容易.