性能调优指南

Puma 线程数量（每个 Puma worker）配置为使用两个值进行配置： threads_min 和 threads_max。

threads_min 的值决定了每个 worker 在 worker 启动时生成多少个线程。然后，当并发请求进入并且需要更多线程时，worker 将生成更多 worker，最多为 threads_max 限制。

我们建议将 threads_min 设置为与 threads_max 的值相同，与 Puma 线程较少的值相同，这会导致 Satellite 服务器上的内存用量更高。

例如，我们已使用并发注册测试来比较这两个设置：

与 threads_min=0 相比，将最小 Puma 线程设置为 16 会导致大约需要 12% 的内存用量。

如果您没有通过 satellite-installer 提供任何 Puma worker 和 thread 值，或者 Satellite 配置中没有它们，satellite-installer 会配置均衡数量的 worker。它遵循以下公式：

min(CPU_COUNT * 1.5, RAM_IN_GB - 1.5)

对于大多数情况，这应该很正常，但对于一些使用模式调整，需要限制专用于 Puma （其他 Satellite 组件）或其它原因的资源量。每个 Puma worker 消耗大约 1 GiB RAM。

# cat /etc/systemd/system/foreman.service.d/installer.conf

# systemctl status foreman.service

如果您决定不依赖 第 6.2.2 节 “puma Workers 和 Threads Auto-Tuning”，您可以为这些可调项应用自定义数字。在以下示例中，我们使用 2 个 worker、5 个和 5 个线程：

# satellite-installer \
--foreman-foreman-service-puma-workers=2 \
--foreman-foreman-service-puma-threads-min=5 \
--foreman-foreman-service-puma-threads-max=5

将您的更改应用到 Satellite 服务器。更多信息请参阅 第 6.1 节 “应用配置”。

为了为不同的调优配置集推荐线程和 worker 配置，我们对具有不同调优配置文件的 Satellite 进行了 Puma 调优测试。此测试中使用的主要测试是使用下列组合的并发注册，以及不同数量的 worker 和线程。我们建议只基于并发注册性能，因此它可能没有反映您的具体用例。例如，如果您的设置非常面向许多发布和提升的内容，您可能需要限制 Puma 所消耗的资源，而代于 Pulp 和 PostgreSQL。

调优 worker 数量是更重要的方面，在某些情况下，我们看到最多 52% 的性能提高了。虽然安装程序默认使用 5 分钟/最大线程，但我们推荐使用上表中的所有调优配置集的 16 个线程。这是因为，与设置有 4 个线程相比，我们看到最多 23% 的性能提高了 16 个线程(14% 用于 8，10％ 用于 32 个)。

要找出这些建议，我们使用了并发注册测试问题单，这是非常具体的用例。它可能在您的 Satellite 上有所不同，这些用例可能具有更均衡的用例（不仅仅是注册）。保持默认的 5 分钟/最大线程也是良好的选择。

以下是我们向我们提供这些建议的一些衡量：

在默认设置(4 个 CPU)上使用 4945-1146 worker - 与 2 个 worker 相比，我们看到 25% 的性能，与 2 个 worker 相比，在 8 个 worker 中性能较低，请参阅下表：

在中型设置(8 个 CPU)上使用 8598-59812 worker - 请参考下表：

在 32 个 CPU 设置（这在 90 GiB RAM 机器上测试，在系统启动交换时被认为是系统启动交换（正确的 额外容量 ）应该有 128 GiB，因此我们测试了更高的注册并发级别会出现问题，因此我们无法建议它。

如果有足够的 CPU，添加更多 worker 会增加性能。例如，我们已将 Satellite 设置与 8 和 16 个 CPU 进行比较：

在 8 个 CPU 设置中，将 worker 数量从 2 改为 16，将并发注册时间提高 36%。在 16 个 CPU 设置中，相同的更改会导致 55% 的改进。

添加更多 worker 还可以帮助完成所有注册并发 Satellite 可以处理。在我们的测量中，使用 2 个 worker 设置可以处理 480 并发注册，但添加更多 worker 可以提高这种情况。

# satellite-installer \
--foreman-foreman-service-puma-threads-max=5
--foreman-foreman-service-puma-threads-min=5 \
--foreman-foreman-service-puma-workers=2 \

更多线程允许较少的时间来并行注册主机。例如，我们比较这两个设置：

使用更多 worker 和相同线程总数会导致在高并发注册场景中有 11% 的速度。此外，添加更多 worker 不会消耗更多 CPU 和 RAM，但性能更高。

$db_pool 的有效值设为相同的 $foreman::foreman_service_puma_threads_max。它是 $foreman::db_pool 和 $foreman::foreman_service_puma_threads_max 的最大值，但默认值 5 都增加 5，因此 5 以上的最大线程都根据相同数量自动增加数据库连接池。

如果您遇到 ActiveRecord::ConnectionTimeoutError: 无法在 5.000 秒内从池中获取连接（等待 5.006 秒）；所有池的连接都在使用 /var/log/foreman/production.log 中的错误，您可能需要增加这个值。

# grep pool /etc/foreman/database.yml
  pool: 5

如果您决定不依赖于自动配置的值，您可以应用如下自定义数字：

# satellite-installer --foreman-db-pool 10

将您的更改应用到 Satellite 服务器。更多信息请参阅 第 6.1 节 “应用配置”。

默认情况下，HTTPD 使用 prefork 请求处理机制。通过处理请求的预分叉模型，httpd 会启动一个新进程来处理客户端进入的连接。

当对 apache 的请求数超过可启动以处理传入连接的子进程的最大数量时，httpd 引发 HTTP 503 Service Unavailable 错误。amidst httpd 不足以处理进程，传入的连接也可以在 Satellite 端造成多个组件失败，因为 httpd 进程可用性上 Pulp 等组件依赖项。

您可以调整 HTTPD prefork 的配置，以根据预期的峰值负载处理更多并发请求。

对服务器的预fork配置的一个示例，可能需要处理 150 个并发内容主机注册到 Satellite，如下所示（请参阅 如何使用 custom-hiera.yaml 文件；这将修改配置文件 /etc/httpd/conf.modules.d/prefork.conf）：

您可以修改 /etc/foreman-installer/custom-hiera.yaml ：

apache::mod::prefork::serverlimit: 582
apache::mod::prefork::maxclients: 582
apache::mod::prefork::startservers: 10

通过调优，Apache httpd 可以轻松地在服务器上打开大量文件描述符，这些描述符可能会超过大多数 Linux 系统的默认限制。为了避免因为系统上的最大打开文件限制而可能出现任何类型的问题，请创建以下文件和目录并设置以下文件和目录，如以下示例中指定的文件的内容：

在使用具有大量内容主机的 katello-agent 基础架构部署中，可能需要增加 qdrouterd 的最大打开文件。

使用这个公式计算 qdrouterd 中打开文件的限制： (N x 3)+ 100，其中 N 是内容主机的数量。每个内容主机最多可消耗路由器中的三个文件描述符，并且需要 100 个文件描述符来运行路由器本身。

以下设置允许 Satellite 扩展至 10.000 内容主机。

在使用具有大量内容主机的 katello-agent 基础架构部署中，可能需要增加 qpidd 的最大打开文件。

使用这个公式计算 qpidd 中打开文件的限制： (N x 4)+ 500，其中 N 是内容主机的数量。单个内容主机最多可消耗四个文件描述符，对于代理操作需要 500 个文件描述符(qpidd 组件)。

在使用具有大量内容主机的 katello-agent 基础架构部署中，可能需要增加允许的最大并发 AIO 请求。您可以通过增加内核参数 fs.aio-max-nr 来增加允许并发 AIO 请求的最大数量。

当您计划广泛使用 katello-agent 的安装时，请确保提前为 /var/lib/qpidd 提供足够的存储空间。在 Satellite 服务器上，/var/lib/qpidd 需要每个内容主机 2MiB 磁盘空间。

您可能会在 Red Hat Enterprise Linux 7 中看到日志中的以下错误（使用 journalctl 命令访问它）：

satellite.example.com qpidd[92464]: [Broker] error Channel exception: not-attached: Channel 2 is not attached(/builddir/build/BUILD/qpid-cpp-0.30/src/qpid/amqp_0_10/SessionHandler.cpp: 39
satellite.example.com qpidd[92464]: [Protocol] error Connectionqpid.10.1.10.1:5671-10.1.10.1:53790 timed out: closing

出现此错误消息的原因是 qpid 为队列、会话和连接维护管理对象，默认每 10 秒回收它们。同一 ID 的同一对象被创建、删除并重新创建。旧的管理对象尚未清除，因此 qpid 抛出此错误的原因。

要获得关于 Candlepin、Foreman 和 Pulp 检查 satellite-support git 存储库中的 postgres-size-report 脚本的磁盘空间中顶级表大小的列表。

pgbench 工具（请注意，您可能需要将 PostgreSQL 数据目录 /var/opt/rh/rh-postgresql12/lib/pgsql/ 目录调整为 100 GiB，或基准需要运行什么来测量系统上的 PostgreSQL 性能。使用 yum install postgresql-contrib 进行安装。如需更多信息，请参阅 github.com/DSLSatellite/satellite-support。

为 PostgreSQL 数据目录选择文件系统可能也很重要。

我们在多个 Capsule 配置中计算了多个测试案例：

当从 Satellite 服务器与从 Capsule 服务器下载性能相比，我们只看到大约 5% 的速度，但预期为 Capsule 服务器的主要好处在于获得更接近地理分布式客户端（或不同网络中的客户端）以及处理负载 Satellite 服务器的一部分的内容。在某些较小的硬件配置中(8 个 CPU 和 24 GiB)，Satellite 服务器无法处理来自 500 个并发客户端的下载，而具有相同硬件配置的 Capsule 服务器可以服务超过 1000 个且可能甚至更多。