定位分析内存泄漏的原因和后果-php教程

外部泄露谬误代码：

Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes)

察看php顺序内存应用状况

php提提供了两个办法来猎取以后顺序的内存应用状况。
memorygetusage()，这个函数的作用是猎取今朝PHP剧本所用的内存巨细。

memorygetpeak_usage()，这个函数的作用前往以后剧本到今朝地位所占用的内存峰值，这样就可能猎取到今朝的剧本的内存需要状况。

int memory_get_usage ([ bool $real_usage = false ] )  
int memory_get_peak_usage ([ bool $real_usage = false ] )

函数默许失去的是挪用emalloc()占用的内存，假如设置参数为TRUE，则失去的是实际顺序向零碎请求的内存。由于 PHP 有本人的内存治理机制，以是有时分虽然外部曾经开释了内存但并无还给零碎。

linux 零碎文件 /proc/{$pid}/status 会记载某个过程的运转状态，外面的 VmRSS 字段记载了该过程应用的常驻物理内存(Residence)，这个就是该过程实际占用的物理内存了，用这个数据比拟靠谱，正在顺序外面提取这个值也很容易 。

场景一：顺序操作数据过年夜

情形复原：一次性读取超越php可用内存下限的数据招致内存耗尽

实例：

<?php  ini_set('memory_limit', '128M');  
$string = str_pad('1', 128 * 1024 * 1024);    
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 134217729 bytes) 
in /Users/zouyi/php-oom/bigfile.php on line 3

这是通知咱们顺序运转时试图调配新内存时因为达到了PHP容许调配的内存下限而抛出致命谬误，无奈持续执行了，正在 java 开发中普通称之为 OOM ( Out Of Memory ) 。
PHP 设置装备摆设内存下限是正在php.ini中设置memory_limit，PHP 5.2 之前这个默许值是8M，PHP 5.2 的默许值是16M，正在这之后的版本默许值都是128M。
成绩景象：特定命据解决时可复现，做任何 IO 操作都有可能遇到此类成绩，比方：一次 mysql 查问前往年夜量数据、一次把年夜文件读取过程序等。

处理办法：

一、能用钱处理的成绩都没有是成绩，假如顺序要读年夜文件的机会没有是不少，且下限可预期，那末经过ini_set('memory_limit', '1G');来设置一个更年夜的值或许memory_limit=-1。内存管够的话让顺序不断跑也能够。

二、假如顺序需求思考正在小内存机械上也能失常应用，那就需求优化顺序了。以下，代码复杂了不少。

<?php  
//php7 如下版本经过 composer 引入 paragonie/random_compat ，为了不便来天生一个随机称号的暂时文件  
require "vendor/autoload.php";    
ini_set('memory_limit', '128M');  
//天生暂时文件寄存年夜字符串  
$fileName = 'tmp'.bin2hex(random_bytes(5)).'.txt';  
touch($fileName);  
for ( $i = 0; $i < 128; $i++ ) {      
$string = str_pad('1', 1 * 1024 * 1024);      
file_put_contents($fileName, $string, FILE_APPEND);  
}  
$handle = fopen($fileName, "r");  
for ( $i = 0; $i <= filesize($fileName) / 1 * 1024 * 1024; $i++ )  {     
//do something     
$string = fread($handle, 1 * 1024 * 1024);  
}    
fclose($handle);  
unlink($fileName);

场景2、顺序操作年夜数据时孕育发生拷贝

情形复原：执行进程中对年夜变量进行了复制，招致内存不敷用。

<?php  
ini_set("memory_limit",'1M');    
$string = str_pad('1', 1* 750 *1024);  
$string2 = $string;  $string2 .= '1';    
Fatal error: Allowed memory size of 1048576 bytes exhausted (tried to allocate 768001 bytes) 
in /Users/zouyi/php-oom/unset.php on line 8    
Call Stack:      
0.0004     235440   1. {main}() /Users/zouyi/php-oom/unset.php:0    zend_妹妹_heap corrupted

成绩景象：部分代码执行进程中占用内存翻倍。

成绩剖析：
php 是写时复制（Copy On Write），也就是说，当新变量被赋值时内存没有发作变动，直到新变量的内容被操作时才会孕育发生复制。

处理办法：

尽早开释无用变量，或许以援用的方式操作原始数据。

<?php  
ini_set("memory_limit",'1M');    
$string = str_pad('1', 1* 750 *1024);  
$string2 = $string;  unset($string);  
$string2 .= '1';    
<?php  
ini_set("memory_limit",'1M');    
$string = str_pad('1', 1* 750 *1024);  
$string2 = &$string;  
$string2 .= '1';    
unset($string2, $string);

场景3、设置装备摆设没有正当零碎资本耗尽

情形复原：因设置装备摆设没有正当招致内存不敷用，2G 内存机械上设置最年夜能够启动 100 个 php-fpm 子过程，但实际启动了 50 个 php-fpm 子过程后无奈再启动更多过程 。

成绩景象：线上营业申请量小的时分没有呈现成绩，申请量一旦很年夜后局部申请就会执行失败 。

成绩剖析：普通为了平安方面思考， php 限度表单申请的最年夜可提交的数目及巨细等参数，post_max_size、max_file_uploads、upload_max_filesize、max_input_vars、max_input_nesting_level。 假定带宽足够，用户频仍的提交post_max_size = 8M数据到效劳端，nginx 转发给 php-fpm 解决，那末每一个 php-fpm 子过程除了了本身占用的内存外，即便甚么都没有做也有可能多占用 8M 内存。

处理办法：正当设置post_max_size、max_file_uploads、upload_max_filesize、max_input_vars、max_input_nesting_level等参数并调优 php-fpm 相干参数。

php.ini代码：

$ php -i |grep memory  
memory_limit => 1024M => 1024M //php剧本执行最年夜可以使用内存  
$php -i |grep max  max_execution_time => 0 => 0 //最年夜执行工夫，剧本默许为0没有限度，web申请默许30s  
max_file_uploads => 20 => 20 //一个表单里最年夜上传文件数目  
max_input_nesting_level => 64 => 64 //一个表单里数据最年夜数组深度层数  
max_input_time => -1 => -1 //php从接纳申请开端解决数据后的超不时间  
max_input_vars => 1000 => 1000 //一个表单（包罗get、post、cookie的一切数据）最多提交1000个字段  
post_max_size => 8M => 8M //一次post申请最多提交8M数据  
upload_max_filesize => 2M => 2M //一个可上传的文件最年夜没有超越2M

假如上传设置没有正当那末呈现年夜量内存被占用的状况也没有希奇，比方有些内网场景下需求 post 超年夜字符串post_max_size=200M，那末当从表单提交了 200M 数据到效劳端， php 就会调配 200M 内存给这条数据，直到申请解决终了开释内存。

Php-fpm.conf代码 ：

pm = dynamic //仅dynamic模式下如下参数失效  
pm.max_children = 10 //最年夜子过程数  
pm.start_servers = 3 //启动时启动子过程数  
pm.min_spare_servers = 2 //最小闲暇过程数，不敷了启动更多过程  
pm.max_spare_servers = 5 //最年夜闲暇过程数，超越了却束一些过程  
pm.max_requests = 500 //最年夜申请数，留意这个参数是一个php-fpm假如解决了500个申请后会本人重启一下，
能够防止一些三方扩大的内存泄漏成绩

一个 php-fpm 过程按 30MB 内存算，50 个 php-fpm 过程就需求 1500MB 内存，这里需求简略预算一下正在负载最重的状况下一切 php-fpm 过程都启动后能否会把零碎内存耗尽。

Ulimit代码：

$ulimit -a
-t: cpu time (seconds)              unlimited  
-f: file size (blocks)              unlimited  
-d: data seg size (kbytes)          unlimited  
-s: stack size (kbytes)             8192  
-c: core file size (blocks)         0  
-v: address space (kbytes)          unlimited  
-l: locked-in-memory size (kbytes)  unlimited  
-u: processes                       1024  
-n: file descriptors                1024

这是我内陆mac os的设置装备摆设，文件形容符的设置是比拟小的，普通消费环境设置装备摆设要年夜患上多。

场景4、无用的数据未实时开释

情形复原：这类成绩从顺序逻辑上没有是成绩，然而无用的数据年夜量占用内存招致资本不敷用，应该有针对性的做代码优化。

Laravel开发顶用于监听数据库操作时有以下代码:

代码：

DB::listen(function ($query) {      
// $query->sql      
// $query->bindings      
// $query->time  
});

启用数据库监听后，每一当有 SQL 执行时会 new 一个 QueryExecuted 工具并传入匿名函数以便后续操作，关于执行终了就完结过程开释资本的php顺序来讲不甚么成绩，而假如是一个常驻过程的顺序，顺序每一执行一条 SQL 内存中就会添加一个 QueryExecuted 工具，顺序没有完结内存就会始终增进。

成绩景象：顺序运转时期内存逐步增进，顺序完结后内存失常开释。

成绩剖析：此类成绩不容易觉察，定位艰难，尤为是有些框架封装好的办法，要明白其实用场景。

处理办法：本例中要经过DB::listen办法猎取一切执行的 SQL 语句记载并写入日记，但此办法存正在内存泄漏成绩，正在开发环境下无所谓，正在消费环境下则应停用，改用其余路子猎取执行的 SQL 语句并写日记。

深化理解

一、名词诠释

内存泄露（Memory Leak）：是顺序正在治理内存调配进程中未能正确的开释再也不应用的内存招致资本被年夜量占用的一种成绩。正在面向工具编程时，造成内存泄漏的缘由经常是工具正在内存中存储然而运转中的代码却无奈拜访他。因为孕育发生相似成绩的状况不少，以是只能从源码上动手剖析定位并处理。

渣滓收受接管（Garbage Collection，简称GC）：是一种主动内存治理的方式，GC顺序反省并解决顺序中那些曾经调配进来但却再也不被工具应用的内存。最先的GC是1959年先后John McCarthy创造的，用来简化正在Lisp中手动管制内存治理。 PHP的内核中已自带内存治理的性能，普通使用场景下，不容易呈现内存泄漏。

追踪法（Tracing）：从某个根工具开端追踪，反省哪些工具可拜访，那末其余的（不成拜访）就是渣滓。

援用计数法（reference count）：每一个工具都一个数字用来标示被援用的次数。援用次数为0的能够收受接管。当对一个工具的援用创立时他的援用计数就会添加，援用销毁时计数缩小。援用计数法能够保障工具一旦没有被援用时第一工夫销毁。然而援用计数有一些缺点：1.轮回援用，2.援用计数需求请求更多内存，3.对速率有影响，4.需求保障原子性，5.没有是及时的。

二、php内存治理

正在 PHP 5.3 当前引入了同步周期收受接管算法(Concurrent Cycle Collection)来解决内存泄漏成绩，价值是对功能有肯定影响，不外普通 web 剧本使用顺序影响很小。PHP的渣滓收受接管机制是默许关上的，php.ini 能够设置zend.enable_gc=0来封闭。也能经过辨别挪用gcenable() 以及 gcdisable()函数来关上以及封闭渣滓收受接管机制。
尽管渣滓收受接管让php开发者正在内存治理上无需担忧了，但也有极其的反例：php界驰名的担保理对象composer曾因退出一行gc_disable();功能失去极年夜晋升。

三、php-fpm内存泄露成绩

正在一台常见的 nginx + php-fpm 的效劳器上：
nginx 效劳器 fork 出 n 个子过程（worker）， php-fpm 治理器 fork 出 n 个子过程。

当有用户申请， nginx 的一个 worker 接纳申请，并将申请抛到 socket 中。

php-fpm 闲暇的子过程监听到 socket 中有申请，接纳并解决申请。

一个 php-fpm 的生命周期大抵是这样的：

模块初始化（MINIT）-> 申请初始化（RINIT）-> 申请解决 -> 申请完结（RSHUTDOWN） -> 申请初始化（RINIT）-> 申请解决 -> 申请完结（RSHUTDOWN）……. 申请初始化（RINIT）-> 申请解决 -> 申请完结（RSHUTDOWN）-> 模块封闭（MSHUTDOWN）。

正在申请初始化（RINIT）-> 申请解决 -> 申请完结（RSHUTDOWN）这个“申请解决”进程是： php 读取相应的 php 文件，对其进行词法剖析，天生 opcode ， zend 虚构机执行 opcode 。
php 正在每一次申请完结后主动开释内存，无效防止了常见场景下内存泄漏的成绩，但是实际环境中因某些扩大的内存治理不做好或许 php 代码中呈现轮回援用招致未能失常开释不必的资本。
正在 php-fpm 设置装备摆设文件中，将pm.max_requests这个参数设置小一点。这个参数的含意是：一个 php-fpm 子过程最多解决pm.max_requests个用户申请后，就会被销毁。当一个 php-fpm 过程被销毁后，它所占用的一切内存城市被收受接管。

四、常驻过程内存泄露成绩

Valgrind 包罗以下一些对象：
Memcheck。这是 valgrind 使用最宽泛的对象，一个分量级的内存反省器，可以发现开发中绝年夜少数内存谬误应用状况，比方：应用未初始化的内存，应用曾经开释了的内存，内存拜访越界等。

Callgrind。它次要用来反省顺序中函数挪用进程中呈现的成绩。

Cachegrind。它次要用来反省顺序中缓存应用呈现的成绩。

Helgrind。它次要用来反省多线程顺序中呈现的竞争成绩。

Massif。它次要用来反省顺序中货仓旅馆应用中呈现的成绩。

Extension。能够行使core提供的性能，本人编写特定的内存调试对象。

Memcheck 对换试 C/C++ 顺序的内存泄漏颇有协助，它的机制是正在零碎 alloc/free 等函数挪用上加计数。 php 顺序的内存泄漏，是因为一些轮回援用，或许 gc 的逻辑谬误, valgrind 无奈探测，因而需求正在检测时需求封闭 php 自带的内存治理。

代码：

$ export USE_ZEND_ALLOC=0   
# 设置环境变量封闭内存治理  
 valgrind --tool=memcheck --num-callers=30 --log-file=php.log
/Users/zouyi/Downloads/php-5.6.31/sapi/cli/php  leak.php

援用：

definitely lost: 一定内存泄漏
indirectly lost: 非间接内存泄漏
possibly lost: 可能发作内存泄漏
still reachable: 依然可拜访的内存
suppressed: 内部酿成的内存泄漏

Callgrind 合营 php 扩大 xdebug 输入的 profile 剖析日记文件能够剖析顺序运转时期各个函数挪用时占用的内存、 CPU 占用状况。

总结：遇到了内存泄漏时先察看是顺序自身内存有余仍是内部资本招致，而后搞分明顺序运转顶用到了哪些资本：写入磁盘日记、衔接数据库 SQL 查问、发送 Curl 申请、 Socket 通讯等， I/O 操作必定会用到内存，假如这些中央都不发作显著的内存泄漏，反省那里解决年夜量数据不实时开释资本，假如是 php 5.3 如下版本还需思考轮回援用的成绩。多理解一些 Linux 下的剖析辅佐对象，处理成绩时能够事倍功半。
最初宣传一下穿云团队往年最新开源的使用通明链路追踪对象 Molten：https://github.com/chuan-yun/Molten。装置好php扩大后就能帮你及时搜集顺序的 curl,pdo,mysqli,redis,mongodb,memcached 等申请的数据，能够很不便的与 zipkin 集成。

以上内容仅供参考！

以上就是定位剖析内存泄露的缘由以及结果的具体内容，更多请存眷资源魔其它相干文章！