객체를 해제해 힙 사용량은 줄었는데 프로세스의 RSS는 그대로입니다. 누수인지 재사용 공간인지 어떻게 구분하나요?

힙에서 객체를 해제했다는 사실과 운영체제가 그 페이지를 즉시 회수했다는 사실은 다릅니다. RSS는 현재 물리 메모리에 상주하는 프로세스 매핑의 크기이므로 관리 힙만이 아니라 스레드 스택, native allocation, 공유 라이브러리, 파일 매핑 등을 포함할 수 있습니다. 할당자는 다음 요청을 빠르게 처리하려고 arena와 free block을 보유할 수 있고, 큰 객체를 해제해도 같은 페이지에 작은 생존 객체가 남아 있으면 페이지 전체를 반환하지 못합니다. 따라서 RSS가 그대로라는 관찰만으로 누수라고 말하지 않겠습니다.

세 숫자의 의미를 분리합니다

살아 있는 객체량은 애플리케이션이 참조를 유지하는지를, allocator retained bytes는 할당자가 프로세스 안에 보유한 재사용 공간을, RSS는 실제 물리 상주 매핑을 보여 줍니다. PSS는 공유 페이지 비용을 여러 프로세스에 나누어 계산하므로 컨테이너나 프로세스별 실제 부담을 비교할 때 유용하지만, RSS와 같은 숫자는 아닙니다. 파일 매핑이 줄지 않거나 스레드 수가 늘어도 RSS가 유지될 수 있습니다. 반대로 객체 그래프와 native allocation이 반복 부하마다 함께 증가하면 allocator가 단순히 공간을 보유한 것보다 참조·자원 누수를 의심해야 합니다. 이 구분이 메모리 지표를 해석하는 기본입니다.

부하를 올렸다가 충분히 내리는 회복 실험을 하겠습니다. 살아 있는 객체와 요청량은 안정됐는데 RSS만 높은 값에서 평평해지면 재사용 공간·단편화 가능성이 큽니다. 부하를 반복할 때 생존 객체, native heap, 매핑, 열린 파일·스레드가 계속 증가하면 그 증가 영역부터 프로파일합니다. GC를 호출하는 것만으로 native allocation이나 파일 매핑이 정리되지는 않으며, GC가 보유 메모리를 OS에 돌려줄 수 있는지도 런타임과 할당자에 따라 다릅니다.

누수 여부는 부하를 내린 뒤에도 무엇이 남는지로 좁힙니다. 예를 들어 살아 있는 객체 수는 100만 개에서 안정됐는데 allocator arena만 2GiB를 유지하면 재사용 공간이나 단편화를 우선 의심합니다. 반대로 요청을 반복할 때 콜백·전역 캐시·thread-local 객체와 native allocation이 계속 증가하면 소유 경로를 추적합니다. fork 후 공유 페이지는 각 프로세스 RSS를 단순 합산하면 안 되고 PSS로 부담을 나눠야 하며, 쓰기 시 copy-on-write가 private page를 늘릴 수 있습니다.

trim을 강제로 실행하면 RSS는 내려가도 다음 요청에서 매핑과 page fault가 늘어 p99가 악화될 수 있습니다. 그래서 스냅숏 한 번이 아니라 부하 상승·안정·하강의 세 구간에서 객체량, allocator 보유량, 익명·파일 매핑, RSS·PSS와 cgroup 사용량을 함께 기록하겠습니다. 애플리케이션 해제와 OS 페이지 반환을 같은 사건으로 표시하지 않는 것이 핵심입니다.

메모리 프로파일은 생존 객체의 타입과 할당 호출 지점을 보여 주지만, RSS가 왜 남았는지는 매핑·할당자 통계와 함께 봐야 합니다. 반환 가능한 arena와 실제 참조 중인 객체를 구분하고, 파일 캐시를 애플리케이션 누수로 세지 않겠습니다. 회복 후에도 증가가 계속되는 영역만 누수 후보로 좁히겠습니다.

메모리 누수의 판단에는 시간축과 소유 관계가 모두 필요합니다. 30분 soak 뒤 객체 수·native allocation·열린 파일·스레드가 안정되고 RSS만 유지되면 재사용 공간일 수 있지만, 각 단계마다 동일한 양이 누적되면 누수 후보입니다. 큰 객체를 해제해도 작은 객체가 같은 페이지를 붙잡을 수 있고, 파일 매핑은 객체 힙과 별도로 RSS에 보일 수 있습니다. 영역별 프로파일과 매핑 목록을 연결해 증가 원인을 좁히겠습니다.