AWS EC2实例上Node.js应用内存耗尽问题排查求助（日志被抑制无法定位根因）

遇到这种内存耗尽还抓不到关键日志的情况确实挺闹心的！结合我之前排查类似问题的实战经验，给你几个可行的方向，应该能帮你定位到根因：

• 给Node.js进程加崩溃前的内存快照
  启动Node.js应用时加上--heap-dump-on-exit参数，这样进程被OOM Killer杀死时会自动生成堆快照文件。另外可以搭配--trace-gc参数跟踪垃圾回收的详细日志，帮你判断是内存泄漏还是GC跟不上内存增长。注意要把快照文件的存储目录提前配置到有足够空间的挂载点（比如EBS卷），避免因为本地磁盘满或者内存不足导致快照写失败。如果需要更实时的监控，推荐用clinic heap-profiler工具，它能可视化展示内存变化，还能手动触发快照。

• 绕过本地系统日志限制，用独立日志方案
  既然本地系统日志在OOM时会被抑制，那就绕开它。可以用Node.js的第三方日志库（比如winston）直接把关键日志异步写入S3，或者配置rsyslog把应用日志转发到另一个空闲的EC2实例。这样即使本地系统资源耗尽，远程也能收到崩溃前的日志信息。

• 系统层面的监控与诊断

  • 先查dmesg日志！OOM Killer触发时，系统内核会把相关信息写入内核缓冲区，即使用户态日志被抑制，dmesg | grep -i oom大概率能找到哪条进程被杀死、当时的内存状态等关键信息。
  • 开启swap分区（临时应急方案）：给EC2实例加个swap分区，虽然不能解决内存泄漏，但能延缓进程被杀死的时间，给日志收集或快照生成争取几秒时间。命令很简单：sudo fallocate -l 4G /swapfile && sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile。
  • 用监控工具提前预警：配置node_exporter + Prometheus实时采集进程的RSS内存、VMSize、GC状态等指标，设置内存使用率超过80%的告警，在OOM触发前手动登录实例执行pmap -x <node_pid>查看内存分布，或者用node --inspect连接进程手动触发堆快照。

• 代码层面的内存泄漏排查
  检查代码里有没有常见的内存泄漏点：比如未清除的定时器/Interval、未移除的事件监听器、大对象缓存没有设置过期时间、闭包引用导致的内存无法释放等。可以在代码里加入周期性的内存检查逻辑，比如每隔5分钟用process.memoryUsage()打印内存状态，写到独立的日志文件里，这样能看到内存增长的趋势，缩小排查范围。另外用Node.js内置的async_hooks模块可以跟踪异步资源的创建和销毁，帮你找到未释放的异步资源。

• 调整OOM Killer的行为（谨慎操作）
  可以修改Node.js进程的oom_score_adj值，让系统在内存不足时优先杀死其他低优先级进程，给Node.js进程多留一点时间。命令：echo -1000 | sudo tee /proc/<node_pid>/oom_score_adj，数值越低，越不容易被OOM Killer选中。不过这个要谨慎，避免系统因为内存耗尽而挂掉。

这些方法应该能帮你逐步缩小范围，找到内存耗尽的根本原因。可以先从查dmesg日志和加堆快照开始，这两个方法见效最快！

备注：内容来源于stack exchange，提问作者treskilion