Understanding Unicorn and unicorn-worker-killer · Gitlab 中文文檔

# 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) .