Node.js 메모리 누수 디버깅 — Heap Snapshot보다 먼저 봐야 할 신호

메모리 누수는 보통 프로세스가 안 죽는데 점점 무거워진다는 형태로 먼저 온다. 직접 겪어보면 Heap Snapshot부터 뜨는 건 꽤 늦다. 저는 오히려 세 가지 신호를 먼저 본다. GC 직후에도 내려오지 않는 old space, 요청량이 그대로인데 계속 우상향하는 RSS, 그리고 배포 직후엔 멀쩡하다가 하루 지나면 응답 시간이 같이 무거워지는 패턴이다. 이 세 개가 같이 움직이면 거의 누수 쪽이다.

## 1. 숫자부터 제대로 본다

흔히 착각하는 게 있다. heapUsed만 보면 다 보인다고 생각하는 거다. 실제 운영에선 rss, heapUsed, external, arrayBuffers를 같이 봐야 한다. Buffer를 많이 쓰는 서비스는 V8 heap보다 외부 메모리에서 먼저 터진다. 이미지 리사이즈, 파일 업로드, 대용량 JSON 직렬화가 섞이면 그래프가 예쁘게 안 나온다. 그래서 저는 1분 평균보다 GC 직후 최저점이 어제보다 높아졌는가를 본다. 이게 제일 빨리 이상 신호를 준다.

## 2. 원인은 생각보다 단순하다

원인도 생각보다 뻔하다. 요청 스코프에 있어야 할 객체가 전역 Map에 남아 있거나, 캐시 만료가 없어 키만 계속 늘어나거나, setInterval 안에서 클로저가 큰 객체를 붙잡고 있거나, 이벤트 리스너를 요청마다 다시 등록하는 식이다. 한 번은 WebSocket 세션 상태를 편하다는 이유로 프로세스 메모리에 쌓아뒀다가, 접속 해제 후 정리가 늦어져서 old space가 계속 커졌다. Heap Snapshot을 떠보니 이미 늦었다. 그래프만 봐도 답이 나오는 상황이었다.

## 3. 순서를 거꾸로 잡지 않는다

그래서 순서는 늘 같다. 첫째, 메모리 지표를 분리해서 본다. 둘째, 누수가 의심되는 시점의 request path를 묶어본다. 셋째, 그다음에야 snapshot이나 allocation profiling으로 들어간다. 순서를 거꾸로 하면 원인 후보가 너무 많아진다. 실무에서 보면 대부분 이 지점에서 막힌다. 도구가 부족해서가 아니라, 신호를 먼저 못 읽어서다.

마지막으로 하나만 더. 누수는 메모리가 늘어난다보다 원래 내려와야 할 선이 안 내려온다로 보는 게 맞다. 직접 써봤다. 그리고 이게 핵심이다. Snapshot은 증거고, 운영 지표는 예고편이다. 예고편을 먼저 읽을 수 있어야 디버깅 시간이 짧아진다.

Node.js 메모리 누수 디버깅 — Heap Snapshot보다 먼저 봐야 할 신호

// COMMENTS

ON THIS PAGE