PHP在Linux上的内存泄漏怎么办

PHP在Linux上的内存泄漏排查与修复

一、快速确认与定位思路

• 观察趋势：在 Linux 上先用 free -h、top/htop 查看系统内存与 PHP-FPM 子进程常驻内存是否随请求数持续增长，确认是否为真实泄漏而非偶发峰值。
• 服务日志：检查 /var/log/php-fpm.log、/var/log/nginx/error.log、/var/log/apache2/error.log 是否出现内存不足或异常增长记录。
• 区分场景：区分 CLI 长脚本（如队列、导入）与 PHP-FPM（多进程模型）的泄漏特征，前者看单次执行内存曲线，后者看进程重启前后 RSS 是否“只增不减”。
• 初步判断：若仅提升 memory_limit 能缓解但 RSS 仍持续攀升，多半是泄漏或资源未释放。

二、工具链与命令清单

• 运行时观测：在代码中埋点使用 memory_get_usage() / memory_get_peak_usage() 打印内存变化，定位增长阶段。
• 引用环回收：对可能产生循环引用的逻辑，显式调用 gc_enable() / gc_collect_cycles() 验证可回收性。
• 请求级分析：启用 Xdebug 生成内存分配/调用跟踪，或用 Blackfire 查看内存趋势与热点函数。
• 原生内存诊断：对 CLI 脚本用 Valgrind + Memcheck 检测内存错误与泄漏（注意性能开销）。
• 资源泄漏排查：用 lsof -p <PHP_PID> 检查未关闭的文件/套接字；对扩展或底层问题可用 GDB 辅助。
• 扩展与依赖：确保 PHP、PHP-FPM 与扩展为稳定版本，及时升级修复已知问题。

三、常见根因与修复要点

• 全局/静态变量累积：长期向 $GLOBALS / static 追加数据会驻留内存，改为 Redis/Memcached 等外部缓存，或在逻辑结束后 unset() 并周期性清理。
• 循环引用：对象互相持有导致引用计数无法释放，使用 gc_collect_cycles() 验证，必要时重构为弱引用或拆分对象生命周期。
• 资源未释放：数据库连接、文件句柄、会话等未关闭，使用 try/finally 或等效模式确保释放，并用 lsof 排查句柄泄漏。
• 大数据一次性加载：避免 range()/fetchAll() 等一次性装入，改用 生成器 yield 与 分块处理。
• 第三方扩展/库：升级或替换已知有泄漏的扩展，最小化启用扩展，逐个排除。

四、PHP-FPM 专项治理

• 控制进程生命周期：设置 pm.max_requests（如 500）让子进程处理一定请求后自动重启，配合 pm.max_children 合理控峰，作为“兜底”手段。
• 监控与告警：用 htop 按内存排序观察 PHP-FPM 子进程 RSS 是否随请求单调上升；结合日志与业务指标建立基线告警。
• 配置优化：避免无限制提升 memory_limit，优先修复泄漏与优化内存占用；保持 PHP-FPM/PHP 与扩展版本更新。

五、最小可行排查示例

• 步骤1：在关键阶段打印内存与峰值
  • 代码示例：echo “before=” . memory_get_usage() . " peak=" . memory_get_peak_usage() . “\n”;
• 步骤2：在可疑循环后主动触发回收
  • 代码示例：gc_enable(); $before = memory_get_usage(); gc_collect_cycles(); $after = memory_get_usage(); echo “collected=” . ($before - $after) . “\n”;
• 步骤3：CLI 复现并用 Valgrind 检测
  • 命令示例：valgrind --leak-check=full php your_script.php（仅在非生产环境使用，开销较大）。
• 步骤4：FPM 侧观察与兜底
  • 观察：watch -n 1 “ps -o pid,rss,cmd -C php-fpm”；配置：pm.max_requests=500 自动重启子进程。