Run multiple Sidekiq processes

• Available Sidekiq queues
• Negate settings
• • Available attributes
  • Example queries
• Ignore all GitHub import queues
• Manage concurrency
  • When running a single Sidekiq process
• Troubleshoot using the CLI
  • PID files

Run multiple Sidekiq processes

GitLab 允许您启动多个 Sidekiq 进程. 这些过程可用于消耗一组专用队列. 这可以用来确保某些队列始终具有专用的工作程序，而不管需要处理的作业数量如何.

注意：此页面中的信息仅适用于 Omnibus GitLab.

For a list of the existing Sidekiq queues, check the following files:

• Queues for GitLab Enterprise Editions only

以上文件中的每个条目都代表一个队列，可以在其上启动 Sidekiq 进程.

Start multiple processes

版本历史

• 在 GitLab 12.10 中引入 ，使用 Sidekiq 集群启动多个进程.
• GitLab 12.10 中的 GitLab Core .
• 在 GitLab 13.0 中成为默认设置 .

To start multiple processes:

1. 保存文件并重新配置 GitLab，以使更改生效：

   sudo gitlab-ctl reconfigure

添加了额外的 Sidekiq 进程后，导航至 GitLab 中的管理区域>监视>后台作业 （ /admin/background_jobs ）.

Negate settings

若要使其他 Sidekiq 进程在您列出的队列之外的每个队列上工作：

1. 在按照步骤 ，请编辑/etc/gitlab/gitlab.rb并添加：

   sidekiq['negate'] = true

2. 保存文件并重新配置 GitLab，以使更改生效：

   sudo gitlab-ctl reconfigure

Introduced in 12.8.

注意：由于这被标记为实验性的 ，因此随时可能更改，包括破坏向后兼容性 . 这样我们就可以对 GitLab.com 部署所需的更改做出反应. 我们存在一个跟踪问题，希望从此功能中删除实验性名称 ； 如果您有兴趣在自己的部署中使用它，请在此处发表评论.

除了按名称选择队列之外，如上所述， experimental_queue_selector选项还允许使用以下组件以更通用的方式选择队列组：

• 可以选择的属性.
• 用于构造查询的运算符.

• 在 GitLab 13.1 中 ， tags .

从所有可用属性的 ， experimental_queue_selector允许通过以下属性选择队列：

• feature_category队列所属的GitLab 功能类别 . 例如， merge队列属于source_code_management类别.
• has_external_dependencies队列是否连接到外部服务. 例如，所有进口商都将此设置为true .
• urgency -快速运行此队列的重要性. 可以high ， low或throttled . 例如， authorized_projects队列用于刷新用户权限，并且紧急度很高.
• name -队列名. 其他属性通常更有用，因为它们更通用，但这在需要选择特定队列的情况下可用.
• resource_boundary如果队列受cpu ， memory或unknown绑定. 例如， project_export队列受内存限制，因为它必须先将数据加载到内存中，然后再保存以进行导出.
• tags -队列的短暂注释. 预计这些版本会在发行版本之间频繁更改，并且可能会完全删除.

tags是一个集合，这意味着=检查相交的集合，而!=检查不相交的集合. 例如， tags=a,b选择具有标签a ， b或两者都有的队列. tags!=a,b选择没有这些标签的队列.

Available operators

experimental_queue_selector支持以下运算符，从最高优先级到最低优先级列出：

• | -逻辑或运算符. 例如， query_a|query_b （此处的query_a和是由其他运算符组成的查询）将包括与任一查询匹配的队列.
• & -逻辑 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 and later, as with the standard queue group syntax above, a single * as the entire queue group selects all queues.

Example queries

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
  '*'
]

警告：在 GitLab 14.0 中， 计划将 Sidekiq 群集作为启动 Sidekiq 的唯一方法.

默认情况下，Sidekiq 服务将运行sidekiq-cluster . 若要禁用此行为，请将以下内容添加到 Sidekiq 配置中：

所有上述提及的sidekiq配置选项均可用. 默认情况下，它们的配置如下：

sidekiq['experimental_queue_selector'] = false
sidekiq['interval'] = nil
sidekiq['max_concurrency'] = 50
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 配置的和其他选项.

默认情况下， sidekiq-cluster /var/log/gitlab/sidekiq像常规的 Sidekiq 日志一样进入/var/log/gitlab/sidekiq .

Ignore all GitHub import queues

，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_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

在sidekiq下定义的每个进程都以等于队列数的线程数开始，再加上一个备用线程. 例如，处理process_commit和post_receive队列的进程将总共使用三个线程.

设置最大并发数时，请记住，这通常不应超过可用的 CPU 内核数. 以下示例中的值是任意的，不是特别的建议.

Each thread requires a Redis connection, so adding threads may increase Redis latency and potentially cause client timeouts. See the for more details.

When running Sidekiq cluster (default)

在 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 将禁用该限制.

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

在 GitLab 12.10 及更早版本中，默认运行单个 Sidekiq 进程.

警告：计划在 GitLab 14.0 中删除直接运行 Sidekiq.

1. 编辑/etc/gitlab/gitlab.rb并添加：

   sidekiq['cluster'] = false
   sidekiq['concurrency'] = 25

2. 保存文件并重新配置 GitLab，以使更改生效：

这将设置 Sidekiq 进程的并发性（线程数）.

Modify the check interval

修改其他 Sidekiq 进程的检查间隔：

1. 编辑/etc/gitlab/gitlab.rb并添加：

   sidekiq['interval'] = 5

2. 保存文件并重新配置 GitLab，以使更改生效.

这告诉其他进程多久检查一次排队的作业.

Troubleshoot using the CLI

警告：建议使用/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 样式指南中的相关部分.

例如，假设您要启动两个额外的进程：一个进程处理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队列，则可以使用以下命令：

一旦启动了所需数量的 Sidekiq 进程， sidekiq-cluster命令将不会终止. 相反，该进程将继续运行并将所有信号转发到子进程. 这使停止所有 Sidekiq 进程变得容易，因为您只需将信号发送到sidekiq-cluster进程即可，而不必将其发送到各个进程.

如果sidekiq-cluster进程崩溃或收到SIGKILL ，则子进程将在几秒钟后终止. 这样可以确保您不会遇到僵尸 Sidekiq 进程.

所有这些使监视过程变得相当容易. 只需将sidekiq-cluster到您选择的主管（例如 runit），就可以了.

如果子进程死亡， sidekiq-cluster命令将发出信号通知所有剩余进程终止，然后终止自身. 这样就不需要sidekiq-cluster来重新实现复杂的过程监控/重新启动代码. 相反，您应该确保主管在必要时重新启动sidekiq-cluster过程.

PID files

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

Environment

可以通过将--environment标志传递给sidekiq-cluster命令或将设置为非空值来设置 Rails 环境. 可以在/opt/gitlab/etc/gitlab-rails/env/RAILS_ENV找到默认值.