무엇을 바로잡을까

heap과 RSS 지속 증가에서 바꿀 결과와 유지할 기존 동작을 한 문장씩 적습니다. V8 heap은 RSS의 일부일 뿐이며 Buffer·native addon·thread stack도 RSS에 포함되므로 heapUsed와 external·arrayBuffers를 분리해야 합니다.

수정 전에 확인할 것

메모리 문제는 한 시점의 사용률이 아니라 시간에 따른 할당률, 작업 종료 뒤 기준선과 참조 경로를 봐야 합니다. heap과 native·buffer·파일 캐시를 분리하면 제한을 늘려야 하는지, 참조를 끊어야 하는지가 달라집니다. 현재 version의 공식 문서와 실제 설정을 확인하고 대표·경계·실패 사례를 준비합니다. event loop delay/utilization, CPU profile, heap/RSS, active handle, GC와 dependency latency를 함께 본다.

순서 할 일
1 수정 전 결과와 되돌릴 기준 저장
2 핵심 사실과 맞닿은 한 곳만 변경
3 같은 입력으로 수정 전후 비교

작게 고치고 검증하기

반복 횟수, 컬렉션, queue와 cache에 상한을 두고 상태를 만든 소유자가 listener·timer·handle까지 정리하게 합니다. 메모리 제한 상향은 원인 수정 뒤의 안전 여유로만 사용합니다. CPU 작업과 I/O를 구분하고 queue, timeout, body, 동시성에 제한을 둔 뒤 정상 종료를 구현한다. 예상과 다르면 변경을 더 얹지 말고 처음 달라진 값으로 돌아갑니다. 부하 테스트에서 처리량, p99, event loop delay, heap 기준선, 열린 handle과 종료 시간을 검증한다. 동일 부하를 충분히 오래 유지한 뒤 GC 이후 live set과 RSS 기준선, allocation rate, 처리량과 pause가 함께 안정되는지 확인합니다.

공식 문서와 적용 범위

문서의 기본값과 동작은 version에 따라 달라질 수 있습니다. 현재 runtime·framework version, 실제 입력과 요청 흐름에서 다시 확인합니다.