调优 Red Hat Satellite 的性能

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

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

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

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

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

如果您没有使用 satellite-installer 提供任何 Puma worker 和线程值，或者 Satellite 配置中不存在它们，satellite-installer 会配置均衡的 worker 数量。它遵循此公式：

min(CPU_COUNT * 1.5, RAM_IN_GB - 1.5)

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

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

systemctl status foreman

# systemctl status foreman

如果您决定不依赖于 第 5.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-installer \
--foreman-foreman-service-puma-workers=2 \
--foreman-foreman-service-puma-threads-min=5 \
--foreman-foreman-service-puma-threads-max=5

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

为了为不同的调优配置文件推荐线程和 worker 配置，我们使用不同的调优配置文件在卫星中进行了 Puma 调整测试。此测试中使用的主要测试是与以下组合中的并发注册，以及不同的 worker 和线程数。我们推荐完全基于并发注册性能，因此可能无法反映您的确切用例。例如，如果您的设置非常面向大量发布和推广的内容，您可能需要限制 Puma 消耗的资源，而使用 Pulp 和 PostgreSQL。

调优工作程序数是此处更为重要的方面，在一些情况下，我们看到了 52% 的性能提升。虽然安装程序默认使用 5 个 min/max 线程，但我们建议使用上表中的所有调优配置文件的 16 个线程。这是因为，与设置 4 个线程相比，我们看到了高达 23% 的性能提高，16 个线程(84% 和 10% 为 32)。

要找出这些建议，我们使用了并发注册测试案例，这是非常具体的用例。在您的卫星中可能具有不同的，这可能具有更为均衡的用例（不仅仅是注册）。保持默认的 5 分钟/最大线程也是不错的选择。

以下是我们造成以下建议的一些测量：

在默认设置(4 个 CPU)上使用 4 个 worker - 与 2 个 worker 相比，我们看到 5 个 worker 的性能高 25%，但在与 2 个 worker 相比，高达 8 个 worker 的性能会降低 8 个 worker 的性能 - 如下所示：

在介质设置(8 CPU)上使用 8mvapich-literal12 worker - 请参考下表：

在 32 个 CPU 设置中使用 16 个+1 worker （这在 90 GiB RAM 机器上进行了测试，且内存已作为系统启动交换因素 - 正确的 extra-large 应该有 128 GiB），对于我们测试的更高注册并发级别，我们无法建议它。

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

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

添加更多的 worker 也可以帮助，获得总注册并发 Satellite 可以处理。在我们的测量中，带有 2 个 worker 的设置可以处理最多 480 个并发注册，但添加更多工作程序可以改进这种情况。

更多线程可以缩短并行注册主机的时间。例如，我们对比了这两个设置：

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

$db_pool 的有效值设置为 equal $foreman::foreman_service_puma_threads_max。最多 $foreman::db_pool 和 $foreman_service_puma_threads_max 都是默认的值 5，因此对 5 以上的最大线程自动增加数据库连接池。

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

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

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

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

satellite-installer --foreman-db-pool 10

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

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

在调整就位后，Apache httpd 可轻松打开服务器上的许多文件描述符，该描述符可能会超过大部分 Linux 系统的默认限制。为了避免因为系统上超过最大打开文件限制而可能出现的任何问题，请创建以下文件和目录并设置以下示例中指定的文件内容：

默认情况下，httpd 使用事件请求处理机制。当 httpd 的请求数超过可以启动来处理进入连接的最大子进程数时，httpd 会引发 HTTP 503 Service Unavailable 错误。amidst httpd 无法处理进程，进入的连接也可以导致 Satellite 服务的多个组件失败，因为 httpd 进程的可用性某些组件。

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

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

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

以下设置允许卫星扩展至 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 提供足够的存储空间。在服务器上，/var/lib/qpidd 需要每个内容主机 2MiB 磁盘空间。

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

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

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 为队列、会话和连接维护管理对象，默认每十秒回收它们。创建、删除和再次创建具有相同 ID 的同一对象。旧的管理对象尚未清除，这就是 qpid 引发此错误的原因。

您可以调整 mosquitto MQTT 服务器，并增加与之连接的主机数量。

当使用 Script provider 为远程执行作业配置 Satellite 服务器时，胶囊服务器通过 MQTT 向客户端发送有关新作业的通知。此通知不包括客户端应该执行的实际工作负载。客户端收到有关新远程执行作业的通知后，它会查询胶囊服务器以获取其实际工作负载。在作业期间，客户端定期将作业输出发送到胶囊服务器，进一步增加对胶囊服务器的请求数量。

这些对胶囊服务器的请求与 MQTT 协议允许的高并发性一起可能会导致胶囊服务器上的可用连接耗尽。有些请求可能会失败，使远程执行作业的一些子任务无响应。这还取决于实际的作业工作负载，因为一些作业会给 Satellite 服务器造成额外的负载，从而在客户端注册到 Satellite 服务器时使其争用资源。

要避免这种情况，请使用以下参数配置 Satellite 服务器和 Capsule 服务器：

satellite-installer \
--foreman-proxy-plugin-remote-execution-script-mqtt-rate-limit My_MQTT_Rate_Limit \
--foreman-proxy-plugin-remote-execution-script-mqtt-resend-interval My_MQTT_Resend_Interval \
--foreman-proxy-plugin-remote-execution-script-mqtt-ttl My_MQTT_Time_To_Live

# satellite-installer \
--foreman-proxy-plugin-remote-execution-script-mqtt-rate-limit My_MQTT_Rate_Limit \
--foreman-proxy-plugin-remote-execution-script-mqtt-resend-interval My_MQTT_Resend_Interval \
--foreman-proxy-plugin-remote-execution-script-mqtt-ttl My_MQTT_Time_To_Live

Capsule 服务器日志位于 /var/log/foreman-proxy/proxy.log 中。胶囊服务器使用 Webrick HTTP 服务器（不包括 httpd 或 Puma），因此无法简单地提高其容量。

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

pgbench 工具（请注意，您可能需要将 PostgreSQL 数据目录 /var/lib/pgsql 目录调整为 100 GiB，或者执行基准运行的内容）可能用来衡量系统中的 PostgreSQL 性能。使用 dnf install postgresql-contrib 安装它。如需更多信息，请参阅 github.com/RedHatSatellite/satellite-support。

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

在多个胶囊配置中，我们测量了多个测试案例：

当我们将从卫星服务器下载性能与胶囊式服务器相比，我们只看到 5% 的速度提升了 5% 的速度，但其预期是，与地理上分散的客户端（或不同网络中的客户端）相关，而为了处理负载卫星服务器的一部分，则需要自行处理。在一些较小的硬件配置(8 个 CPU 和 24 GiB)中，卫星服务器无法从 500 多个并发客户端处理下载，而具有相同硬件配置的胶囊式服务器能够服务超过 1000 并且可能更多。

apache::mod::proxy::proxy_timeout: 600

apache::mod::proxy::proxy_timeout: 600