Heim > Artikel > Backend-Entwicklung > Lokalisieren und analysieren Sie die Ursachen und Folgen von Speicherlecks
Lokalisieren und analysieren Sie die Ursachen und Folgen von Speicherlecks
- 王林Original
- 2019-09-03 17:20:573643Durchsuche
Interner Leckfehlercode:
Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes)
Beobachten Sie die Speichernutzung des PHP-Programms
php bietet zwei Methoden dazu Ermitteln Sie die Speichernutzung des aktuellen Programms.
memorygetusage(), die Funktion dieser Funktion besteht darin, die aktuell vom PHP-Skript verwendete Speichergröße abzurufen.
memorygetpeak_usage(), diese Funktion gibt den vom aktuellen Skript belegten Spitzenspeicher an die aktuelle Position zurück, sodass der Speicherbedarf des aktuellen Skripts ermittelt werden kann. Die Funktion
int memory_get_usage ([ bool $real_usage = false ] ) int memory_get_peak_usage ([ bool $real_usage = false ] )
ruft standardmäßig den durch den Aufruf von emalloc() belegten Speicher ab. Wenn der Parameter auf TRUE gesetzt ist, ruft sie den Speicher ab, den das eigentliche Programm auf das System angewendet hat. Da PHP über einen eigenen Speicherverwaltungsmechanismus verfügt, wird der Speicher manchmal, obwohl er intern freigegeben wurde, nicht an das System zurückgegeben.
Die Linux-Systemdatei /proc/{$pid}/status zeichnet den laufenden Status eines Prozesses auf. Das darin enthaltene VmRSS-Feld zeichnet den vom Prozess verwendeten residenten physischen Speicher auf Der belegte physische Speicher ist zuverlässiger, und es ist auch einfacher, diesen Wert im Programm zu extrahieren.
Szenario 1: Die Programmbetriebsdaten sind zu groß
Szenariowiederherstellung: Das gleichzeitige Lesen von Daten, die die Obergrenze des verfügbaren PHP-Speichers überschreiten, führt zu Speichererschöpfung
Beispiel:
<?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
Dies sagt uns, dass das Programm, wenn es während der Ausführung versucht, neuen Speicher zuzuweisen, einen schwerwiegenden Fehler auslöst, weil es die Obergrenze des von PHP zugeteilten Speichers erreicht und kann in der Java-Entwicklung im Allgemeinen nicht mehr ausgeführt werden.
Die Obergrenze des PHP-Konfigurationsspeichers besteht darin, „memory_limit“ in php.ini festzulegen. Der Standardwert vor PHP 5.2 betrug 8 MB, der Standardwert für PHP 5.2 betrug 16 MB und der Standardwert für nachfolgende Versionen beträgt 128 MB.
Problemphänomen: Es kann bei der Verarbeitung bestimmter Daten reproduziert werden. Bei der Ausführung von E/A-Vorgängen können solche Probleme auftreten, z. B. beim Zurückgeben einer großen Datenmenge in einer MySQL-Abfrage oder beim gleichzeitigen Einlesen einer großen Datei in das Programm , usw.
Lösung:
1. Probleme, die mit Geld gelöst werden können, sind keine Probleme. Wenn das Programm nicht viele Möglichkeiten hat, große Dateien zu lesen, dann durch ini_set('memory_limit' , '1G'); um einen größeren Wert oder memory_limit=-1 festzulegen. Wenn Sie über genügend Speicher verfügen, können Sie das Programm weiter ausführen.
2. Wenn das Programm auf einer Maschine mit kleinem Speicher normal verwendet werden soll, muss das Programm optimiert werden. Wie unten gezeigt, ist der Code viel komplizierter.
<?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);Szenario 2: Kopien werden generiert, wenn das Programm mit Big Data arbeitet
Szenario-Wiederherstellung: Große Variablen werden während der Ausführung kopiert, was zu unzureichendem Speicher führt.
<?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_mm_heap corruptedSymptom: Der belegte Speicher verdoppelt sich während der Ausführung von lokalem Code.
Problemanalyse:
php ist Copy On Write, das heißt, der Speicher ändert sich nicht, wenn einer neuen Variablen ein Wert zugewiesen wird, und das Kopieren erfolgt erst, wenn der Inhalt der neuen Variablen vorhanden ist manipuliert.
Lösung:
Geben Sie nutzlose Variablen frühzeitig frei oder manipulieren Sie Originaldaten in Form von Referenzen.
<?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);Szenario 3. Systemressourcen sind aufgrund unangemessener Konfiguration erschöpft
Szenario-Wiederherstellung: Nicht genügend Speicher aufgrund unangemessener Konfiguration. Die maximale Einstellung kann auf einem 2G-Speicherrechner liegen mit 100 PHP-FPM-Kindprozessen gestartet, aber nachdem tatsächlich 50 PHP-FPM-Kindprozesse gestartet wurden, können keine weiteren Prozesse gestartet werden.
Problemphänomen: Das Problem tritt nicht auf, wenn das Anfragevolumen im Online-Geschäft gering ist. Sobald das Anfragevolumen groß ist, können einige Anfragen nicht ausgeführt werden.
Problemanalyse: Im Allgemeinen begrenzt PHP aus Sicherheitsgründen die maximale Anzahl und Größe der Formularanforderungen, die übermittelt werden können, wie z. B. post_max_size, max_file_uploads, upload_max_filesize, max_input_vars, max_input_nesting_level. Unter der Annahme, dass die Bandbreite ausreichend ist, übermitteln Benutzer häufig post_max_size = 8M-Daten an den Server und nginx leitet sie zur Verarbeitung an PHP-FPM weiter. Zusätzlich zum von ihm selbst belegten Speicher kann jeder untergeordnete PHP-FPM-Prozess 8 MB mehr Speicher belegen auch wenn es nichts bringt.
Lösung: Stellen Sie post_max_size, max_file_uploads, upload_max_filesize, max_input_vars, max_input_nesting_level und andere Parameter richtig ein und optimieren Sie PHP-FPM-bezogene Parameter.
php.ini-Code:
$ 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
Wenn die Upload-Einstellungen unangemessen sind, ist es nicht verwunderlich, dass beispielsweise in einigen Intranets viel Speicher belegt ist In diesem Szenario muss der Beitrag sehr groß sein. Wenn 200 Millionen Daten vom Formular an den Server übermittelt werden, weist PHP diesen Daten 200 Millionen Speicher zu, bis die Anforderung verarbeitet und der Speicher freigegeben wird.
Php-fpm.conf-Code:
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个请求后会自己重启一下， 可以避免一些三方扩展的内存泄露问题
Ein PHP-FPM-Prozess basiert auf 30 MB Speicher, und 50 PHP-FPM-Prozesse erfordern 1500 MB Speicher Hier muss es einfach sein. Schätzen Sie, ob allen PHP-FPM-Prozessen bei höchster Auslastung der Systemspeicher ausgeht.
Ulimit-Code:
$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
Dies ist die Konfiguration meines lokalen Mac OS. Die Dateideskriptoreinstellungen sind relativ klein und die allgemeine Konfiguration der Produktionsumgebung ist viel größer.
Szenario 4. Unbrauchbare Daten werden nicht rechtzeitig freigegeben
情景还原：这种问题从程序逻辑上不是问题，但是无用的数据大量占用内存导致资源不够用，应该有针对性的做代码优化。
Laravel开发中用于监听数据库操作时有如下代码:
代码：
DB::listen(function ($query) {
// $query->sql
// $query->bindings
// $query->time
});启用数据库监听后，每当有 SQL 执行时会 new 一个 QueryExecuted 对象并传入匿名函数以便后续操作，对于执行完毕就结束进程释放资源的php程序来说没有什么问题，而如果是一个常驻进程的程序，程序每执行一条 SQL 内存中就会增加一个 QueryExecuted 对象，程序不结束内存就会始终增长。
问题现象：程序运行期间内存逐渐增长，程序结束后内存正常释放。
问题分析：此类问题不易察觉，定位困难，尤其是有些框架封装好的方法，要明确其适用场景。
解决方法：本例中要通过DB::listen方法获取所有执行的 SQL 语句记录并写入日志，但此方法存在内存泄露问题，在开发环境下无所谓，在生产环境下则应停用，改用其他途径获取执行的 SQL 语句并写日志。
深入了解
1、名词解释
内存泄漏（Memory Leak）：是程序在管理内存分配过程中未能正确的释放不再使用的内存导致资源被大量占用的一种问题。在面向对象编程时，造成内存泄露的原因常常是对象在内存中存储但是运行中的代码却无法访问他。由于产生类似问题的情况很多，所以只能从源码上入手分析定位并解决。
垃圾回收（Garbage Collection，简称GC）：是一种自动内存管理的形式，GC程序检查并处理程序中那些已经分配出去但却不再被对象使用的内存。最早的GC是1959年前后John McCarthy发明的，用来简化在Lisp中手动控制内存管理。 PHP的内核中已自带内存管理的功能，一般应用场景下，不易出现内存泄露。
追踪法（Tracing）：从某个根对象开始追踪，检查哪些对象可访问，那么其他的（不可访问）就是垃圾。
引用计数法（reference count）：每个对象都一个数字用来标示被引用的次数。引用次数为0的可以回收。当对一个对象的引用创建时他的引用计数就会增加，引用销毁时计数减少。引用计数法可以保证对象一旦不被引用时第一时间销毁。但是引用计数有一些缺陷：1.循环引用，2.引用计数需要申请更多内存，3.对速度有影响，4.需要保证原子性，5.不是实时的。
2、php内存管理
在 PHP 5.3 以后引入了同步周期回收算法(Concurrent Cycle Collection)来处理内存泄露问题，代价是对性能有一定影响，不过一般 web 脚本应用程序影响很小。PHP的垃圾回收机制是默认打开的，php.ini 可以设置zend.enable_gc=0来关闭。也能通过分别调用gcenable() 和 gcdisable()函数来打开和关闭垃圾回收机制。
虽然垃圾回收让php开发者在内存管理上无需担心了，但也有极端的反例：php界著名的包管理工具composer曾因加入一行gc_disable();性能得到极大提升。
3、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 进程被销毁后，它所占用的所有内存都会被回收。
4、常驻进程内存泄漏问题
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 集成。
以上内容仅供参考！
Das obige ist der detaillierte Inhalt vonLokalisieren und analysieren Sie die Ursachen und Folgen von Speicherlecks. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!