调优 Red Hat Satellite 的性能

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

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

我们建议将 thread_min 设置为与 less Puma 线程数量相同的 threads_max 值，从而导致卫星服务器上的内存用量较高。

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

与 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

如果您决定不依赖于 第 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

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

要为不同的调优配置文件推荐线程和 worker 配置，我们使用不同的调优配置文件在 Satellite 上进行 Puma 调优测试。此测试中使用的主测试是并发注册，其组合包括不同的 worker 和线程数量。我们的建议仅基于并发注册性能，因此可能无法反映您的确切用例。例如，如果您的设置非常面向发布和提升内容，您可能想限制 Puma 消耗的资源，并取代 Pulp 和 PostgreSQL。

对工作程序进行调优是，在一些情况下，我们可以提高 52% 的性能。虽然安装程序默认使用 5 分钟/最大线程，但我们建议在上表中使用所有调优配置文件的 16 个线程。这是因为，与 4 个线程设置相比，与设置 4 个线程相比，我们看到的 16 个线程性能增加了 23%(14%，84% 的 10%)。

要查明这些建议，我们使用了并发注册测试案例，这是一个非常具体的用例。它在卫星上可能会有所不同，它可能具有更平衡的用例（不仅仅是注册）。另外，保留默认 5 分钟/最大线程是很好的选择。

以下是导致我们提出这些建议的一些测量信息：

在默认设置(4 个 CPU)上使用 4 个关闭 worker - 与 2 个 worker 相比，与 2 个 worker 相比，与 5 个 worker 相比，与 8 个 worker 的性能更高，但 8% 的性能降低 8 个 worker - 参见下表：

在 Medium setup (8 CPU)中使用 8049-的 worker - 请参考下表：

使用 32 个 CPU 设置上的 16 个关闭程序（这是在 90 GiB RAM 计算机上测试，且内存关闭为因系统开始交换）的一个因子，对于我们测试的超大的线程数量较高，所以我们测试的并发级别较高，因此不建议它。

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

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

增加更多 worker 可以帮助处理总注册并发卫星。在我们的测量中，使用 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% 的速度。此外，添加更多工作程序不会消耗更多 CPU 和 RAM，但会获得更好的性能。

$db_pool 的有效值自动设置为等于 $foreman::foreman_service_puma_threads_max。它是 $foreman::db_pool 和 $foreman::foreman_service_puma_max 的最大值，但两者的默认值为 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

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

默认情况下，HTTPD 使用预派生请求处理机制。借助预派生处理请求的模型，httpd 会启动一个新的进程来处理客户端的传入连接。

当 Apache 的请求数超过可启动以处理传入连接的子进程的最大数量时，httpd 将引发 HTTP 503 服务 Unavailable Error。amidst httpd 从进程之外进行处理，传入的连接也会导致您的卫星一侧出现多个组件故障，因为 httpd 进程可用性上的 Pulp 等组件依赖 Pulp。

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

对可能要处理 150 个并发内容主机注册的服务器修改示例（请参阅如何使用 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 系统的默认限制。为了避免因为在系统中超过最大打开文件限制而出现的任何问题，请创建以下文件和目录并设置下例中指定的文件内容：

默认情况下，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 是内容主机数。对于 Broker 操作(qpidd)操作需要单个内容主机最多消耗四个文件描述符和 500 个文件描述符。

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

在规划安装（用于广泛使用 katello-agent ）时，请确保提前为 /var/lib/qpidd 提供足够的存储空间。在卫星服务器上，/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 维护队列、会话和连接默认为每十秒的管理对象。具有相同 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

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

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

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

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

我们已在多个胶囊配置中计算多个测试情况：

当从卫星服务器与胶囊服务器下载性能与从胶囊服务器下载性能时，我们只看到大约 5% 的速度，但随着胶囊服务器的主要好处，将更接近地将内容更接近地分布客户（或不同网络客户端）以及处理负载卫星服务器的一部分。在一些较小的硬件配置(8 个 CPU 和 24 GiB)中，卫星服务器无法从 500 个并发客户端处理下载，而具有相同硬件配置的胶囊服务器也可以超过 1000，甚至可能会更多。

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