各位下午好，我是你们的资深 PHP 专家。今天我们不聊那些花里胡哨的语法糖，也不聊怎么把代码写得像诗一样美。今天我们聊点硬核的，聊点“救命”的。
如果你的生产环境里跑了 PHP，而且是在容器化环境里跑，尤其是涉及“海量采集任务”，那你绝对该坐下来听听这场讲座。
为什么？因为你们的服务器正在经历一场一场的“物理宕机”，而罪魁祸首通常只有一个——OOM (Out of Memory)。
很多人觉得容器不就是沙盒吗？把内存限制一下不就行了？天真。在 Linux 内核眼里，容器里的进程和宿主机上的进程唯一的区别就是它挂了个名字。当内存不够时，Linux 会启动 OOM Killer。这个家伙是个暴脾气，它不管你是什么服务，只管杀鸡儆猴，谁占内存多，谁就死。而 PHP 脚本这种东西，一旦掉进内存黑洞，那是真的一去不回，吃干抹净，最后连个渣都不剩，然后宿主机在一片哀嚎中优雅地重启。
别慌，今天我们就来手把手教你怎么用容器化和 PHP 的配置，给这个暴脾气的 OOM Killer 戴上项圈。
第一课：容器化环境的“水泥墙”与“铁丝网”
首先，我们要明确一个概念：容器不是虚拟机。容器共享宿主机的内核。这意味着，容器内部的内存限制，本质上是操作系统层面的 cgroups (Control Groups)。
想象一下，你的宿主机有 64G 内存，你启动了 100 个 PHP 容器。如果你不限制，这 100 个 PHP 脚本就会像一群饿狼冲进自助餐厅，每一只都想独吞所有的肉。最后，内存被吃光了，操作系统内存不足，开始疯狂交换内存到磁盘，此时你的服务器开始变卡，然后——轰，OOM Killer 被唤醒了。
第一步：硬限制，给 Docker 画个圈
这是最基础，也最有效的手段。你必须在启动容器的时候，明确告诉 Docker：“嘿，给我省着点花，最大就给你这么多。”
在 Docker CLI 中，我们用 --memory 参数。
docker run -d --name php-worker
--memory="2g"
--memory-swap="2g"
php:7.4-cli /app/collector.php这里有两个参数，很多人只懂第一个，导致踩坑。
--memory="2g"：这是容器的硬上限。这意味着容器内所有进程加起来的物理内存占用不能超过 2G。--memory-swap="2g"：这是关键！很多人以为设置这个等于“限制 Swap”，其实它说的是“物理内存 + Swap 的总和上限”。
专家提示： 如果你只想限制物理内存，而不想让它使用 Swap（因为 Swap 是慢速硬盘，性能极差，且容易被 OOM 杀死），你需要这样设置：
--memory="2g" --memory-swap="0"。这会强制容器在达到 2G 物理内存时直接报错或退出，而不是跑去蹭 Swap。
如果你用了 Kubernetes，这个配置就写在 Deployment 的 resources.limits 里：
apiVersion: apps/v1
kind: Deployment
metadata:
name: php-scraper
spec:
template:
spec:
containers:
- name: php-app
image: php:7.4-cli
resources:
limits:
memory: "2Gi" # 限制最大内存
cpu: "1000m" # 顺便限制一下 CPU，防止饿死
requests:
memory: "512Mi" # 保证至少给这么多，别因为超卖把我饿死看到没？有了这个 limits，即使你的 PHP 脚本是个无底洞，容器也会在 2G 的时候停下来。但是！ 停下来之后呢？如果容器崩溃了，K8s 会尝试重启它。结果就是，你的日志里全是 Fatal error: Allowed memory size of X bytes exhausted，而宿主机上的 OOM Killer 正在深夜里冷冷地看着你。
第二课：PHP 内核的“餐盘大小”
既然 Docker 已经给了我们一个“碗”，那我们 PHP 代码自己是不是也得有个“胃口限制”？答案是有，而且非常重要。
PHP 有一个核心配置 memory_limit。这是 PHP 解释器在执行脚本时，能申请到的最大连续内存块。如果超过了这个值，PHP 会直接抛出 Fatal Error。
常见误区：
很多高级开发（包括以前的我）喜欢把 memory_limit 设为 -1，意思是“不要限制”。这种做法在 CLI 脚本里没问题，但在容器化环境里，这就是在自杀。
调优策略：
- 不要盲目使用
-1：在容器里，请务必设置一个具体的值。比如memory_limit = 512M。 - 根据任务类型动态调整：如果你的脚本是个内存计算器，设大点；如果你的脚本是爬虫，设小点。
代码示例：动态调整内存限制
<?php
// 在脚本最开始，根据输入参数动态决定需要多少内存
$input = $argv[1] ?? 0;
// 假设我们需要处理 1000 万条数据，预估每个数组元素占 50 字节
$estimatedSize = 10000000 * 50;
// 动态调整 PHP 的内存限制
$memoryLimit = $estimatedSize / (1024 * 1024); // 转换成 MB
ini_set('memory_limit', $memoryLimit . 'M');
echo "Memory limit adjusted to " . ini_get('memory_limit') . PHP_EOL;
// 现在你可以尽情使用了
$bigArray = [];
for ($i = 0; $i < 10000000; $i++) {
$bigArray[] = "Data-" . $i;
// 手动释放不再需要的内存
if ($i % 1000000 === 0) {
unset($bigArray);
$bigArray = [];
}
}专家提示： PHP 的 memory_limit 是针对整个脚本的。如果你的脚本里调用了外部库（比如 GuzzleHttp, Swoole, Monolog），这些库在初始化时可能会申请一些内存（比如连接池、缓冲区）。所以，你设定的 memory_limit 实际上必须大于库初始化所需的内存。
第三课：PHP 对象模型的“幽灵引用”
这是最让人头疼的地方，也是导致 OOM 的元凶。PHP 使用的是引用计数机制来管理内存。简单说，一个变量消失，内存就释放。
但是，“引用”这个词有歧义。
在 PHP 中，赋值操作（=）默认是“复制”。但当你把一个大对象赋值给一个变量时，这个变量只是指向了对象在堆上的地址（指针）。
场景模拟：
function processItem($data) {
// 这里是按值传递，但实际上 PHP 7+ 对大数组会做 Copy-on-Write (COW) 优化
// 看起来像是复制了
$processed = $data;
// 处理数据...
$processed['timestamp'] = time();
return $processed;
}
// 主循环
$sourceData = loadHugeData(); // 假设占 500MB
$iterations = 1000;
for ($i = 0; $i < $iterations; $i++) {
// 每次调用 processItem，PHP 都会尝试复制 $sourceData 的一份副本
// 虽然 COW 优化在初始写入时才复制，但在高并发或频繁调用下，
// 堆上的内存占用会呈指数级增长。
$result = processItem($sourceData);
// 哪怕你这里 unset 了 $result，如果 $sourceData 还没被销毁，内存压力依然存在
unset($result);
saveToDatabase($result);
unset($result);
}在这个循环里，每迭代一次，PHP 就会试图给堆内存分配空间来存储新的 $processed 数组。如果 processItem 函数里还持有 $data 的引用（比如把它传给另一个需要引用的库函数），那么内存永远不会释放。
应对策略：
- 及时
unset：这不仅是好习惯，是救命稻草。在while循环里，处理完一条数据，立即unset相关变量。 - 使用引用传递：如果不需要修改原数据，直接用
&引用传参。function processItem(&$data) { ... } - 利用弱引用：如果你是用 Swoole 或 Workerman 这种 PHP 进程模型，需要缓存数据，但不想占用内存，了解一下 WeakRef 扩展。
第四课：海量采集任务的“异步化”与“分片”
如果任务真的海量到“2G 内存根本不够用”，那说明你的架构思路需要调整了。单纯靠增加内存来堆砌资源是下策，我们要靠流程。
策略 A：分而治之
不要让一个脚本处理 1 亿条数据。让 10 个脚本，每个处理 1 亿条数据，但是限制每个脚本的内存。
# 启动 5 个采集任务，每个任务只抓取 1/5 的 URL
for i in {1..5}; do
docker run -d --name scraper-$i
--memory="1g"
php:7.4-cli /app/scrape.php --start $(( ($i-1) * 20000000 )) --end $(( $i * 20000000 ))
done这样，就算其中 2 个脚本崩了，剩下的 3 个还能坚持，宿主机也不会因为 OOM 而死机。K8s 的 replicas 就在这里发挥作用。
策略 B：流式处理
不要把所有数据都加载到 $data 数组里。用数据库游标，用文件流，用 Redis 列表。
终极代码示例：流式采集与内存限制
<?php
// 连接数据库
$pdo = new PDO('mysql:host=host;dbname=db', 'user', 'pass');
$stmt = $pdo->query("SELECT id, content FROM huge_table");
// 开启 fetch mode 模式，而不是 fetchAll
// 这样 PHP 每次只取一行，处理完一行，立即释放内存
$stmt->setFetchMode(PDO::FETCH_ASSOC);
$counter = 0;
// 设置 PHP 内存限制为 128M，看看能不能撑过 100 万行
ini_set('memory_limit', '128M');
while ($row = $stmt->fetch()) {
$counter++;
// 处理当前行
$result = heavyProcessing($row['content']);
// 存入 Redis 或数据库
$redis->lpush('queue', $result);
// 显式清理，虽然 PHP GC 会自动回收，但手动 unset 能让你心里更有数
unset($row, $result);
// 进度监控
if ($counter % 10000 === 0) {
echo "Processed $counter rows. Memory: " . memory_get_usage(true) / 1024 / 1024 . "Mn";
}
}
echo "All done!";这种写法，无论你的表有几亿条数据，只要你的 PHP 进程内存限制设置得比 PDO 的缓冲区大，它就死不了。这就是流式处理的艺术。
第五课：Swap 的“甜蜜陷阱”与监控
很多运维为了防止容器因为内存不足直接被 KILL，会开启宿主机的 Swap，或者设置容器的 Swap 上限。这听起来很安全，实际上是个定时炸弹。
当物理内存耗尽，Linux 会开始把内存页换到硬盘上。对于 PHP 这种 CPU 密集型或高内存型脚本，Swap 的存在会导致它疯狂 I/O 等待，CPU 占用率虽然高，但都在等待内存换入换出。
此时，如果你没有监控到 Swap 的激增，服务器可能看起来还很“活着”，实际上已经卡死，响应时间从 50ms 变成了 50000ms。
监控方案：
你不能只看 free -m。你要看 OOM Kill 的日志。
-
查看 OOM 日志：
# OOM Killer 通常会记录在 /var/log/messages 或 kern.log 里 grep -i "Out of memory" /var/log/messages # 或者 dmesg | grep -i "killed process" -
容器内的内存监控：
在容器里安装stress-ng或者写个脚本定期打印内存使用情况。// 容器内每 5 秒打印一次内存 // 放在 while(true) 循环里 file_put_contents('/tmp/memory.log', date('Y-m-d H:i:s') . " " . memory_get_usage(true) . "n", FILE_APPEND );
专家提示： 如果你的 PHP 采集任务极其耗时且高内存，绝对不要开启 Swap。直接限制物理内存，让它在达到上限时优雅退出（通过 register_shutdown_function 保存进度），比让它卡在 Swap 里等死要好上一万倍。
第六课：优雅降级与重启策略
假设你做到了以上所有：Docker 限制了 2G，PHP 设置了 512M，代码里用流式处理。但是，有个极个别的数据包特别大（比如一张 10MB 的图片 Base64 编码塞进数组里），还是把内存撑爆了。
这时，PHP 会报 Fatal Error，脚本结束，容器退出，K8s 重启。这很正常。
问题在于，你有没有保存进度？
很多采集脚本是从第 100 万条开始的，崩了之后，下次启动又从 100 万条开始，重复刚才的错误。这就是“掉轮子”。
解决方案：断点续传
<?php
$progressFile = '/tmp/progress.txt';
$lastId = file_exists($progressFile) ? (int)file_get_contents($progressFile) : 0;
$stmt = $pdo->query("SELECT * FROM table WHERE id > $lastId LIMIT 1000");
while ($row = $stmt->fetch()) {
// ... 处理逻辑 ...
// 处理成功，更新进度
file_put_contents($progressFile, $row['id']);
// 如果内存快爆了（虽然设置了限制，但为了保险），主动退出
if (memory_get_usage(true) > (1024 * 1024 * 1024)) { // 超过 1G
echo "Memory pressure detected, saving progress and exiting.n";
break;
}
}
// 退出码处理
if ($row) {
exit(137); // 137 是 OOM Kill 的标准退出码，告诉 K8s "我是非正常退出，重启我"
}配合 Kubernetes 的 restartPolicy（通常为 OnFailure），当容器因为内存错误退出时，K8s 会知道这是“失败”状态，从而尝试重启。只要我们有进度文件，重启就能接着干，而不是从头再来。
终极奥义：Swoole/Workerman 的多进程内存模型
如果你真的要在 PHP 里跑“海量采集”，用普通的 php cli 脚本已经是古董了。现在都流行用 Swoole 或 Workerman。
这些扩展允许你启动多个子进程。每个子进程都有自己独立的内存空间。
为什么这很重要？
假设你的宿主机有 4G 内存，你开启了 4 个 Swoole 进程。每个进程限制 500M。总内存消耗 2G。这很健康。
但是，如果其中一个进程因为写死循环导致 OOM 被杀掉，另外 3 个进程不受影响。宿主机的总内存占用会下降，而不是像单进程脚本那样从 2G 直接飙升到 4G 然后把宿主机撑爆。
Swoole 中的内存管理：
// Swoole 进程主控代码
$server = new SwooleProcessPool(4); // 4个进程
$server->on('workerStart', function ($pool, $workerId) {
// 给每个进程分配不同的任务范围
// 进程 0: 0-1000, 进程 1: 1001-2000 ...
ini_set('memory_limit', '512M'); // 单进程限制
});
$server->on('workerMessage', function ($pool, $data) {
// 处理消息
// 在这里处理数据时，务必小心，不要产生内存泄漏
// Swoole 的 Server 类本身会占用一些内存，分配内存给 task data 时要快进快出
});
$server->start();使用多进程模型，实际上是将“内存风险”从“单点”分散到了“多点”。虽然增加了开发的复杂性，但对于“海量采集”这种场景，它是唯一能稳定运行的方案。
总结（不，这不是总结，这是经验之谈）
各位，防止宿主机 OOM 没有什么银弹。
如果你还在用 php script.php 这种单进程脚本跑几百万条数据，请立刻停止，去看看 Swoole，或者至少把内存限制设小一点，多开几个实例跑。
如果你已经在用 Docker/K8s，请务必检查你的 limits 配置。记住 --memory-swap="0" 的奥义。
如果你在写 PHP 代码，请记住 memory_limit 不是摆设，unset 是好习惯，流式处理是王道。
记住，我们不是要让 PHP 进程跑得飞快，我们是要让它活得久。在资源受限的容器环境里，活得久就是最大的胜利。
好了，今天的讲座就到这里。去检查你们的采集任务吧，别让 OOM Killer 晚上来找你麻烦。