PHP-FPM的连接池配置：`pm.max_children`与`pm.max_requests`在高并发下的调优

PHP-FPM 连接池配置：pm.max_children 与 pm.max_requests 在高并发下的调优

大家好，今天我们来深入探讨 PHP-FPM 连接池配置中的两个关键参数：pm.max_children 和 pm.max_requests，并分析它们在高并发场景下的调优策略。理解这两个参数的作用以及它们之间的相互影响，对于构建高性能的 PHP 应用至关重要。

PHP-FPM 连接池模式回顾

在深入参数细节之前，我们先简单回顾一下 PHP-FPM 连接池的几种常见模式：

• static: 预先创建固定数量的子进程，这些进程在 FPM 启动时创建，并且一直保持运行状态。优点是启动速度快，响应速度稳定，缺点是资源占用高，即使请求量低，也会占用大量内存。

• dynamic: 根据负载动态创建和销毁子进程。FPM 会维护一个最小进程数，并在需要时创建更多进程，直到达到最大进程数。优点是资源利用率高，缺点是启动速度相对较慢，在高并发场景下可能出现进程创建延迟。

• ondemand: 只有在收到请求时才创建子进程。优点是资源占用最低，缺点是启动速度最慢，不适合对响应时间要求高的场景。

这三种模式通过 pm 指令进行配置，例如：pm = dynamic。

pm.max_children: 最大子进程数

pm.max_children 定义了 PHP-FPM 可以创建的最大子进程数。每个子进程都能够处理一个 PHP 请求。当所有子进程都在忙碌时，新的请求将被阻塞，直到有空闲的子进程可用。

核心作用： 限制并发处理请求的最大数量。

影响：

• 内存占用： 每个子进程都会占用一定的内存。pm.max_children 设置过高，会导致服务器内存耗尽，系统性能急剧下降，甚至崩溃。
• CPU 利用率： 过多的子进程会增加 CPU 上下文切换的开销，降低 CPU 利用率。
• 请求处理能力： 设置过低，在高并发场景下会导致请求排队，响应时间变长。

调优策略：

确定 pm.max_children 的最佳值需要考虑以下几个因素：

1. 服务器总内存： 这是最主要的限制因素。
2. 每个 PHP 进程的内存占用： 可以通过 ps 命令或者监控工具（如 top, htop）来观察。
3. 应用特点： 不同的应用对内存和 CPU 的需求不同。例如，需要大量数据库查询的应用可能需要更多的内存。

计算方法：

一种常用的估算方法是：

max_children = (服务器总内存 - 系统保留内存) / 每个 PHP 进程的平均内存占用

其中：

• 服务器总内存： 指服务器的物理内存总量。
• 系统保留内存： 指操作系统和其他服务（如数据库、Web 服务器）所需的内存。通常建议保留 20%-30% 的内存。
• 每个 PHP 进程的平均内存占用： 可以通过监控工具获得。

示例：

假设服务器有 8GB 内存，系统保留 2GB，每个 PHP 进程平均占用 100MB 内存，则：

max_children = (8GB - 2GB) / 100MB = (8192MB - 2048MB) / 100MB = 61.44 ≈ 61

因此，pm.max_children 可以设置为 61。

实战案例：

假设我们有一个简单的 PHP 应用，用于处理用户登录请求。该应用需要连接数据库，并执行一些简单的业务逻辑。在高并发场景下，我们发现服务器 CPU 利用率不高，但响应时间却很长。通过监控工具，我们发现 PHP 进程数量达到了 pm.max_children 的限制，并且有大量的请求在排队。

解决方案：

1. 增加 pm.max_children 的值： 根据服务器的内存情况，适当增加 pm.max_children 的值，以允许更多的并发请求被处理。
2. 优化代码： 检查代码是否存在性能瓶颈，例如低效的数据库查询、大量的 I/O 操作等。
3. 使用缓存： 使用缓存技术（如 Redis, Memcached）来减少数据库查询的次数，提高响应速度。

配置示例：

; php-fpm.conf

[global]
pid = /run/php/php7.4-fpm.pid

[www]
listen = /run/php/php7.4-fpm.sock
listen.owner = www-data
listen.group = www-data

user = www-data
group = www-data

pm = dynamic
pm.max_children = 61 ; 调整后的值
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

重要提示： 增加 pm.max_children 的值并不总是最好的解决方案。如果代码存在性能瓶颈，即使增加了 pm.max_children 的值，也可能无法显著提高性能，反而会增加服务器的负载。因此，在调整 pm.max_children 的值之前，务必先检查代码是否存在性能问题。

pm.max_requests: 子进程最大请求数

pm.max_requests 定义了每个子进程在退出之前可以处理的最大请求数。当一个子进程处理的请求数达到 pm.max_requests 时，该进程会自动退出，并由 FPM 重新启动一个新的子进程。

核心作用： 解决 PHP 进程的内存泄漏问题，并定期重置进程状态。

影响：

• 内存泄漏： PHP 应用可能会出现内存泄漏问题。即使是很小的泄漏，长时间运行也会导致进程占用越来越多的内存，最终影响性能。pm.max_requests 可以防止进程长时间运行，从而避免内存泄漏带来的问题。
• 进程状态： 有些 PHP 扩展或应用可能会在进程中留下一些状态信息。pm.max_requests 可以定期重置进程状态，确保进程的运行环境干净。
• 性能开销： 每次进程退出和启动都会带来一定的性能开销。如果 pm.max_requests 设置过低，会导致频繁的进程重启，增加服务器的负载。

调优策略：

确定 pm.max_requests 的最佳值需要在性能和稳定性之间进行权衡。

1. 监控内存占用： 监控 PHP 进程的内存占用情况。如果发现进程的内存占用随着时间的推移而增加，则说明可能存在内存泄漏问题。
2. 考虑应用特点： 如果应用使用了大量的第三方扩展，或者代码比较复杂，则更容易出现内存泄漏问题，pm.max_requests 可以设置得相对较低。
3. 性能测试： 通过性能测试来评估不同 pm.max_requests 值对性能的影响。

经验值：

通常情况下，pm.max_requests 可以设置为 500 到 2000 之间。对于内存泄漏比较严重的应用，可以设置得更低，例如 100。

实战案例：

假设我们有一个 PHP 应用，运行一段时间后，我们发现服务器的内存占用率不断增加，并且 PHP 进程的 CPU 利用率也在下降。通过监控工具，我们发现 PHP 进程的内存占用越来越高，并且没有被释放。

解决方案：

1. 设置 pm.max_requests： 设置 pm.max_requests 为一个较小的值，例如 500，以强制 PHP 进程定期重启，从而释放内存。
2. 查找内存泄漏的原因： 使用内存分析工具（如 Valgrind）来查找内存泄漏的原因，并修复代码中的问题。

配置示例：

; php-fpm.conf

[global]
pid = /run/php/php7.4-fpm.pid

[www]
listen = /run/php/php7.4-fpm.sock
listen.owner = www-data
listen.group = www-data

user = www-data
group = www-data

pm = dynamic
pm.max_children = 61
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500 ; 调整后的值

重要提示： pm.max_requests 只是一个缓解内存泄漏的手段，并不能彻底解决问题。解决内存泄漏的根本方法是找到泄漏的原因，并修复代码中的问题。

pm.max_children 和 pm.max_requests 的协同工作

pm.max_children 和 pm.max_requests 是两个相互关联的参数。pm.max_children 决定了并发处理请求的最大数量，而 pm.max_requests 则控制了每个子进程的生命周期。

最佳实践：

1. 合理设置 pm.max_children： 根据服务器的内存情况和应用的特点，合理设置 pm.max_children 的值，以确保服务器有足够的内存来处理并发请求。
2. 监控内存占用： 监控 PHP 进程的内存占用情况，并根据实际情况调整 pm.max_requests 的值。
3. 定期测试： 定期进行性能测试，以评估配置更改对性能的影响。

示例：

假设我们有一个高并发的电商网站，需要处理大量的用户请求。我们首先根据服务器的内存情况，设置了 pm.max_children 的值为 100。然后，我们通过监控工具发现 PHP 进程的内存占用随着时间的推移而增加。为了解决这个问题，我们将 pm.max_requests 设置为 1000。经过一段时间的运行，我们发现服务器的内存占用率有所下降，并且网站的响应速度也得到了提升。

高并发场景下的优化策略总结

在高并发场景下，pm.max_children 和 pm.max_requests 的调优是一个持续的过程，需要根据实际情况不断调整。以下是一些常用的优化策略：

• 使用性能分析工具： 使用性能分析工具（如 Xdebug, Blackfire）来找出代码中的性能瓶颈，并进行优化。
• 使用缓存技术： 使用缓存技术（如 Redis, Memcached）来减少数据库查询的次数，提高响应速度。
• 优化数据库查询： 优化数据库查询语句，使用索引，避免全表扫描。
• 使用 CDN： 使用 CDN 来加速静态资源的访问，减轻服务器的负载。
• 负载均衡： 使用负载均衡器将请求分发到多台服务器上，提高系统的整体吞吐量。

更多参数调优和代码示例

除了 pm.max_children 和 pm.max_requests 之外，还有许多其他的 PHP-FPM 配置参数可以进行调优，例如：

• pm.start_servers: 启动时创建的子进程数。
• pm.min_spare_servers: 保持空闲的最小子进程数。
• pm.max_spare_servers: 保持空闲的最大子进程数。
• request_terminate_timeout: PHP 脚本的最大执行时间。
• request_slowlog_timeout: 记录慢日志的阈值。

以下是一些代码示例，演示了如何使用这些参数进行调优：

调整 pm.start_servers, pm.min_spare_servers, pm.max_spare_servers：

; php-fpm.conf

[www]
pm = dynamic
pm.max_children = 61
pm.start_servers = 20  ; 调整后的值
pm.min_spare_servers = 10 ; 调整后的值
pm.max_spare_servers = 30 ; 调整后的值
pm.max_requests = 500

调整 request_terminate_timeout：

; php-fpm.conf

[www]
pm = dynamic
pm.max_children = 61
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500
request_terminate_timeout = 60s ; 调整后的值

配置慢日志：

; php-fpm.conf

[www]
pm = dynamic
pm.max_children = 61
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500
request_slowlog_timeout = 3s
slowlog = /var/log/php7.4-fpm.log.slow

性能监控和诊断至关重要

监控是性能调优的基础。我们需要收集各种指标，例如 CPU 利用率、内存占用率、磁盘 I/O、网络流量、PHP 进程数量、请求响应时间等。常用的监控工具包括：

• top, htop: 命令行工具，用于实时监控系统资源使用情况。
• vmstat: 命令行工具，用于报告虚拟内存统计信息。
• iostat: 命令行工具，用于报告磁盘 I/O 统计信息。
• netstat: 命令行工具，用于报告网络连接信息。
• Prometheus, Grafana: 开源监控和可视化工具，可以收集和展示各种指标。
• New Relic, Datadog: 云监控服务，提供更高级的监控和告警功能。

通过监控这些指标，我们可以及时发现性能问题，并采取相应的措施。

总结一下

pm.max_children 控制并发，pm.max_requests 限制生命周期；调整这些参数是优化高并发 PHP 应用的关键，需要结合实际服务器资源和应用特点，并持续进行性能监控和调优。