Help us learn about your current experience with the documentation. Take the survey.

运行多个 Sidekiq 进程

Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed

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

本页中的信息仅适用于 Linux 软件包安装。

启动多个进程

启动多个进程时，进程数量最多应等于（并且不能超过）您希望分配给 Sidekiq 的 CPU 核心数。Sidekiq 工作进程最多使用一个 CPU 核心。

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

例如，要创建四个 Sidekiq 进程，每个进程都监听所有可用队列：

编辑 /etc/gitlab/gitlab.rb：
```
sidekiq['queue_groups'] = ['*'] * 4
```
保存文件并重新配置 GitLab：
```
sudo gitlab-ctl reconfigure
```

要在 GitLab 中查看 Sidekiq 进程：

在左侧边栏的底部，选择 管理员。
选择 监控 > 后台作业。

并发性

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

这些线程在单个 Ruby 进程内运行，并且每个进程只能使用一个 CPU 核心。线程的作用取决于工作是否有需要等待的外部依赖项，例如数据库查询或 HTTP 请求。大多数 Sidekiq 部署都受益于此线程机制。

显式管理线程数

正确的最大线程数（也称为并发性）取决于工作负载。对于高度占用 CPU 的任务，典型值范围为 5；对于混合的、低优先级的工作，则为 15 或更高。对于非专业化部署，一个合理的起始范围是 15 到 25。

这些值会根据每个特定 Sidekiq 部署所执行的工作而有所不同。任何其他具有专门处理特定队列的进程的专用部署，都应根据以下因素调整其并发性：

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

每个线程都需要一个 Redis 连接，因此增加线程可能会增加 Redis 延迟，并可能导致客户端超时。更多详情请参阅 Sidekiq 关于 Redis 的文档。

使用并发性字段管理线程数

在 GitLab 16.9 及更高版本中，您可以通过设置 concurrency 来设置并发性。此值会为每个进程显式设置此数量的并发性。

例如，要将并发性设置为 20：

编辑 /etc/gitlab/gitlab.rb：
```
sidekiq['concurrency'] = 20
```
保存文件并重新配置 GitLab：
```
sudo gitlab-ctl reconfigure
```

修改检查间隔

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

编辑 /etc/gitlab/gitlab.rb：
```
sidekiq['interval'] = 5
```
该值可以是任意整数秒数。
保存文件并重新配置 GitLab：
```
sudo gitlab-ctl reconfigure
```

使用 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, ...]

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

每个独立的参数表示一组必须由 Sidekiq 进程处理的队列。多个队列可以通过逗号（而非空格）分隔，从而由同一个进程处理。

除了指定队列，您也可以提供队列命名空间，使进程自动监听该命名空间中的所有队列，而无需显式列出所有队列名称。有关队列命名空间的更多信息，请参阅 GitLab 开发文档中 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 中找到。