CentOS 上 PHP 运行慢的排查与优化清单

遇到 PHP 应用响应迟缓，别急着重启服务器。一套系统性的排查与优化组合拳，往往能直击要害。下面这份清单，从定位瓶颈到实施优化，再到验证效果，帮你一步步把性能“追”回来。

一 定位瓶颈

优化第一步，得先知道“慢”在哪里。盲目调整参数，无异于隔靴搔痒。

• 开启 PHP-FPM 慢日志，先找出“慢脚本”。这是最直接的线索。在池配置文件 /etc/php-fpm.d/www.conf 中设置：
  • request_slowlog_timeout = 1s
  • slowlog = /var/log/php-fpm/www-slow.log
  然后重载服务：systemctl reload php-fpm。那些执行超过1秒的请求，都会被记录在案。
• 打开 PHP 错误日志，便于发现异常与告警。有时候，慢是因为隐藏的错误或警告在消耗资源。确保配置：
  • log_errors = On
  • error_log = /var/log/php-fpm/www-error.log
• 在 Nginx 侧同时记录慢请求，便于端到端分析。PHP-FPM 慢日志看的是脚本执行时间，而 Nginx 可以记录从接收到响应的全链路时间。在 http 块定义慢日志格式与条件，例如将超过 1s 的请求单独记录，这需要用到 map 与条件日志的写法。
• 用系统工具观察资源：top/htop 看 CPU、内存，vmstat 看进程、内存、I/O，iostat 看磁盘。确认是否存在 CPU 满载、内存耗尽或 I/O 等待过高的情况。
• 用性能分析工具对热点函数定位：如果代码层面是瓶颈，就需要更精细的工具。比如 Xdebug 的 Profiler，或者 Blackfire。切记，这类工具开销较大，仅在测试环境启用，避免对生产环境造成额外性能损耗。

二 必做优化

定位问题后，就可以着手优化了。下面这些是经过验证的、收益明显的“必选项”。

• 启用并正确配置 OPcache。对于 PHP 7.0 及以上版本，这是提升性能的头号功臣，它能缓存预编译的字节码，避免每次请求都重复编译。配置文件通常为 /etc/php.d/10-opcache.ini。
  • 关键参数建议：
    • opcache.enable = 1 （必须开启）
    • opcache.memory_consumption = 128–256 （MB，根据项目大小调整）
    • opcache.interned_strings_buffer = 16 （MB，减少字符串内存占用）
    • opcache.max_accelerated_files = 20000 （缓存的文件数上限）
    • opcache.validate_timestamps = 0 （生产环境建议关闭，避免频繁检查文件变更。部署新代码后，通过重启 PHP-FPM 或发送重载信号来更新缓存）
    • opcache.revalidate_freq = 60 （如果上面设为1，则此项定义检查间隔）
    • opcache.fast_shutdown = 1 （加速清理）
  • 修改后，记得重启 Web 服务或 PHP-FPM 使其生效。
• 优化 PHP-FPM 进程管理。进程池配置不当，要么资源闲置，要么请求排队。
  • 进程模型：优先选择 dynamic 或 ondemand。
  • 关键参数示例（需结合服务器内存和实际压测结果微调）：
    • pm = dynamic
    • pm.max_children = 50 （最大子进程数）
    • pm.start_servers = 5 （启动时的进程数）
    • pm.min_spare_servers = 5 （最小空闲进程）
    • pm.max_spare_servers = 35 （最大空闲进程）
    • pm.max_requests = 1000 （每个进程处理一定请求后重启，有助于缓解潜在的内存泄漏）
• 升级 PHP 版本 并利用 JIT。如果还在用 PHP 5.x 或 7.x，升级到 8.x 本身就是巨大的性能提升。对于 PHP 8.x，可以启用 JIT（即时编译）来进一步提升计算密集型任务的性能。
  • 启用 JIT（示例）：opcache.jit_buffer_size = 256M；opcache.jit = 1235
  • 验证：执行 php -r “echo json_encode(opcache_get_status());”，查看输出中 jitted_functions_count 是否在增加。
• 精简扩展与禁用危险函数。加载不必要的扩展会浪费内存，而危险函数则可能带来安全风险。
  • 列出已加载模块：php -m。将不使用的扩展配置文件重命名（如将 /etc/php.d/gd.ini 改为 gd.ini.bak），变更后重启服务。
  • 在 php.ini 中禁用高危函数（根据应用实际需要调整）：disable_functions = exec,passthru,shell_exec,system,proc_open,popen
• 调整基础 php.ini 参数。一些默认设置可能成为瓶颈。
  • memory_limit = 256M （根据应用需要调整）
  • max_execution_time = 30
  • max_input_time = 60
  • post_max_size = 16M
  • upload_max_filesize = 10M
  • display_errors = Off；log_errors = On （生产环境务必关闭错误显示）
  • 可选调整：output_buffering = On；implicit_flush = Off （优化输出控制）
• Web 服务器与内容层面优化。别让 PHP 处理所有事情。
  • 在 Nginx/Apache 中启用 Gzip 压缩，有效减少网络传输体积。
  • 将图片、CSS、JS 等静态资源交给 CDN，并设置合理的浏览器缓存策略，直接从源头降低后端 PHP 的压力。

三 数据库与缓存层优化

很多时候，PHP 慢的根源在数据库。优化这一层，效果立竿见影。

• 数据库连接与查询
  • 使用持久连接（如 PDO::ATTR_PERSISTENT），可以减少每次请求建立数据库连接握手带来的开销。
  • 为高频查询条件字段建立合适的索引，避免使用 SELECT *，定期分析并优化慢查询。
  • 对于读多写少的场景，可以合理设置 MySQL 的 query_cache_type = 1 与 query_cache_size（如 64M）。需要注意，在高并发写入场景下，查询缓存可能因频繁失效而降低性能。
• 引入内存缓存
  • Redis：安装 Redis 服务及 PHP 的 Redis 扩展（如 php-pecl-redis），在业务侧缓存热点数据、复杂的查询结果或完整的页面片段。
  • Memcached：安装 Memcached 服务及 PHP 的 Memcached 扩展（如 php-pecl-memcached），适合简单的键值对缓存场景。
  • 将会话（Session）存储从默认的文件系统切换到 Redis 或 Memcached，能显著减少文件 I/O 操作和锁竞争，提升并发能力。

四 参数调优参考与计算

知其然，更要知其所以然。了解关键参数背后的计算逻辑，才能做出最适合自己环境的调整。

• PHP-FPM 进程数估算
  • 核心公式：max_children ≈ (为 PHP-FPM 预留的可用内存 − 系统/其他服务占用) / 单个 PHP 进程平均内存
  • 经验值参考：每个 PHP 进程内存占用约 5–15MB（这与使用的框架、加载的扩展密切相关，务必通过压测校准）。
  • 示例：如果计划为 PHP-FPM 预留 1GB 内存，实测单个进程平均占用 10MB，那么 max_children 理论上可设为 100 左右。再结合预期的并发量，通过压测最终确定 start_servers、min_spare_servers 和 max_spare_servers 的值。
• OPcache 关键项
  • 生产环境最佳实践：设置 validate_timestamps = 0，并在每次代码部署后，通过重启 PHP-FPM 或发送 opcache_reset() 信号来主动更新缓存。如果做不到，可将 revalidate_freq 设为 60s 作为折中方案。
  • 对于大型项目，可以适当提高 max_accelerated_files（如 20000）和 memory_consumption（如 256MB），确保所有文件都能被缓存。
• JIT 启用要点
  • JIT 仅在 PHP 8.x 及以上版本支持。一个常用的配置组合是：opcache.jit = 1235，opcache.jit_buffer_size = 256M。
  • 通过 opcache_get_status() 函数返回信息中的 jitted_functions_count 字段，可以验证 JIT 是否生效以及命中情况。

五 快速验证与回滚

优化不是一劳永逸，验证和回滚方案同样重要。

• 每次变更后，执行 systemctl reload php-fpm（或 restart）使配置生效，并立即观察 php-slow.log、php-error.log 以及业务监控指标，确认无异常。
• 使用压测工具量化效果。用像 wrk 这样的工具，对比优化前后的响应时间（RT）、每秒请求数（RPS）以及 95/99 分位延迟，用数据说话，确认优化收益。
• 分阶段上线，保留回滚方案。所有优化，先在测试或灰度环境充分验证。生产环境变更时，确保有完整的回滚方案，包括配置回滚和版本回滚两条路径。