独角兽内存使用量几乎占满了所有RAM

16

New Relic进程快照

这里主要有三个问题:

1)Unicorn似乎在稳定地填充所有的内存,导致我不得不手动删除worker。

2)Unicorn似乎会出于某种原因生成额外的worker,尽管我已经指定了固定数量的worker(7个)。这部分导致了内存的积累,也让我不得不手动删除worker。

3)我的零停机部署很不可靠。有时它能够捕捉到变化,有时我会遇到网关超时。每次部署都成为了非常紧张的局面。

我真的不喜欢使用Monit,因为它会在worker完成服务请求之前就把worker杀掉。

那么,这是正常的吗?使用Unicorn进行部署的其他人是否也有同样的问题,即内存无法控制地增长?

还有一个问题是生成的worker数量与定义的worker数量不匹配吗?

另一种替代方法是使用unicorn-worker-killer,在阅读Unicorn Eating Memory之后,我会尝试使用它。

小更新:

enter image description here

所以,New Relic告诉我内存几乎已经达到了95%的时候,我不得不杀掉一个worker。有趣的是,杀死那个worker让内存下降了很多,如下面的图所示。

这是怎么回事?

供参考,这是我的unicorn.rbunicorn_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
你是如何生成这个图表的? - ant
2个回答

11

你似乎存在两个问题:1)优雅重启的协调错误导致旧的 Unicorn 工作进程和旧的主进程仍然存在;2)你的应用程序(而非 Unicorn)存在内存泄漏。

对于前者,查看你的 before_fork 代码,它似乎使用了来自示例配置的内存限制方法。但是,你的 .oldbin 文件名中有一个错别字(多余的反引号),这意味着你从不存在的文件中无法读取 pid,因此无法向旧进程发送信号。

对于后者,你需要进行调查和深入分析。在你的应用程序中寻找会随时间累积数据的缓存语义;仔细检查所有全局变量、类变量和类实例变量的使用情况,这些变量可能会在请求之间保留数据引用。运行一些内存分析以表征你的内存使用情况。你可以通过在工作进程增长到某个上限时杀死它们来减轻内存泄漏;unicorn-worker-killer 可以轻松实现此操作。


谢谢!我会立即修复并回报。感谢您的时间。 - Benjamin Tan Wei Hao
@dbenhur,您能否进一步解释一下“优雅重启”和这种内存限制方法是什么? - tulio84z
@tulio84z 关于优雅重启,请阅读 文档中的“替换正在运行的 unicorn 可执行文件的过程”。对于 unicorn_worker_killer 的商业使用,请阅读许可证 - dbenhur
@dbenhur,如何进行以下操作:“运行一些内存分析来描述您的内存使用情况。” - DelPiero

3

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接