调优 Red Hat Satellite 的性能

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

threads_min 的值决定了每个 worker 在启动时生成的线程数量。然后，由于并发请求来自且需要更多的线程，因此 worker 将生成更多 worker，最多生成 threads_max 限制。

我们建议将 threads_min 设置为与 threads_max 的值与具有较少的 Puma 线程的值会导致 Satellite 服务器上的内存使用高。

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

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

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

min(CPU_COUNT * 1.5, RAM_IN_GB - 1.5)

在大多数情况下，这应该可以正常工作，但有些使用模式调整需要限制专用于 Puma 的资源量（因此其他 Satellite 组件可以使用这些资源）或其它原因。每个 Puma worker 大约消耗 1 GiB 内存。

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

# systemctl status foreman

如果您决定不依赖于 第 5.2.2 节 “Puma Worker 和 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 服务器。更多信息请参阅 第 5.1 节 “应用配置”。

为了为不同的调优配置文件推荐线程和 worker 配置，我们使用不同的调优配置文件对 Satellite 进行 Puma 调优测试。此测试中使用的主测试是与以下组合并发注册，以及不同数量的 worker 和线程。我们的建议仅基于并发注册性能，因此可能无法反映您的具体用例。例如，如果您的设置对于大量发布和提升而言非常内容，您可能希望限制 Puma 所消耗的资源，而代之为 Pulp 和 PostgreSQL。

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

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

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

在默认设置(4 个 CPU)上使用 4 个 workers (4 个 CPU)- 与 2 个 worker 相比，我们看到了大约 25% 的性能，但与 2 个 worker 相比，只有 8 个 worker 的性能较低，请参阅下表：

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

在 32 个 CPU 设置上使用 16 个是 16 个 CPUs 设置（这在 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 提高了这种情况。

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

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

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

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

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

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

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

将您的更改应用到 Satellite 服务器。更多信息请参阅 第 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 个文件描述符来运行路由器本身。

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

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

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

在使用带有大量内容主机的 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 为队列、会话和连接维护管理对象，并默认每 10 秒回收一次它们。具有相同 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），因此无法简单地提高其容量。

若要获取 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 数据目录选择文件系统也可能很重要。

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

当我们从 Satellite 服务器与 Capsule 服务器下载性能进行比较时，我们只看到 5% 的速度，但正因为胶囊服务器的主要好处是更接近地域分布的客户端（或不同网络中的客户端）以及处理负载服务器的一部分时，必须处理自身。在一些较小的硬件配置(8 个 CPU 和 24 GiB)中，Satellite 服务器无法处理从 500 多个并发客户端下载，而具有相同硬件配置的胶囊服务器可以服务超过 1000，甚至可能更多。

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