背景
这是08年写的一份文档，我当时在一家网站刚接手做技术负责人，网站每天大概有60万ip/300万pv的访问，网站产品很复杂，代码结构差，开发工程师来来去去，代码只能只读了。突然有一天开始频繁出现php-fpm进程耗光内存和cpu占有率飙升，前端频繁出现504错误
php-fpm进程耗光内存
这个就是传说中的内存泄露，所谓内存泄露，是指进程在运行过程中，内存占用率逐步上升而不释放，导致系统可用内存越来越少的情况
严格上说，这个也不算致命错误，“内存泄露”只对长期运行的程序有威胁，对单一任务的执行脚本不需要担心,最简单的处理方式，是定时重启进程。php-fpm的配置信息里面有个max_request,就定义一个fastcgi进程处理完多少个请求之后退出这样系统可用释放掉内存，但是如果内存占用率增长速度非常快，频繁重启进程，就会影响服务的稳定性，所以这个问题必须正面解决
内存泄露排查非常困难
因为代码规模非常大，想靠做code review的方式来查基本上不可能, 而php并非运行在虚拟机上，没有什么官方的monitor（类似java hprof,JVM Monitor等）,在互联网上搜索，找不到任何答案探索解决问题
valgrind方案
用valgrind调试php-cgi进程
Valgrind 是一个linux常用的程序的内存调试和代码剖析，对调试C/C++程序的内存泄露很有帮助，它的机制是在系统alloc/free等函数调用上加计数。用 valgrind 调试php-cgi，要求php-cgi 是debug版本，实践证明行不通：
-
php-cgi debug 版本放在线上根本跑不起来，性能太差
-
php程序的内存泄露，是由于一些循环引用，或者gc的逻辑错误,valgrind无法探测，它适合去检查php解释器是否有内存泄露问题
备注：php解释器（Zend core）自带有检查内存泄露的机制，php解释器的核心代码叫做（Zend Core)
php自带检查
调试php-cgi进程，我查看了php-cgi的代码，发现zend core 实现了内存泄露的自我检查
但是 同上原因，php-cgi debug 跑不起来，也无法得到调试信息
FreeBSD 的 DTrace
DTrace是freebsd 系统支持的核心调试器，可以在各个系统函数调用上加计数点,twitter曾经用过。这个方法最后没有使用 有如下原因：
- 需要找一台服务器安装freebsd,并部署到线上、或者模拟负载，非常繁琐
- 我仔细研究了DTrace的文档，发现这个可以认为是增强的 valgrind，也不能解决我们的问题
这3种方法都不行，陷入困境.但是换个角度思考:
虽然解决php程序内存泄露没有方便的工具，但是 web 程序是按请求切分的，一个http请求，对应的php进程执行一个php文件
一个自然的想法是，记录 每次 http请求处理前后php进程的内存占用率之差，然后对结果排序，就能找出，让进程内存增加可能性最大的 文件 ，这个文件导致内存泄露的可能性最大
计算进程内存占用率有两种方式
-
php内置函数memory_get_usage
这个函数是 Zend Core里面一个计数器，是zend core认为的内存使用量，但是php内存泄露有可能是zend core逻辑错误导致的，所以memory_get_usage不一定可靠 -
linux 系统文件 /proc/{$pid}/status 会记录某个进程的运行状态，里面的
VmRSS 字段记录了该进程使用的常驻物理内存(Residence)，这个就是该进程实际占用的物理内存了，用这个数据比较靠谱，在程序里面提取这个值也很容易
找到思路，就可以开始动手写程序
直接修改了php-cgi的源代码，在main.c里面处理每个fastcgi请求前后分别加计数代码，输出日志到log文件，重新编译上线
运行30分钟之后，执行
cat short.log| awk '{print $3 "\t" $7 "\t" $6 "\t" $4$5}' |sort -r -n |head -n 100
很容易找到最可能出现内存泄露的代码文件，然后进一步排查，重构代码，这就很简单了：能不加载的文件就不加载，大数组用完之后赶紧unset …
搞定！
后面的故事
后来，我才发现其实不需要去修改php的源代码，php.ini配置文件里面有两个配置项： auto_append_file,auto_prepend_file，可以在请求前后注入代码 …
真是悲剧
web程序做性能优化也是这个思路，但是要简单很多，无需写代码，在nginx log里面加上$request_time ，用awk/sort 处理一下就可以找出瓶颈。