Docker部署的Node.js应用因SIGSEGV信号频繁重启问题排查求助

看起来你的Node.js应用在Docker里运行24-26小时后就会触发SIGSEGV（段错误）导致重启，这个错误通常和内存访问异常有关，可能来自Node.js runtime本身、原生依赖包、内存资源限制或者容器配置问题。结合你提供的Dockerfile和docker-compose配置，我整理了一套排查和解决步骤：

1. 排查Node.js版本与镜像的兼容性问题 #

你当前使用的node:16-alpine3.13组合可能存在潜在坑点：

• Alpine镜像使用musl libc替代了常见的glibc，很多Node.js原生依赖（比如涉及底层系统调用的数据库驱动、图像处理库）在musl环境下编译可能不完整，运行一段时间后容易触发内存错误。
• Node.js 16虽为LTS版本，但较旧的小版本可能存在已修复的内存泄漏或段错误bug。

尝试方案：

• 切换到基于Debian的Node.js镜像，比如node:16-bullseye，glibc环境对原生依赖的兼容性更好，可先排除musl相关问题。
• 升级Node.js 16到最新小版本，比如node:16.20.2-bullseye，官方已修复不少内存相关旧bug。

2. 检查依赖包的原生模块问题 #

SIGSEGV常出现在使用原生C/C++模块的npm包中（比如sharp、bcrypt等）。你的应用挂载了本地代码目录到容器，但保留了容器内的node_modules匿名卷，这种配置可能引发：

• 本地开发环境的依赖是在非Alpine系统编译的，与容器环境不兼容，运行久了出现异常。
• 某个依赖包本身存在内存泄漏，持续占用内存后触发段错误。

尝试方案：

• 先移除docker-compose中${PWD}:/usr/src/app/的挂载，让容器完全使用构建时复制的代码和依赖，排除本地环境干扰，测试是否还会重启。
• 检查package.json中的依赖，尤其是带原生模块的包，尽量升级到最新稳定版，或替换为纯JavaScript实现的替代包。
• 运行npm audit检查依赖是否存在已知的内存相关漏洞。

3. 排查内存资源限制与泄漏问题 #

容器内存限制 #

Docker默认不设置内存限制，若宿主机内存不足，系统会触发OOM Killer杀死进程，有时会表现为SIGSEGV。你可以给Node.js容器添加内存限制并监控内存使用：
修改docker-compose.yml中node服务的配置：

node:
  # ... 原有其他配置
  deploy:
    resources:
      limits:
        memory: 512M
      reservations:
        memory: 256M

同时，给Node.js添加内存监控参数，修改Dockerfile的CMD：

CMD ["node", "--expose-gc", "--trace-gc", "app.js"]

或在package.json的start脚本中加入这些参数，日志中会显示垃圾回收情况，帮助判断是否存在内存泄漏。

内存泄漏排查 #

若应用运行时内存持续增长，大概率存在内存泄漏：

• 使用--inspect参数开启Node.js调试，在docker-compose的node服务中添加端口映射-p 9229:9229，通过Chrome DevTools连接容器，拍摄内存快照分析泄漏点。
• 使用clinic.js工具分析内存使用，可在容器内安装clinic后运行clinic heap-profiler -- node app.js生成分析报告，定位问题模块。

4. 启用Core Dump获取详细错误信息 #

要精准定位SIGSEGV的原因，可在容器中启用core dump，错误发生时会生成core文件用于后续分析：

修改Dockerfile添加core dump配置： #

FROM node:16-alpine3.13
WORKDIR /usr/src/app
# 开启core dump并指定存储路径
RUN ulimit -c unlimited && echo "/tmp/core.%e.%p" > /proc/sys/kernel/core_pattern
COPY package.json ./
RUN npm install
COPY . .
CMD ["npm", "start"]

然后在docker-compose的node服务中添加特权模式和tmp挂载：

node:
  # ... 原有其他配置
  privileged: true
  volumes:
    - ./core_dumps:/tmp

当应用触发SIGSEGV后，可在本地core_dumps目录找到core文件，用gdb分析：

docker run -v $(pwd)/core_dumps:/tmp --rm node:16-alpine3.13 gdb node /tmp/core.node.*

输入bt命令查看调用栈，即可定位触发错误的代码或模块。

5. 检查容器挂载的潜在问题 #

你当前的docker-compose中，node服务挂载了${PWD}:/usr/src/app/会覆盖容器内代码，同时保留/usr/src/app/node_modules匿名卷，这种配置可能导致：

• 代码热重载时出现资源竞争，触发内存错误。
• 本地配置文件或日志在容器中被频繁读写，引发异常。

建议先移除该挂载，让容器使用镜像内的内容测试。若必须挂载本地代码，需保证开发环境与容器环境的依赖完全一致，比如用npm ci替代npm install安装依赖，确保依赖版本完全匹配。

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