ThinkChat2.0新版上线,更智能更精彩,支持会话、画图、阅读、搜索等,送10W Token,即刻开启你的AI之旅 广告
# Understanding Unicorn and unicorn-worker-killer > 原文:[https://docs.gitlab.com/ee/administration/operations/unicorn.html](https://docs.gitlab.com/ee/administration/operations/unicorn.html) * [Unicorn](#unicorn) * [Tunable options](#tunable-options) * [unicorn-worker-killer](#unicorn-worker-killer) # Understanding Unicorn and unicorn-worker-killer[](#understanding-unicorn-and-unicorn-worker-killer "Permalink") **注意:**从 GitLab 13.0 开始,Puma 是基于 GitLab 多合一软件包的安装以及 GitLab Helm 图表部署中使用的默认 Web 服务器. ## Unicorn[](#unicorn "Permalink") GitLab uses [Unicorn](https://yhbt.net/unicorn/), a pre-forking Ruby web server, to handle web requests (web browsers and Git HTTP clients). Unicorn is a daemon written in Ruby and C that can load and run a Ruby on Rails application; in our case the Rails application is GitLab Community Edition or GitLab Enterprise Edition. Unicorn 具有多进程架构,可以更好地利用可用的 CPU 内核(进程可以在不同的内核上运行),并具有更强的容错能力(大多数故障仅隔离在一个进程中,无法完全关闭 GitLab). 启动时,Unicorn 的"主"进程使用 GitLab 应用程序代码加载一个干净的 Ruby 环境,然后生成继承此干净的初始环境的"工人". "主人"从不处理任何留给工人的请求. 操作系统网络堆栈将传入的请求排队,并在工作进程之间分配它们. 在一个理想的世界中,主服务器将生成一个工人池,然后工人依次处理传入的 Web 请求,直到时间结束. 实际上,工作进程可能崩溃或超时:如果主服务器注意到工作时间过长,无法处理请求,它将以 SIGKILL(" kill -9")终止工作进程. 无论工作进程如何结束,主进程都将再次用新的"干净"进程替换它. Unicorn 的设计宗旨是能够替换"崩溃的"工人,而无需放弃用户的要求. 这就是`unicorn_stderr.log`的 Unicorn worker 超时. 主过程具有下面的 PID 56227. ``` [2015-06-05T10:58:08.660325 #56227] ERROR -- : worker=10 PID:53009 timeout (61s > 60s), killing [2015-06-05T10:58:08.699360 #56227] ERROR -- : reaped #<Process::Status: pid 53009 SIGKILL (signal 9)> worker=10 [2015-06-05T10:58:08.708141 #62538] INFO -- : worker=10 spawned pid=62538 [2015-06-05T10:58:08.708824 #62538] INFO -- : worker=10 ready ``` ### Tunable options[](#tunable-options "Permalink") Unicorn 的主要可调选项是工作进程数和请求超时,之后 Unicorn 主服务器终止工作进程. 如果要调整这些设置,请参见[Omnibus GitLab Unicorn 设置文档](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/unicorn.html) . ## unicorn-worker-killer[](#unicorn-worker-killer "Permalink") GitLab 内存泄漏. 这些内存泄漏在长时间运行的进程(例如 Unicorn 工作者)中表现出来. (不知道 Unicorn 主进程会泄漏内存,可能是因为它无法处理用户请求.) 为了使这些内存泄漏易于管理,GitLab 随附了[unicorn-worker-killer gem](https://github.com/kzk/unicorn-worker-killer) . 每隔 16 个请求,这只宝石[猴就会](https://en.wikipedia.org/wiki/Monkey_patch)给独角兽工人打[补丁](https://en.wikipedia.org/wiki/Monkey_patch)以进行内存自检. 如果 Unicorn worker 的内存超过预设限制,则退出 worker 进程. 然后,Unicorn 主服务器自动替换工作进程. 这是处理内存泄漏的可靠方法:Unicorn 旨在处理"崩溃"的工作程序,因此不会丢弃任何用户请求. unicorn-worker-killer gem 被设计为仅*在请求之间*终止工作进程,因此不会影响用户请求. 您可以通过设置以下值`/etc/gitlab/gitlab.rb`来设置 Unicorn worker killer 的最小和最大内存阈值(以字节为单位): * 对于 GitLab **12.7**及更高版本: ``` unicorn['worker_memory_limit_min'] = "1024 * 1 << 20" unicorn['worker_memory_limit_max'] = "1280 * 1 << 20" ``` * 对于 GitLab **12.6**及更高版本: ``` unicorn['worker_memory_limit_min'] = "400 * 1 << 20" unicorn['worker_memory_limit_max'] = "650 * 1 << 20" ``` 否则,您可以设置`GITLAB_UNICORN_MEMORY_MIN`和`GITLAB_UNICORN_MEMORY_MAX` [环境变量](../environment_variables.html) . 这就是 Unicorn_stderr.log 中的 Unicorn 工作程序内存重新启动的样子. 您看到工作程序 4(PID 125918)正在检查自己并决定退出. 内存阈值是 254802235 字节,大约 250MB. 对于 GitLab,此阈值是 200 到 250 MB 之间的随机值. 然后,主进程(PID 117565)接收工作进程,并生成具有 PID 127549 的新"工作进程 4". ``` [2015-06-05T12:07:41.828374 #125918] WARN -- : #<Unicorn::HttpServer:0x00000002734770>: worker (pid: 125918) exceeds memory limit (256413696 bytes > 254802235 bytes) [2015-06-05T12:07:41.828472 #125918] WARN -- : Unicorn::WorkerKiller send SIGQUIT (pid: 125918) alive: 23 sec (trial 1) [2015-06-05T12:07:42.025916 #117565] INFO -- : reaped #<Process::Status: pid 125918 exit 0> worker=4 [2015-06-05T12:07:42.034527 #127549] INFO -- : worker=4 spawned pid=127549 [2015-06-05T12:07:42.035217 #127549] INFO -- : worker=4 ready ``` 从 GitLab.com 上摘录的另一段日志摘要是," worker 4"仅在 23 秒内处理请求. 对于我们当前的 GitLab.com 设置和流量,这是正常值. 在某些 GitLab 网站上,独角兽内存重新启动的频率很高,可能会使管理员感到困惑. 通常他们是[红鲱鱼](https://en.wikipedia.org/wiki/Red_herring) .