编译 Nginx 时进程被杀通常由 OOM Killer 触发，因 gcc/make 内存超限；应先执行 dmesg -T | grep -i "killed process" 确认，再通过禁用并行编译、关闭调试符号、增大 swap 等方式缓解。
编译 Nginx 源码时进程被杀（如 gcc 或 make 突然退出），通常不是 Nginx 本身的问题，而是系统在编译过程中触发了 OOM Killer —— 编译器（尤其是启用调试符号或高优化等级时）会大量申请内存，导致系统资源耗尽。
确认是否被 OOM Killer 终止
编译中断后，立即执行：
-
dmesg -T | grep -i "killed process"—— 查看内核日志中是否有类似Out of memory: Kill process 12345 (cc1) or sacrifice child的记录 -
journalctl -b --since "1 hour ago" | grep -i "oom\|killed"—— 补充系统级日志线索 - 若看到
cc1、cc1plus、ld或make被 kill，基本可锁定为内存不足
降低编译内存压力的实操方法
无需升级硬件，优先调整编译行为：
- 禁用并行编译：
make -j1（默认-j$(nproc)会同时启动数十个 gcc 实例，每个占用 500MB–1.5GB 内存） - 关闭调试符号生成（除非必须）：
./configure --without-debug ...；若需调试，至少避免--with-debug+-O2同时启用 - 限制 GCC 堆内存使用：
export GCC_COLORS=never; export MAKEFLAGS="-j1"，再运行make - 临时增大 swap（仅应急）：
sudo fallocate -l 2G /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile
检查编译环境资源瓶颈
编译前快速验证基础条件：
-
free -h—— 确保可用内存 ≥ 2GB（推荐 ≥ 4GB）；swap 不为 0 更稳妥 -
ulimit -v—— 检查虚拟内存限制（soft limit），若为有限值（如 2097152 KB ≈ 2GB），执行ulimit -v unlimited临时解除 -
df -h /tmp—— GCC 默认用/tmp存放中间文件，确保剩余空间 ≥ 3GB（尤其启用--with-cc-opt="-g"时）
规避高内存配置组合
以下配置显著增加编译内存需求，应谨慎搭配：
-
--with-debug+--with-http_ssl_module+--with-http_v2_module—— 三者叠加会使目标文件体积翻倍，链接阶段内存峰值常超 3GB -
./configure --with-cc-opt="-O3 -march=native"——-O3在大型模块（如 OpenSSL）上极易引发 GCC 内存爆炸 - 在容器或 CI 环境中未限制 cgroup memory —— 即使宿主机内存充足，容器内仍可能因 memlimit 触发 OOM
不复杂但容易忽略：编译失败时先看 dmesg，而不是反复改 configure 参数。
