{{< details >}}

  • Tier: 基础版,专业版,旗舰版
  • Offering: 私有化部署

{{< /details >}}

极狐GitLab 允许您启动多个 Sidekiq 进程,以便在单个实例上以更高的速率处理后台作业。默认情况下,Sidekiq 启动一个工作进程,并且只使用一个核心。

{{< alert type=”note” >}}

The information in this page applies only to Linux package installations.

{{< /alert >}}

启动多个进程

当启动多个进程时,进程数量最多应等于(并且不能超过)您希望专用于 Sidekiq 的 CPU 核心数量。Sidekiq 工作进程最多只使用一个 CPU 核心。

要启动多个进程,请使用 sidekiq['queue_groups'] 数组设置来指定使用 sidekiq-cluster 创建多少个进程以及它们应该处理哪些队列。数组中的每一项相当于一个额外的 Sidekiq 进程,每项中的值决定了它所处理的队列。在绝大多数情况下,所有进程都应监听所有队列(有关更多详细信息,请参阅处理特定作业类别)。

例如,要创建四个 Sidekiq 进程,每个进程监听所有可用队列:

  1. 编辑 /etc/gitlab/gitlab.rb

    sidekiq['queue_groups'] = ['*'] * 4
    
  2. 保存文件并重新配置极狐GitLab :

    sudo gitlab-ctl reconfigure
    

要在极狐GitLab 中查看 Sidekiq 进程:

  1. 在左侧侧边栏底部,选择 管理员
  2. 选择 监控 > 后台作业

并发性

默认情况下,在 sidekiq 下定义的每个进程以等于队列数量加一个备用线程的线程数启动,最多可达 50 个。 例如,处理所有队列的进程默认使用 50 个线程。

这些线程在单个 Ruby 进程中运行,并且每个进程只能使用一个 CPU 核心。线程的有用性取决于工作是否具有一些外部依赖关系需要等待,例如数据库查询或 HTTP 请求。大多数 Sidekiq 部署都受益于这种线程处理。

显式管理线程数

正确的最大线程数(也称为并发性)取决于工作负载。典型值范围从 5,用于高度 CPU 密集型任务,到 15 或更高,用于混合低优先级工作。对于非专用部署,合理的起始范围是 1525

这些值根据 Sidekiq 的每个特定部署所执行的工作而有所不同。任何其他专用部署的进程专用于特定队列,应根据以下因素调整并发性:

  • 每种类型进程的 CPU 使用率。
  • 实现的吞吐量。

每个线程都需要一个 Redis 连接,因此增加线程可能会增加 Redis 延迟,并可能导致客户端超时。

使用并发字段管理线程数

{{< history >}}

  • 引入于GitLab 16.9。

{{< /history >}}

在极狐GitLab 16.9 及更高版本中,您可以通过设置 concurrency 来设置并发性。这个值明确设置了每个进程的并发数量。

例如,要将并发性设置为 20

  1. 编辑 /etc/gitlab/gitlab.rb

    sidekiq['concurrency'] = 20
    
  2. 保存文件并重新配置极狐GitLab :

    sudo gitlab-ctl reconfigure
    

修改检查间隔

要修改额外 Sidekiq 进程的 Sidekiq 健康检查间隔:

  1. 编辑 /etc/gitlab/gitlab.rb

    sidekiq['interval'] = 5
    

    值可以是任何整数秒数。

  2. 保存文件并重新配置极狐GitLab :

    sudo gitlab-ctl reconfigure
    

使用 CLI 进行故障排除

{{< alert type=”warning” >}}

建议使用 /etc/gitlab/gitlab.rb 配置 Sidekiq 进程。如果您遇到问题,您应该联系极狐GitLab 支持。使用命令行需自担风险。

{{< /alert >}}

为了调试目的,您可以使用命令 /opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster 启动额外的 Sidekiq 进程。此命令使用以下语法接收参数:

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

--dryrun 参数允许查看要执行的命令而无需实际启动它。

每个单独的参数表示一个需要由 Sidekiq 进程处理的队列组。通过使用逗号而不是空格分隔多个队列,可以由同一进程处理多个队列。

可以提供队列命名空间而不是队列,以便进程自动监听该命名空间中的所有队列,而无需显式列出所有队列名称。有关队列命名空间的更多信息,请参阅 Sidekiq 开发文档的相关部分。

监控 sidekiq-cluster 命令

sidekiq-cluster 命令在启动所需数量的 Sidekiq 进程后不会终止。相反,进程继续运行并将任何信号转发给子进程。这允许您在向 sidekiq-cluster 进程发送信号时停止所有 Sidekiq 进程,而无需将其发送给单个进程。

如果 sidekiq-cluster 进程崩溃或收到 SIGKILL,子进程会在几秒钟后自动终止。这确保了您不会最终出现僵尸 Sidekiq 进程。

这允许您通过将 sidekiq-cluster 连接到您选择的监督程序(例如,runit)来监视进程。

如果一个子进程死亡,sidekiq-cluster 命令会向所有剩余进程发出终止信号,然后自己终止。这消除了 sidekiq-cluster 重新实现复杂进程监控/重启代码的需要。相反,您应该确保您的监督程序在必要时重新启动 sidekiq-cluster 进程。

PID 文件

sidekiq-cluster 命令可以将其 PID 存储在文件中。默认情况下不会写入 PID 文件,但可以通过向 sidekiq-cluster 传递 --pidfile 选项来更改这一点。例如:

/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster --pidfile /var/run/gitlab/sidekiq_cluster.pid process_commit

请记住,PID 文件包含 sidekiq-cluster 命令的 PID,而不是启动的 Sidekiq 进程的 PID。

环境

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