Run multiple Sidekiq processes · Gitlab 中文文檔

# Run multiple Sidekiq processes > 原文：[https://docs.gitlab.com/ee/administration/operations/extra_sidekiq_processes.html](https://docs.gitlab.com/ee/administration/operations/extra_sidekiq_processes.html) * [Available Sidekiq queues](#available-sidekiq-queues) * [Start multiple processes](#start-multiple-processes) * [Negate settings](#negate-settings) * [Queue selector (experimental)](#queue-selector-experimental) * [Available attributes](#available-attributes) * [Available operators](#available-operators) * [Example queries](#example-queries) * [Disable Sidekiq cluster](#disable-sidekiq-cluster) * [Ignore all GitHub import queues](#ignore-all-github-import-queues) * [Number of threads](#number-of-threads) * [Manage concurrency](#manage-concurrency) * [When running Sidekiq cluster (default)](#when-running-sidekiq-cluster-default) * [When running a single Sidekiq process](#when-running-a-single-sidekiq-process) * [Modify the check interval](#modify-the-check-interval) * [Troubleshoot using the CLI](#troubleshoot-using-the-cli) * [Monitor the `sidekiq-cluster` command](#monitor-the-sidekiq-cluster-command) * [PID files](#pid-files) * [Environment](#environment) # Run multiple Sidekiq processes[](#run-multiple-sidekiq-processes-core-only "Permalink") GitLab 允許您啟動多個 Sidekiq 進程. 這些過程可用于消耗一組專用隊列. 這可以用來確保某些隊列始終具有專用的工作程序，而不管需要處理的作業數量如何. **注意：**此頁面中的信息僅適用于 Omnibus GitLab. ## Available Sidekiq queues[](#available-sidekiq-queues "Permalink") For a list of the existing Sidekiq queues, check the following files: * [Queues for both GitLab Community and Enterprise Editions](https://gitlab.com/gitlab-org/gitlab/blob/master/app/workers/all_queues.yml) * [Queues for GitLab Enterprise Editions only](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/workers/all_queues.yml) 以上文件中的每個條目都代表一個隊列，可以在其上啟動 Sidekiq 進程. ## Start multiple processes[](#start-multiple-processes "Permalink") 版本歷史 * 在 GitLab 12.10 中[引入](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4006) ，使用 Sidekiq 集群啟動多個進程. * [Sidekiq 集群移至](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/181) GitLab 12.10 中的 GitLab [Core](https://about.gitlab.com/pricing/#self-managed) . * [Sidekiq 集群](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4140)在 GitLab 13.0 中[成為默認設置](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4140) . To start multiple processes: 1. 使用`sidekiq['queue_groups']`數組設置，指定使用`sidekiq-cluster`創建多少個進程以及它們應處理的隊列. 數組中的每個項目都相當于一個附加的 Sidekiq 進程，并且每個項目中的值確定了它要處理的隊列. 例如，以下設置創建三個 Sidekiq 過程，一到上運行`elastic_indexer` ，一到上運行`mailers` ，以及一個進程中運行的所有的隊列： ``` sidekiq['queue_groups'] = [ "elastic_indexer", "mailers", "*" ] ``` 要讓附加的 Sidekiq 進程處理多個隊列，請將多個隊列名稱添加到其項目中，并以逗號分隔. 例如： ``` sidekiq['queue_groups'] = [ "elastic_indexer, elastic_commit_indexer", "mailers", "*" ] ``` [在 GitLab 12.9](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26594)和更高版本中，特殊隊列名稱`*`表示所有隊列. 這將啟動兩個進程，每個進程處理所有隊列： ``` sidekiq['queue_groups'] = [ "*", "*" ] ``` `*`不能與具體的隊列名稱結合使用- `*, mailers`將只處理`mailers`隊列. 當`sidekiq-cluster`僅在單個節點上運行時，請使用`*`確保在所有隊列上至少運行一個進程. 這意味著一個進程將自動在將來創建的隊列中拾取作業. 如果`sidekiq-cluster`在多個節點上運行，則還可以使用[`--negate`](#negate-settings)并列出所有已在處理的隊列. 2. 保存文件并重新配置 GitLab，以使更改生效： ``` sudo gitlab-ctl reconfigure ``` 添加了額外的 Sidekiq 進程后，導航至 GitLab 中的**管理區域>監視>后臺作業** （ `/admin/background_jobs` ）. [![Multiple Sidekiq processes](https://img.kancloud.cn/da/78/da7819e483291739564955a898175f4a_781x300.png)](img/sidekiq-cluster.png) ## Negate settings[](#negate-settings "Permalink") 若要使其他 Sidekiq 進程在您列出的隊列**之外**的每個隊列上工作： 1. 在按照步驟[啟動額外的流程之后](#start-multiple-processes) ，請編輯`/etc/gitlab/gitlab.rb`并添加： ``` sidekiq['negate'] = true ``` 2. 保存文件并重新配置 GitLab，以使更改生效： ``` sudo gitlab-ctl reconfigure ``` ## Queue selector (experimental)[](#queue-selector-experimental "Permalink") [Introduced](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/45) in [GitLab Starter](https://about.gitlab.com/pricing/) 12.8. **注意：**由于這被標記為**實驗性的** ，因此隨時可能更改，包括**破壞向后兼容性** . 這樣我們就可以對 GitLab.com 部署所需的更改做出反應. 我們存在一個跟蹤問題，希望從此功能中[刪除實驗性名稱](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/147) ；如果您有興趣在自己的部署中使用它，請在此處發表評論. 除了按名稱選擇隊列之外，如上所述， `experimental_queue_selector`選項還允許使用以下組件以更通用的方式選擇隊列組： * 可以選擇的屬性. * 用于構造查詢的運算符. ### Available attributes[](#available-attributes "Permalink") * 在 GitLab 13.1 中[引入](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/261) ， `tags` . 從[所有可用屬性](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/all_queues.yml)的[列表中](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/all_queues.yml) ， `experimental_queue_selector`允許通過以下屬性選擇隊列： * `feature_category`隊列所屬的[GitLab 功能類別](https://about.gitlab.com/direction/maturity/#category-maturity) . 例如， `merge`隊列屬于`source_code_management`類別. * `has_external_dependencies`隊列是否連接到外部服務. 例如，所有進口商都將此設置為`true` . * `urgency` -快速運行此隊列的重要性. 可以`high` ， `low`或`throttled` . 例如， `authorized_projects`隊列用于刷新用戶權限，并且緊急度很高. * `name` -隊列名. 其他屬性通常更有用，因為它們更通用，但這在需要選擇特定隊列的情況下可用. * `resource_boundary`如果隊列受`cpu` ， `memory`或`unknown`綁定. 例如， `project_export`隊列受內存限制，因為它必須先將數據加載到內存中，然后再保存以進行導出. * `tags` -隊列的短暫注釋. 預計這些版本會在發行版本之間頻繁更改，并且可能會完全刪除. `has_external_dependencies`是布爾值屬性：只有確切的字符串`true`才被視為 true，其他所有內容都被視為 false. `tags`是一個集合，這意味著`=`檢查相交的集合，而`!=`檢查不相交的集合. 例如， `tags=a,b`選擇具有標簽`a` ， `b`或兩者都有的隊列. `tags!=a,b`選擇沒有這些標簽的隊列. ### Available operators[](#available-operators "Permalink") `experimental_queue_selector`支持以下運算符，從最高優先級到最低優先級列出： * `|` -邏輯或運算符. 例如， `query_a|query_b` （此處的`query_a`和`query_b`是由其他運算符組成的查詢）將包括與任一查詢匹配的隊列. * `&` -邏輯 AND 運算符. 例如， `query_a&query_b` （此處的`query_a`和`query_b`是由其他運算符組成的查詢）將僅包括與兩個查詢均匹配的隊列. * `!=` -NOT IN 運算符. 例如， `feature_category!=issue_tracking`將所有隊列排除在`issue_tracking`功能類別之外. * `=` -IN 運算符. 例如， `resource_boundary=cpu`包括所有受 CPU 約束的隊列. * `,` -串聯集合運算符. 例如， `feature_category=continuous_integration,pages`包含來自`continuous_integration`類別或`pages`類別的所有隊列. 使用 OR 運算符也可以使用此示例，但是它具有更高的簡潔性，并且具有較低的優先級. 此語法的運算符優先級是固定的：不可能使 AND 的優先級高于 OR. [In GitLab 12.9](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26594) and later, as with the standard queue group syntax above, a single `*` as the entire queue group selects all queues. ### Example queries[](#example-queries "Permalink") In `/etc/gitlab/gitlab.rb`: ``` sidekiq['enable'] = true sidekiq['experimental_queue_selector'] = true sidekiq['queue_groups'] = [ # Run all non-CPU-bound queues that are high urgency 'resource_boundary!=cpu&urgency=high', # Run all continuous integration and pages queues that are not high urgency 'feature_category=continuous_integration,pages&urgency!=high', # Run all queues '*' ] ``` ### Disable Sidekiq cluster[](#disable-sidekiq-cluster "Permalink") **警告：**在 GitLab 14.0 中， [計劃](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/240)將 Sidekiq 群集作為啟動 Sidekiq 的唯一方法. 默認情況下，Sidekiq 服務將運行`sidekiq-cluster` . 若要禁用此行為，請將以下內容添加到 Sidekiq 配置中： ``` sidekiq['enable'] = true sidekiq['cluster'] = false ``` 所有上述提及的`sidekiq`配置選項均可用. 默認情況下，它們的配置如下： ``` sidekiq['experimental_queue_selector'] = false sidekiq['interval'] = nil sidekiq['max_concurrency'] = 50 sidekiq['min_concurrency'] = nil sidekiq['negate'] = false sidekiq['queue_groups'] = ['*'] sidekiq['shutdown_timeout'] = 25 ``` 如果您決定如上所述配置集群，則必須禁用`sidekiq_cluster` . 禁用`sidekiq_cluster` ，必須將`sidekiq_cluster`的配置復制到`sidekiq` . 任何配置成用于`sidekiq_cluster`將被覆蓋由用于選項`sidekiq`設定時`sidekiq['cluster'] = true` . 使用此功能時，名為`sidekiq`的服務現在將在運行`sidekiq-cluster` . 將遵守為 Sidekiq 配置的[并發](#manage-concurrency)和其他選項. 默認情況下， `sidekiq-cluster` `/var/log/gitlab/sidekiq`像常規的 Sidekiq 日志一樣進入`/var/log/gitlab/sidekiq` . ## Ignore all GitHub import queues[](#ignore-all-github-import-queues "Permalink") [從 GitHub 導入時](../../user/project/import/github.html) ，Sidekiq 可能會使用其所有資源來執行那些操作. 要設置一個單獨的`sidekiq-cluster`進程以忽略所有與 GitHub 導入相關的隊列： 1. 編輯`/etc/gitlab/gitlab.rb`并添加： ``` sidekiq['enable'] = true sidekiq['negate'] = true sidekiq['queue_groups'] = [ "github_import_advance_stage", "github_importer:github_import_import_diff_note", "github_importer:github_import_import_issue", "github_importer:github_import_import_note", "github_importer:github_import_import_lfs_object", "github_importer:github_import_import_pull_request", "github_importer:github_import_refresh_import_jid", "github_importer:github_import_stage_finish_import", "github_importer:github_import_stage_import_base_data", "github_importer:github_import_stage_import_issues_and_diff_notes", "github_importer:github_import_stage_import_notes", "github_importer:github_import_stage_import_lfs_objects", "github_importer:github_import_stage_import_pull_requests", "github_importer:github_import_stage_import_repository" ] ``` 2. 保存文件并重新配置 GitLab，以使更改生效： ``` sudo gitlab-ctl reconfigure ``` ## Number of threads[](#number-of-threads "Permalink") 在`sidekiq`下定義的每個進程都以等于隊列數的線程數開始，再加上一個備用線程. 例如，處理`process_commit`和`post_receive`隊列的進程將總共使用三個線程. ## Manage concurrency[](#manage-concurrency "Permalink") 設置最大并發數時，請記住，這通常不應超過可用的 CPU 內核數. 以下示例中的值是任意的，不是特別的建議. Each thread requires a Redis connection, so adding threads may increase Redis latency and potentially cause client timeouts. See the [Sidekiq documentation about Redis](https://github.com/mperham/sidekiq/wiki/Using-Redis) for more details. ### When running Sidekiq cluster (default)[](#when-running-sidekiq-cluster-default "Permalink") 在 GitLab 13.0 和更高版本中，默認運行 Sidekiq 群集. 1. 編輯`/etc/gitlab/gitlab.rb`并添加： ``` sidekiq['min_concurrency'] = 15 sidekiq['max_concurrency'] = 25 ``` 2. 保存文件并重新配置 GitLab，以使更改生效： ``` sudo gitlab-ctl reconfigure ``` `min_concurrency`和`max_concurrency`是獨立的；一個可以不設置另一個. 將`min_concurrency`設置為 0 將禁用該限制. 對于每個隊列組，令 N 為隊列數多一. 并發因子將設置為： 1. `N` ，如果它介于`min_concurrency`和`max_concurrency`之間. 2. `max_concurrency` ，如果`N`超過此值. 3. `min_concurrency` ，如果`N`小于此值. 如果`min_concurrency`等于`max_concurrency` ，那么無論隊列數量如何，都將使用此值. 當`min_concurrency`大于`max_concurrency` ，它將被視為等于`max_concurrency` . ### When running a single Sidekiq process[](#when-running-a-single-sidekiq-process "Permalink") 在 GitLab 12.10 及更早版本中，默認運行單個 Sidekiq 進程. **警告：**計劃在 GitLab [14.0 中](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/240)刪除直接運行 Sidekiq. 1. 編輯`/etc/gitlab/gitlab.rb`并添加： ``` sidekiq['cluster'] = false sidekiq['concurrency'] = 25 ``` 2. 保存文件并重新配置 GitLab，以使更改生效： ``` sudo gitlab-ctl reconfigure ``` 這將設置 Sidekiq 進程的并發性（線程數）. ## Modify the check interval[](#modify-the-check-interval "Permalink") 修改其他 Sidekiq 進程的檢查間隔： 1. 編輯`/etc/gitlab/gitlab.rb`并添加： ``` sidekiq['interval'] = 5 ``` 2. 保存文件并[重新配置 GitLab，](../restart_gitlab.html#omnibus-gitlab-reconfigure)以使更改生效. 這告訴其他進程多久檢查一次排隊的作業. ## Troubleshoot using the CLI[](#troubleshoot-using-the-cli "Permalink") **警告：**建議使用`/etc/gitlab/gitlab.rb`來配置 Sidekiq 進程. 如果遇到問題，應聯系 GitLab 支持. 使用命令行需要您自擔風險. 為了進行調試，可以使用命令`/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster`啟動額外的 Sidekiq 進程. 此命令使用以下語法獲取參數： ``` /opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster [QUEUE,QUEUE,...] [QUEUE, ...] ``` 每個單獨的參數表示一組必須由 Sidekiq 進程處理的隊列. 多個隊列可以通過相同的過程來處理，方法是用逗號而不是空格將它們分開. 除了隊列，還可以提供隊列名稱空間，以使進程自動偵聽該名稱空間中的所有隊列，而無需顯式列出所有隊列名稱. 有關隊列名稱空間的更多信息，請參見[Sidekiq 樣式指南中](../../development/sidekiq_style_guide.html#queue-namespaces)的相關部分. 例如，假設您要啟動兩個額外的進程：一個進程處理`process_commit`隊列，另一個進程處理`post_receive`隊列. 可以按以下步驟完成： ``` /opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster process_commit post_receive ``` 如果您想啟動一個處理兩個隊列的進程，則可以使用以下語法： ``` /opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster process_commit,post_receive ``` 如果您想讓一個 Sidekiq 進程處理`process_commit`和`post_receive`隊列，以及一個進程來處理`gitlab_shell`隊列，則可以使用以下命令： ``` /opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster process_commit,post_receive gitlab_shell ``` ### Monitor the `sidekiq-cluster` command[](#monitor-the-sidekiq-cluster-command "Permalink") 一旦啟動了所需數量的 Sidekiq 進程， `sidekiq-cluster`命令將不會終止. 相反，該進程將繼續運行并將所有信號轉發到子進程. 這使停止所有 Sidekiq 進程變得容易，因為您只需將信號發送到`sidekiq-cluster`進程即可，而不必將其發送到各個進程. 如果`sidekiq-cluster`進程崩潰或收到`SIGKILL` ，則子進程將在幾秒鐘后終止. 這樣可以確保您不會遇到僵尸 Sidekiq 進程. 所有這些使監視過程變得相當容易. 只需將`sidekiq-cluster`到您選擇的主管（例如 runit），就可以了. 如果子進程死亡， `sidekiq-cluster`命令將發出信號通知所有剩余進程終止，然后終止自身. 這樣就不需要`sidekiq-cluster`來重新實現復雜的過程監控/重新啟動代碼. 相反，您應該確保主管在必要時重新啟動`sidekiq-cluster`過程. ### PID files[](#pid-files "Permalink") `sidekiq-cluster`命令可以將其 PID 存儲在文件中. 默認情況下，不會寫入任何 PID 文件，但是可以通過將`--pidfile`選項傳遞給`sidekiq-cluster`來更改此文件. 例如： ``` /opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster --pidfile /var/run/gitlab/sidekiq_cluster.pid process_commit ``` 請記住，PID 文件將包含`sidekiq-cluster`命令的 PID，而不包含已啟動的 Sidekiq 進程的 PID. ### Environment[](#environment "Permalink") 可以通過將`--environment`標志傳遞給`sidekiq-cluster`命令或將`RAILS_ENV`設置為非空值來設置 Rails 環境. 可以在`/opt/gitlab/etc/gitlab-rails/env/RAILS_ENV`找到默認值.