Cron执行的PHP脚本占用512MB后崩溃，已设更高内存仍无解

咱们一步步拆解这个问题，从最容易被忽略的细节开始排查：

1. Cron使用的PHP配置和网页环境不一致 #

很多服务器会区分**CLI模式（Cron调用的）**和网页模式（Apache/PHP-FPM）的php.ini文件，你在网页环境中看到的memory_limit=8192M，很可能和Cron加载的配置完全不是一回事。

验证操作：

• 在你的脚本开头（ini_set代码之后）添加一行：

  phpinfo();
  exit;
  

• 修改Cron命令，把输出重定向到一个文件：

  * * * * * php /path/to/your/script.php > /tmp/cron_phpinfo.txt 2>&1
  

• 等待Cron执行完成后，打开/tmp/cron_phpinfo.txt搜索memory_limit，如果实际生效的值是512MB，那就是CLI版的php.ini没配置对。

2. 系统层面的用户内存限制（ulimit） #

除了PHP自身的memory_limit，系统用户的ulimit设置也可能限制进程能使用的最大内存。如果Cron是以某个特定用户执行的，这个用户的max memory size可能被设成了512MB。

验证操作：

• 切换到Cron执行的用户（比如su - cron_exec_user），然后执行：

  ulimit -a
  

• 查看max memory size这一项，如果数值是524288（单位KB，对应512MB），那就是系统层面限制了进程内存，需要调整该用户的ulimit配置。

3. 脚本存在内存泄漏或内存占用远超预期 #

有时候不是配置的问题，是脚本本身的内存使用失控了——比如循环加载大量数据不释放、大文件读取没做分段处理，可能你以为内存用不到8G，但实际已经快速涨到了上限。

排查操作：

• 在脚本的关键节点（比如循环开始/结束、大操作前后）添加内存监控代码：

  echo "当前真实分配内存：" . memory_get_usage(true) . " bytes\n";
  

• 把Cron的输出重定向到日志文件：

  * * * * * php /path/to/your/script.php > /tmp/script_memory_log.txt 2>&1
  

• 崩溃后查看日志，看内存是从哪一步开始暴涨的，定位到具体代码块优化。

4. ini_set被后续代码覆盖 #

你在脚本开头设置的memory_limit，可能被后面引入的文件、框架配置或者其他代码给覆盖了。

验证操作：

• 在脚本崩溃前的位置（比如你预计会占用大量内存的代码之前）添加：

  echo "当前生效的memory_limit：" . ini_get('memory_limit') . "\n";
  

• 如果输出不是8191M，那说明有其他代码修改了这个配置，得去排查后续的代码逻辑。

5. PHP版本或扩展的bug #

某些旧版本的PHP或者特定扩展可能存在内存限制的bug，比如忽略memory_limit设置，或者在处理特定操作时触发内存溢出。

尝试方案：

• 暂时禁用非必要的PHP扩展，重新运行脚本看是否还崩溃；
• 如果你的PHP版本比较旧（比如低于7.4），可以尝试升级到稳定的新版本。

内容的提问来源于stack exchange，提问作者M2Newbie