生产环境PHP内存泄漏调试：利用GDB与Core Dump分析常驻进程的内存增长 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

生产环境PHP内存泄漏调试：GDB与Core Dump实战分析

各位同学，大家好。今天我们来聊聊生产环境中PHP内存泄漏的调试问题。相信很多同学都遇到过类似情况：PHP常驻进程（比如FPM、Swoole）运行一段时间后，内存占用持续增长，最终导致性能下降甚至崩溃。这种情况下，如何定位并解决内存泄漏就变得至关重要。

本次讲座主要围绕以下几个方面展开：

内存泄漏的基本概念与PHP的内存管理机制
Core Dump的生成与配置
GDB的基本使用与PHP扩展调试
实战案例分析：利用GDB与Core Dump定位内存泄漏
预防内存泄漏的最佳实践

1. 内存泄漏的基本概念与PHP的内存管理机制

1.1 什么是内存泄漏？

简单来说，内存泄漏指的是程序在动态分配内存后，由于某种原因未能释放不再使用的内存，导致这部分内存无法被再次利用，从而造成内存浪费。长期积累的内存泄漏会导致系统可用内存逐渐减少，最终影响程序的性能和稳定性。

1.2 PHP的内存管理机制

PHP的内存管理机制主要依赖于Zend Engine。Zend Engine采用引用计数的方式管理内存。

引用计数: 每个PHP变量都关联一个引用计数器。当一个变量被赋值给另一个变量时，引用计数器加1。当变量超出作用域或被unset时，引用计数器减1。当引用计数器变为0时，Zend Engine会自动释放该变量所占用的内存。

然而，引用计数机制并不能解决所有内存泄漏问题。最常见的问题是循环引用。

循环引用示例：

<?php

class A {
    public $b;
}

class B {
    public $a;
}

$a = new A();
$b = new B();

$a->b = $b;
$b->a = $a;

// 此时，$a和$b都持有对方的引用，引用计数器永远不会变为0，即使unset也无法释放内存
unset($a);
unset($b);

// 内存泄漏
?>

在这个例子中，$a和$b互相引用，形成了一个循环引用。即使我们使用unset释放了变量，由于它们仍然相互引用，引用计数器仍然大于0，导致它们所占用的内存无法被释放，最终造成内存泄漏。

1.3 其他可能导致内存泄漏的原因

除了循环引用，还有一些其他原因可能导致PHP内存泄漏：

未正确关闭的文件句柄、数据库连接等资源: 如果程序打开了文件或数据库连接，但忘记在使用完毕后关闭，会导致资源泄漏，间接造成内存泄漏。
PHP扩展中的内存管理问题: 如果使用的PHP扩展存在bug，可能会导致扩展本身分配的内存无法被正确释放。
长期运行的脚本中的缓存问题: 某些长期运行的脚本可能会缓存大量数据，如果缓存策略不合理，会导致内存占用持续增长。

2. Core Dump的生成与配置

2.1 什么是Core Dump?

Core Dump是一个进程在发生异常退出时，操作系统将该进程的内存映像、寄存器状态以及其他调试信息保存到磁盘上的文件。我们可以使用调试器（比如GDB）打开Core Dump文件，分析进程崩溃时的状态，从而定位问题。

2.2 配置Core Dump生成

在生产环境中，默认情况下Core Dump可能没有开启。我们需要进行一些配置才能生成Core Dump文件。

检查当前配置: 使用ulimit -c命令查看当前Core Dump文件大小的限制。如果结果是0，表示Core Dump功能被禁用。
开启Core Dump:
- 临时开启: 使用ulimit -c unlimited命令可以临时开启Core Dump功能，并将Core Dump文件大小限制设置为无限制。注意：这个设置只在当前shell会话有效。
- 永久开启: 修改/etc/security/limits.conf文件，添加以下内容：
```
*               soft    core            unlimited
*               hard    core            unlimited
```
  这将允许所有用户生成无限制大小的Core Dump文件。 注意：修改该文件需要root权限，并且需要重新登录才能生效。
配置Core Dump文件保存路径和命名规则: 修改/proc/sys/kernel/core_pattern文件可以配置Core Dump文件的保存路径和命名规则。
- 默认路径: 默认情况下，Core Dump文件保存在当前工作目录下，文件名为core。
- 自定义路径和命名规则: 可以使用以下命令修改/proc/sys/kernel/core_pattern文件：
```
echo "/var/core/core.%e.%p.%t" > /proc/sys/kernel/core_pattern
```
  这个配置会将Core Dump文件保存在/var/core目录下，文件名为core.<程序名>.<进程ID>.<时间戳>。
  
  解释:
  - %e: 程序名
  - %p: 进程ID
  - %t: 时间戳
  注意：修改/proc/sys/kernel/core_pattern文件需要root权限。为了永久生效，可以将该命令添加到/etc/sysctl.conf文件中，并执行sysctl -p命令。

2.3 确保PHP进程有写入Core Dump文件的权限

需要确保PHP进程（比如FPM进程的用户）有权限写入Core Dump文件保存的目录。例如，如果Core Dump文件保存在/var/core目录下，需要确保FPM进程的用户对/var/core目录有写入权限。

示例： 假设FPM进程的用户是www-data，可以使用以下命令赋予www-data用户对/var/core目录的写入权限：

chown www-data:www-data /var/core
chmod 770 /var/core

3. GDB的基本使用与PHP扩展调试

3.1 GDB的基本命令

GDB (GNU Debugger) 是一个强大的调试器，可以用来分析Core Dump文件，查看进程崩溃时的状态。以下是一些常用的GDB命令：

命令	描述
`gdb <程序名> <Core Dump文件>`	启动GDB并加载程序和Core Dump文件
`bt`	打印函数调用栈
`frame <编号>`	切换到指定编号的栈帧
`info locals`	显示当前栈帧的局部变量
`print <变量名>`	打印变量的值
`next`	单步执行，跳过函数调用
`step`	单步执行，进入函数调用
`continue`	继续执行程序
`quit`	退出GDB

3.2 PHP扩展调试

如果内存泄漏发生在PHP扩展中，我们需要加载扩展的调试符号才能进行更深入的分析。

编译扩展时添加调试信息: 在编译PHP扩展时，需要添加-g选项，生成包含调试信息的扩展。例如：
```
./configure --enable-your_extension --with-php-config=/path/to/php-config CFLAGS="-g"
make
make install
```
加载扩展的调试符号: 在GDB中，可以使用add-symbol-file <扩展名>.so <加载地址>命令加载扩展的调试符号。 <加载地址>可以通过以下方法获取：
1. 在PHP中，使用dlopen()函数加载扩展。
2. 使用php -r 'phpinfo();'命令查看phpinfo信息，找到扩展加载的地址。
3. 在GDB中，使用info sharedlibrary命令查看已加载的共享库及其地址。
示例：
```
gdb /usr/local/bin/php /var/core/core.php-fpm.12345.1678886400
(gdb) info sharedlibrary
From        To          Syms Read   Shared Object Library
0x00007f...  0x00007f...  Yes (*)     /usr/lib/php/20210902/your_extension.so
(gdb) add-symbol-file /usr/lib/php/20210902/your_extension.so 0x00007f...
```

4. 实战案例分析：利用GDB与Core Dump定位内存泄漏

4.1 模拟内存泄漏场景

我们先模拟一个简单的内存泄漏场景：

<?php

// leak.php

function leak_memory() {
    $data = [];
    for ($i = 0; $i < 10000; $i++) {
        $data[] = str_repeat('A', 1024); // 每次循环分配1KB内存
        //unset($data[$i]);  // 如果取消注释这行，就不会发生内存泄漏
    }
}

while (true) {
    leak_memory();
    sleep(1);
}

?>

这个脚本在一个无限循环中，不断向数组$data中添加字符串，模拟内存泄漏。如果取消注释unset($data[$i]);，每次循环都会释放掉之前分配的内存，就不会发生内存泄漏。

4.2 运行脚本并触发Core Dump

使用php leak.php命令运行脚本。
等待一段时间，观察PHP进程的内存占用情况。可以使用top命令或者ps aux | grep php命令查看。
当PHP进程的内存占用达到一定程度时，使用kill -6 <进程ID>命令发送SIGABRT信号，强制PHP进程退出并生成Core Dump文件。（-6对应的是SIGABRT信号，也可以使用-11发送SIGSEGV信号，但SIGABRT更适合主动触发Core Dump，SIGSEGV通常是程序出错导致的。）

4.3 使用GDB分析Core Dump文件

使用gdb /usr/local/bin/php /var/core/core.php.12345.1678886400命令启动GDB，并加载PHP程序和Core Dump文件。
使用bt命令打印函数调用栈。通常情况下，调用栈会很长，我们需要找到与我们脚本相关的栈帧。
使用frame <编号>命令切换到与我们脚本相关的栈帧。可以通过阅读调用栈信息，找到包含leak_memory函数的栈帧。
使用info locals命令查看当前栈帧的局部变量。我们可以看到$data数组的内容，以及其占用的内存大小。
使用print sizeof($data)命令打印$data数组的大小。（这个命令可能在GDB中无法直接使用，因为sizeof是PHP函数。我们需要找到更底层的C语言数据结构来查看。）
关键步骤：查找内存分配相关的函数调用。 在函数调用栈中，我们需要关注与内存分配相关的函数调用，比如malloc、emalloc（Zend Engine提供的内存分配函数）等。如果发现某个函数被频繁调用，且没有相应的释放操作，很可能就是内存泄漏的根源。

更高级的调试技巧：

使用GDB的watch命令监视变量的值。 例如，我们可以使用watch sizeof($data)命令监视$data数组的大小变化。
使用GDB的break命令设置断点。 例如，我们可以使用break leak.php:5命令在leak_memory函数的第5行设置断点，然后使用continue命令继续执行程序，当程序执行到断点时，GDB会自动暂停，我们可以查看当前程序的状态。
结合Valgrind等内存检测工具。 Valgrind是一个强大的内存检测工具，可以检测内存泄漏、内存越界等问题。可以将Valgrind与GDB结合使用，进行更深入的内存分析。

4.4 分析结果并定位问题

通过分析GDB的输出，我们可以发现leak_memory函数中，$data数组不断增长，但没有释放内存的操作，导致内存泄漏。

4.5 解决内存泄漏

解决内存泄漏的方法很简单，只需要在每次循环结束后，使用unset释放掉之前分配的内存即可：

<?php

// leak.php

function leak_memory() {
    $data = [];
    for ($i = 0; $i < 10000; $i++) {
        $data[] = str_repeat('A', 1024); // 每次循环分配1KB内存
        unset($data[$i]);  // 释放内存
    }
}

while (true) {
    leak_memory();
    sleep(1);
}

?>

5. 预防内存泄漏的最佳实践

避免循环引用: 在设计程序时，尽量避免循环引用。如果必须使用循环引用，可以使用弱引用或者手动解除引用。
及时释放资源: 在使用完毕后，及时关闭文件句柄、数据库连接等资源。
使用unset释放不再使用的变量: 当一个变量不再使用时，及时使用unset释放掉它所占用的内存。
注意PHP扩展的内存管理: 如果使用的PHP扩展存在bug，可能会导致内存泄漏。及时更新扩展到最新版本，或者寻找替代方案。
使用内存分析工具进行定期检测: 可以使用Valgrind等内存分析工具对程序进行定期检测，及早发现潜在的内存泄漏问题。
代码审查： 定期进行代码审查，特别是涉及资源管理的部分，确保没有遗漏的释放操作。
限制脚本执行时间与内存使用： 通过max_execution_time和memory_limit配置项限制脚本的执行时间和内存使用，防止因内存泄漏导致服务器崩溃。

以上就是关于生产环境PHP内存泄漏调试的全部内容。希望通过本次讲座，大家能够掌握利用GDB与Core Dump分析内存泄漏的基本方法，并在实际工作中运用这些技巧，解决实际问题。

预防重于治疗

预防内存泄漏远比事后调试来的有效。通过良好的编程习惯和代码审查，可以避免大部分的内存泄漏问题。