phpinfo()中的memory_limit仅表示单脚本内存上限，不反映服务器真实可用内存；需结合free -h、/proc/meminfo及memory_get_peak_usage()交叉验证。
phpinfo() 显示的 memory_limit 不等于服务器真实可用内存
很多人看到探针页面里 memory_limit 是 256M 就以为“够用了”，其实这是单个 PHP 脚本能申请的最大内存上限，和服务器总内存、PHP-FPM 进程数、系统缓存、其他服务（如 MySQL、Nginx）争抢完全无关。探针本身不显示 /proc/meminfo 或 free -h 的真实内存状态，它只反映 PHP 层面的配置限制。
- 若探针中
memory_limit显示为-1（无限制），不代表安全——可能只是被禁用检测或配置未生效，需结合php -i | grep memory_limit命令验证 CLI 环境 - 虚拟主机用户常看到
128M或256M，但实际服务器总内存可能仅 1G，开 5 个 PHP-FPM worker 就可能 OOM（Out of Memory） - 某些面板（如 DirectAdmin）会屏蔽
shell_exec、exec等函数，导致探针无法读取/proc/meminfo，此时显示的“内存”字段为空或为 0
探针能否显示真实内存使用？看它是否调用系统接口
标准 phpinfo() 不提供运行时内存占用；而高级探针（如 B-Check 或自定义版）若包含 sys_linux() 和 /proc/meminfo 解析逻辑，才可能显示 MemTotal、MemAvailable 等值。但这依赖两个前提：PHP 进程有读取权限，且未启用 open_basedir 限制。
- 常见失败现象：探针页面中“内存”区块空白、显示
N/A或报错Warning: file(): open_basedir restriction in effect - 检查方法：在探针同目录新建
test_mem.php
，通过浏览器访问测试
- Linux 下真正可靠的内存水位，必须看
MemAvailable（非MemFree），后者不含可回收缓存，会严重低估可用量
判断内存是否“充足”的实操三步法
不能只信探针数字，要交叉验证脚本行为、日志线索与系统指标。
-
查错误日志：出现
Fatal error: Allowed memory size of XXX bytes exhausted是最直接信号；注意不是所有溢出都报错——有些被php-fpm杀掉后只留WARNING: [pool www] child 12345 exited on signal Segmentation fault (11) -
测脚本峰值：在关键脚本开头加
memory_get_usage()，结尾加memory_get_peak_usage()，例如，对比
memory_limit留出至少 30% 缓冲 -
看系统负载：SSH 登录后执行
free -h和cat /proc/sys/vm/swappiness；若Available长期低于 100MB，且swappiness > 10，说明内存已吃紧，开始频繁交换
为什么改大 memory_limit 反而更危险？
盲目把 memory_limit 从 128M 改成 1024M，可能掩盖真实瓶颈，甚至引发雪崩。PHP 脚本内存暴增往往源于循环引用、未释放的大数组、或 GD 图像处理未 imagedestroy()。
立即学习“PHP免费学习笔记（深入）”；
- 一个
imagecreatefromjpeg()加载 5MB JPG，在 GD 处理时可能瞬时占用 50MB+ 内存；若循环处理 10 张且不销毁，就爆了 - 数据库查询未设
limit，fetchAll()一次性加载上万行，内存直接拉满 - 某些探针自身就存在内存泄漏（尤其带实时网卡/CPU 采样的版本），长期运行反而成为压垮内存的元凶
真正要盯的不是探针里那个静态数字，而是你的脚本在真实流量下的 memory_get_peak_usage() 曲线，以及系统 free -h 中 Available 的持续变化——这两者对不上，光调 memory_limit 就是掩耳盗铃。