proc_open() 报“fork failed on memory allocation”是因 Linux 内核按 vm.overcommit_memory=2 策略拒绝 fork，根本原因是 CommitLimit

为什么 proc_open() 会报 “fork failed on memory allocation”？

这不是 Composer 自身的问题，而是 Linux 内核拒绝了 fork() 系统调用——因为当前进程尝试 fork 子进程时，内核判断“如果允许这次 fork，后续可能没内存完成实际执行”，于是直接拦下。根本原因在内核的 vm.overcommit_memory 策略和可用虚拟内存（尤其 vm.overcommit_ratio 或 vm.overcommit_kbytes 配置）。

如何快速验证是 overcommit 导致的？

运行 cat /proc/sys/vm/overcommit_memory 和 cat /proc/sys/vm/overcommit_ratio，再配合 free -h 看可用内存。如果 overcommit_memory == 2（严格模式），且 MemAvailable 明显低于 CommitLimit（可从 /proc/meminfo 查），那基本就是它。

• overcommit_memory == 0：启发式检查（默认，但不可靠）
• overcommit_memory == 1：总是允许 fork（最宽松，适合 Composer 场景）
• overcommit_memory == 2：按 overcommit_ratio 严格计算上限（最容易触发该错误）

临时修复：改 vm.overcommit_memory 并重试 Composer

不用重启，立即生效：

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

sudo sysctl vm.overcommit_memory=1

然后立刻跑 composer install 或 composer update。多数情况下错误消失。注意：这只是会话级临时生效，重启后还原。

• 若需永久生效，写入 /etc/sysctl.conf：添加 vm.overcommit_memory = 1
• 不要盲目调高 overcommit_ratio——它只对 overcommit_memory == 2 有效，而 Composer 更需要的是允许 fork 的确定性
• 某些容器环境（如 Docker）需在 docker run 时加 --sysctl vm.overcommit_memory=1，宿主机设置无效

为什么不能只靠加 swap 或扩物理内存？

Swap 不解决这个问题。fork() 失败发生在复制页表阶段，不涉及实际内存分配或 swap I/O；内核只看“理论最大提交量”是否超限。即使空闲内存充足，只要 CommitLimit 被算死（比如 overcommit_ratio=50 且物理内存小），依然会拒 fork。

• 典型表现：free -h 显示还有 2GB 可用，但 cat /proc/meminfo | grep Commit 显示 CommitLimit: 1.2 GB
• Composer 启动大量子进程（如 git、unzip、php 解析器），每个 proc_open() 都触发一次 fork()
• 云服务器小内存实例（如 1GB RAM）配默认 overcommit_memory=2 是高危组合

真正卡住人的不是命令怎么敲，而是看到 fork failed 还去查 Composer 日志、怀疑 PHP 配置、甚至重装扩展——其实内核早把门焊死了，得先开锁。