Ubuntu PHP日志中的性能瓶颈怎么找

Ubuntu PHP日志定位性能瓶颈的实用流程

一 先打通可观测性

• 启用并规范 PHP 错误日志：在 php.ini 中设置
  error_reporting = E_ALL
  display_errors = Off（生产环境避免暴露到页面）
  log_errors = On
  error_log = /var/log/php_errors.log
  修改后重启 Apache 或 PHP-FPM。
• 打开 PHP-FPM 慢日志：在 www.conf/php-fpm.conf 中设置
  slowlog = /var/log/php-fpm/slow.log
  request_slowlog_timeout = 10s（先设 10 秒捕获明显慢点，再逐步收敛阈值）。
• 打开数据库慢查询日志（以 MySQL 为例）：在 my.cnf 的 [mysqld] 段设置
  slow_query_log = 1
  slow_query_log_file = /var/log/mysql/slow-query.log
  long_query_time = 1–2（先宽松，再按百分位收紧）。
• Web 服务器日志：确保 Nginx/Apache 的 access.log/error.log 正常输出，便于关联请求路径、状态码与耗时。
• 系统资源监控：使用 top/htop/atop 观察 CPU、内存、I/O 是否成为瓶颈。
  以上配置与路径为 Ubuntu 常见做法，具体版本或 SAPI 可能略有差异。

二 从 PHP-FPM 慢日志定位脚本级瓶颈

• 实时观察：tail -f /var/log/php-fpm/slow.log，优先关注超过阈值的请求栈。
• 解读要点：
  • 首行通常包含 pool、pid、request_uri，快速定位到具体接口或脚本；
  • 随后是 script_filename 与 line，直达文件与行号；
  • 堆栈中出现的函数/方法即潜在热点（如外部 API 调用、复杂计算、循环内查询）。
• 快速示例（阈值 10s）：
  slowlog = /var/log/php-fpm/slow.log
  request_slowlog_timeout = 10s
  分析时优先处理“重复出现、累计耗时高”的调用栈。
• 辅助工具：使用 Webgrind 等可视化工具对慢日志进行调用图与热点分析，加速定位。

三 从数据库慢查询定位 SQL 级瓶颈

• 初步筛查：tail -f /var/log/mysql/slow-query.log，关注字段 Query_time、Lock_time、Rows_sent、Rows_examined。
• 识别问题模式：
  • Query_time 明显偏大；
  • Rows_examined 远大于 Rows_sent（疑似全表扫描或缺少索引）；
  • 频繁出现的相同语句（适合做批量优化或缓存）。
• 深入分析与优化：
  • 对问题 SQL 执行 EXPLAIN，检查是否走索引、扫描方式、临时表/文件排序等；
  • 增加或改写索引、避免 SELECT *、优化 JOIN/子查询、分页与批量处理；
  • 使用 mysqldumpslow 聚合分析：mysqldumpslow -s at -t 10 /var/log/mysql/slow-query.log（按平均时间取前 10）；
  • 使用 pt-query-digest 做更细粒度分析（按指纹聚合、识别最耗时的 SQL 模板）。
• 经验要点：多数 PHP 慢请求与 N+1 查询、未命中索引、缺少缓存有关，优先从这几类问题入手。

四 关联访问日志与系统指标进行端到端定位

• 关联分析：用 Nginx/Apache access.log 的 $request_time/$upstream_response_time（或 X-Request-Start/X-Response-Time 自定义头）与 PHP-FPM 慢日志时间戳对齐，判断瓶颈是在 PHP 执行、数据库、还是 上游/网络。
• 资源瓶颈排查：
  • CPU 高：可能存在无限循环、正则回溯、加密/压缩等重计算；
  • 内存高：检查大对象、循环内生成数组、缓存滥用；
  • I/O 高：关注日志/临时文件/数据库磁盘吞吐。
• 辅助工具：结合 top/htop/atop 实时观察，必要时用 Prometheus + Grafana 做长期可视化监控与告警。

五 用 APM 与火焰图做代码级精确定位

• 性能剖析：在开发/预发环境接入 Xdebug 或 Blackfire.io，获取函数级调用图与耗时分布，快速定位“热点函数/方法”。
• 线上友好：使用 Blackfire 的采样分析减少开销，聚焦关键接口与峰值时段。
• 可视化：配合 Webgrind/KCacheGrind 查看调用树与累计耗时，验证优化收益。

六 优化与风险控制清单

• 配置优化（示例值，按业务调整）：
  • PHP：memory_limit = 256M、max_execution_time = 30（避免过长阻塞）；
  • PHP-FPM：合理设置 pm.max_children、request_terminate_timeout，并持续观察慢日志；
  • MySQL：long_query_time = 1–2，必要时开启 log_queries_not_using_indexes 辅助发现无索引查询。
• 代码与架构：
  • 解决 N+1 查询（预加载/批量查询）、减少循环内数据库/HTTP 调用；
  • 引入 Redis/Memcached 做热点数据与计算结果缓存；
  • 对大文件/耗时任务做异步化与队列化。
• 日志治理：
  • 避免日志级别过高导致磁盘占满与 I/O 抖动；
  • 使用 logrotate 自动轮转与压缩，例如：
    /var/log/php_errors.log {
    daily; missingok; rotate 7; compress; delaycompress; notifempty;
    create 640 www-data adm
    }
  • 定期清理与监控日志目录容量，防止因磁盘满导致服务异常。