Run multiple Sidekiq processes

原文:https://docs.gitlab.com/ee/administration/operations/extra_sidekiq_processes.html

Run multiple Sidekiq processes

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

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

Available Sidekiq queues

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

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

Start multiple processes

版本历史

To start multiple processes:

  1. 使用sidekiq['queue_groups']数组设置,指定使用sidekiq-cluster创建多少个进程以及它们应处理的队列. 数组中的每个项目都相当于一个附加的 Sidekiq 进程,并且每个项目中的值确定了它要处理的队列.

    例如,以下设置创建三个 Sidekiq 过程,一到上运行elastic_indexer ,一到上运行mailers ,以及一个进程中运行的所有的队列:

    1. sidekiq['queue_groups'] = [
    2. "elastic_indexer",
    3. "mailers",
    4. "*"
    5. ]

    要让附加的 Sidekiq 进程处理多个队列,请将多个队列名称添加到其项目中,并以逗号分隔. 例如:

    1. sidekiq['queue_groups'] = [
    2. "elastic_indexer, elastic_commit_indexer",
    3. "mailers",
    4. "*"
    5. ]

    在 GitLab 12.9和更高版本中,特殊队列名称*表示所有队列. 这将启动两个进程,每个进程处理所有队列:

    1. sidekiq['queue_groups'] = [
    2. "*",
    3. "*"
    4. ]

    *不能与具体的队列名称结合使用- *, mailers将只处理mailers队列.

    sidekiq-cluster仅在单个节点上运行时,请使用*确保在所有队列上至少运行一个进程. 这意味着一个进程将自动在将来创建的队列中拾取作业.

    如果sidekiq-cluster在多个节点上运行,则还可以使用--negate并列出所有已在处理的队列.

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

    1. sudo gitlab-ctl reconfigure

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

Multiple Sidekiq processes

Negate settings

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

  1. 在按照步骤启动额外的流程之后 ,请编辑/etc/gitlab/gitlab.rb并添加:

    1. sidekiq['negate'] = true
  2. 保存文件并重新配置 GitLab,以使更改生效:

    1. sudo gitlab-ctl reconfigure

Queue selector (experimental)

Introduced in GitLab Starter 12.8.

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

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

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

Available attributes

  • 在 GitLab 13.1 中引入tags .

所有可用属性列表中experimental_queue_selector允许通过以下属性选择队列:

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

has_external_dependencies是布尔值属性:只有确切的字符串true才被视为 true,其他所有内容都被视为 false.

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

Available operators

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

  • | -逻辑或运算符. 例如, query_a|query_b (此处的query_aquery_b是由其他运算符组成的查询)将包括与任一查询匹配的队列.
  • & -逻辑 AND 运算符. 例如, query_a&query_b (此处的query_aquery_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:

  1. sidekiq['enable'] = true
  2. sidekiq['experimental_queue_selector'] = true
  3. sidekiq['queue_groups'] = [
  4. # Run all non-CPU-bound queues that are high urgency
  5. 'resource_boundary!=cpu&urgency=high',
  6. # Run all continuous integration and pages queues that are not high urgency
  7. 'feature_category=continuous_integration,pages&urgency!=high',
  8. # Run all queues
  9. '*'
  10. ]

Disable Sidekiq cluster

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

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

  1. sidekiq['enable'] = true
  2. sidekiq['cluster'] = false

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

  1. sidekiq['experimental_queue_selector'] = false
  2. sidekiq['interval'] = nil
  3. sidekiq['max_concurrency'] = 50
  4. sidekiq['min_concurrency'] = nil
  5. sidekiq['negate'] = false
  6. sidekiq['queue_groups'] = ['*']
  7. 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

从 GitHub 导入时 ,Sidekiq 可能会使用其所有资源来执行那些操作. 要设置一个单独的sidekiq-cluster进程以忽略所有与 GitHub 导入相关的队列:

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

    1. sidekiq['enable'] = true
    2. sidekiq['negate'] = true
    3. sidekiq['queue_groups'] = [
    4. "github_import_advance_stage",
    5. "github_importer:github_import_import_diff_note",
    6. "github_importer:github_import_import_issue",
    7. "github_importer:github_import_import_note",
    8. "github_importer:github_import_import_lfs_object",
    9. "github_importer:github_import_import_pull_request",
    10. "github_importer:github_import_refresh_import_jid",
    11. "github_importer:github_import_stage_finish_import",
    12. "github_importer:github_import_stage_import_base_data",
    13. "github_importer:github_import_stage_import_issues_and_diff_notes",
    14. "github_importer:github_import_stage_import_notes",
    15. "github_importer:github_import_stage_import_lfs_objects",
    16. "github_importer:github_import_stage_import_pull_requests",
    17. "github_importer:github_import_stage_import_repository"
    18. ]
  2. 保存文件并重新配置 GitLab,以使更改生效:

    1. sudo gitlab-ctl reconfigure

Number of threads

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

Manage concurrency

设置最大并发数时,请记住,这通常不应超过可用的 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 for more details.

When running Sidekiq cluster (default)

在 GitLab 13.0 和更高版本中,默认运行 Sidekiq 群集.

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

    1. sidekiq['min_concurrency'] = 15
    2. sidekiq['max_concurrency'] = 25
  2. 保存文件并重新配置 GitLab,以使更改生效:

    1. sudo gitlab-ctl reconfigure

min_concurrencymax_concurrency是独立的; 一个可以不设置另一个. 将min_concurrency设置为 0 将禁用该限制.

对于每个队列组,令 N 为队列数多一. 并发因子将设置为:

  1. N ,如果它介于min_concurrencymax_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并添加:

    1. sidekiq['cluster'] = false
    2. sidekiq['concurrency'] = 25
  2. 保存文件并重新配置 GitLab,以使更改生效:

    1. sudo gitlab-ctl reconfigure

这将设置 Sidekiq 进程的并发性(线程数).

Modify the check interval

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

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

    1. 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 进程. 此命令使用以下语法获取参数:

  1. /opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster [QUEUE,QUEUE,...] [QUEUE, ...]

每个单独的参数表示一组必须由 Sidekiq 进程处理的队列. 多个队列可以通过相同的过程来处理,方法是用逗号而不是空格将它们分开.

除了队列,还可以提供队列名称空间,以使进程自动侦听该名称空间中的所有队列,而无需显式列出所有队列名称. 有关队列名称空间的更多信息,请参见Sidekiq 样式指南中的相关部分.

例如,假设您要启动两个额外的进程:一个进程处理process_commit队列,另一个进程处理post_receive队列. 可以按以下步骤完成:

  1. /opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster process_commit post_receive

如果您想启动一个处理两个队列的进程,则可以使用以下语法:

  1. /opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster process_commit,post_receive

如果您想让一个 Sidekiq 进程处理process_commitpost_receive队列,以及一个进程来处理gitlab_shell队列,则可以使用以下命令:

  1. /opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster process_commit,post_receive gitlab_shell

Monitor the sidekiq-cluster command

一旦启动了所需数量的 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来更改此文件. 例如:

  1. /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标志传递给sidekiq-cluster命令或将RAILS_ENV设置为非空值来设置 Rails 环境. 可以在/opt/gitlab/etc/gitlab-rails/env/RAILS_ENV找到默认值.