GitHub自托管Runner中Node.js堆内存溢出问题求助

错误码134通常意味着进程收到SIGABRT信号终止，结合你提供的Scavenge日志，说明Node.js在新生代垃圾回收时出现内存分配失败，且调大--max-old-space-size无效，可从以下几个方向排查解决：

• 检查Runner实际可用内存
  用free -h或htop在Runner节点上查看实时内存占用，确认物理内存/swap是否充足。你设置的--max-old-space-size不能超过系统实际可分配内存，否则会触发系统OOM killer直接终止进程（表现为错误码134）。如果物理内存不足，可：

  • 升级Runner的硬件配置
  • 临时启用swap分区：

    fallocate -l 16G /swapfile
    chmod 600 /swapfile
    mkswap /swapfile
    swapon /swapfile
    

• 排查内存泄漏
  调大内存只是治标，内存泄漏会最终撑爆所有分配的内存。可通过以下方式定位：

  • 在启动命令中加入--expose-gc，在代码中定期调用global.gc()并打印process.memoryUsage()，跟踪内存增长趋势
  • 使用clinic heap-profiler生成堆快照，分析哪些对象持续占用内存未释放
  • 重点检查未清理的定时器、事件监听器、闭包，或第三方依赖的内存泄漏问题

• 调整垃圾回收策略
  仅调大老年代内存上限不够，可尝试优化GC参数：

  • 启用增量标记GC，减少GC暂停时间：

    NODE_OPTIONS="--max-old-space-size=8192 --incremental-marking"
    

  • 调整新生代内存大小，降低Scavenge触发频率（默认64MB，可根据任务调整）：

    NODE_OPTIONS="--max-old-space-size=8192 --max-semi-space-size=512"
    

• 拆分大任务
  如果任务是批量处理（如构建、数据同步），将大任务拆分为多个小批次执行，每批次完成后主动释放内存（如清空变量、解除引用），避免一次性加载过多数据到内存。

• 检查Node.js版本兼容性
  部分Node.js版本存在GC相关的已知bug，尝试切换到LTS稳定版，或降级到之前能正常运行的版本，验证是否为版本问题导致的GC异常。

• 确认Runner资源限制
  检查Runner是否被cgroup等机制限制了内存使用，即使系统有充足内存，cgroup限制也会导致进程无法分配足够内存。查看限制：

  cat /sys/fs/cgroup/memory/memory.limit_in_bytes
  

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