Memory Diagnostics · 5/7

운영 메모리 누수 진단 — long-running 프로세스의 진단 전략

2026년 5월 31일 · Hawk · 4분 읽기

이 시리즈의 마지막 장 — 재현 환경 없는 운영의 누수 진단. ASan은 빌드 다시 필요, Valgrind는 너무 느림, heaptrack은 trace 너무 큼. 그래서 프로덕션 친화 도구 셋이 필요합니다.

#1단계 — 누수 확인

운영에서 “메모리 많이 쓴다” 가 진짜 누수인지부터.

1
# 시간별 PSS 추이 — 누수 여부 결정적 단서
2
$ for i in $(seq 1 100); do
3
    pss=$(sudo cat /proc/$PID/smaps_rollup | grep "^Pss:" | awk '{print $2}')
4
    echo "$(date +%s) $pss"
5
    sleep 60
6
  done > /tmp/pss.log

추세:

우상향 무한 → 누수.
우상향 후 수렴 → 캐시 (정상).
주기적 sawtooth → GC가 있는 언어 (Go/Java) 또는 explicit free.
플랫 → 누수 없음.

gnuplot / matplotlib로 시각화:

1
$ gnuplot -e "
2
    set terminal png;
3
    set output '/tmp/pss.png';
4
    plot '/tmp/pss.log' using 1:2 with lines
5
"

#2단계 — 누수 영역 좁히기

1
$ sudo cat /proc/$PID/status | grep -E "Rss|Vm"
2
RssAnon:   5000000 kB     # 폭주? heap 또는 anon mmap
3
RssFile:    200000 kB     # 정상 범위
4
RssShmem:    50000 kB     # 정상

RssAnon만 폭주 → 일반 heap 또는 mmap 누수. RssFile 폭주 → 파일 매핑 누수 (Drogon 같은 framework의 log file mmap 등).

1
$ sudo cat /proc/$PID/smaps | awk '
2
  /^[0-9a-f]+-/ { mapping=$0 }
3
  /^Private_Dirty:/ {
4
    if ($2 > 10240) print $2 " KB " mapping
5
  }' | sort -n -r | head
6
6000000 KB  7f1234567000-7f56789abc00 rw-p 00000000 00:00 0
7
2000000 KB  7f3456789000-7f789abcdef00 rw-p 00000000 00:00 0
8
[stack]
9
[heap]
10
...

가장 큰 private dirty 영역이 범인. anon mmap (소스 표시 없음)이면 어디서 mmap했는지 알기 어려움 — strace로.

#3단계 — 누수 콜스택

#옵션 A — jemalloc profiling 상시

가장 추천. 재시작 한 번으로 상시 활성.

1
# 서비스 환경 변수에
2
MALLOC_CONF=prof:true,prof_active:true,prof_prefix:/var/log/myprog/jeprof,lg_prof_sample:19
3
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2

부하: < 5%. 운영에 상시 활성 가능.

자동 dump 트리거 (SIGUSR2 등):

1
#include <signal.h>
2
#include <jemalloc/jemalloc.h>
3

4
void dump_handler(int sig) {
5
    mallctl("prof.dump", NULL, NULL, NULL, 0);
6
}
7

8
int main() {
9
    signal(SIGUSR2, dump_handler);
10
    // ...
11
}

1
# RSS 증가 의심 시 외부에서
2
$ sudo kill -USR2 $PID
3
# /var/log/myprog/jeprof.<pid>.<n>.heap 생성
4

5
# 두 시점 diff
6
$ jeprof --text --base=jeprof.12345.0.heap \
7
    ./myprog jeprof.12345.20.heap | head

#옵션 B — eBPF 메모리 추적

BCC tools의 memleak.

1
$ sudo /usr/share/bcc/tools/memleak -p $PID --combined-only
2
Attaching to pid 12345, Ctrl+C to quit.
3
[3:21:14] Top 10 stacks with outstanding allocations:
4
        152040000 bytes in 76020 allocations from stack
5
                __libc_malloc+0x2a [libc.so.6]
6
                Cache::add+0x42 [myprog]
7
                Server::process+0x123 [myprog]
8
                main+0x88 [myprog]
9
        ...

5초 대기 → 그 5초 동안 alloc + 추적 안 된 free의 누적 누수.
운영에 부담 적음 (eBPF verifier 통과).

#옵션 C — heaptrack attach

1
$ heaptrack -p $PID
2
[10분 후]
3
^C
4
$ heaptrack_gui heaptrack.myprog.*.zst

heaptrack-gui의 Consumed 탭에서 시간별 메모리 그래프 + 콜스택. 한 화면.

부하: 2-3x. 운영 영향 있으나 짧은 샘플은 허용.

#옵션 D — drgn으로 라이브 분석

1
$ sudo drgn -p $PID
2
>>> from drgn.helpers.linux import *
3

4
# vmalloc 영역
5
>>> for addr, info in vmalloc_areas(prog):
6
...     print(hex(addr), info.size)
7

8
# slab 통계 (커널)
9
>>> for slab in for_each_slab_cache(prog):
10
...     print(slab.name.string_(), slab.size)

drgn은 user-space 프로세스의 동적 정보에도 활용 가능 (커널 측에서 본 정보 + procfs).

#4단계 — 누수 수정 후 검증

코드 수정 → 다시 배포 → 시간별 PSS가 수렴하는지.

1
# 자동화 — 30분간 PSS 측정, 추세 확인
2
$ ./monitor_pss.sh $PID 30  | tee pss-after.log
3
$ python3 -c "
4
import numpy as np
5
data = np.loadtxt('pss-after.log')[:, 1]
6
slope = np.polyfit(range(len(data)), data, 1)[0]
7
print(f'slope: {slope:.2f} KB/sec')
8
print('LEAK' if slope > 1024 else 'OK')
9
"

CI에 통합 — 매 배포 시 짧은 load test + slope 검증으로 회귀 차단.

#cgroup memory.max — 보호

운영 환경에서 프로세스 단일 메모리 사용 제한. OOM이 해당 cgroup 안에서만 일어남.

1
# systemd unit
2
[Service]
3
MemoryMax=4G
4
MemoryHigh=3.5G        # 이 위는 throttle
5

6
# 수동
7
$ sudo systemd-run --scope -p MemoryMax=4G ./myprog

cgroup v2:

1
$ sudo mkdir /sys/fs/cgroup/myapp
2
$ echo 4G | sudo tee /sys/fs/cgroup/myapp/memory.max
3
$ echo $PID | sudo tee /sys/fs/cgroup/myapp/cgroup.procs

memory.max — hard limit. 초과 시 OOM killer.
memory.high — soft limit. 초과 시 throttle (reclaim 가속).
memory.low — minimum. OOM 시 마지막.
memory.swap.max — swap 한도.

1
# 현재 사용량
2
$ cat /sys/fs/cgroup/myapp/memory.current
3
3500000000
4

5
$ cat /sys/fs/cgroup/myapp/memory.stat | head
6
anon 2500000000
7
file 1000000000
8
kernel_stack 1048576
9
pagetables 524288
10
...

container 환경(Docker/K8s)은 이미 cgroup 사용. K8s resources.limits.memory가 memory.max에 매핑.

#OOM 회피 — graceful degradation

OOM 직전에 서비스가 알아채고 캐시 비우기.

1
// 주기적 RSS 체크
2
#include <sys/resource.h>
3

4
void check_memory() {
5
    struct rusage ru;
6
    getrusage(RUSAGE_SELF, &ru);
7
    long rss_kb = ru.ru_maxrss;
8

9
    if (rss_kb > 3 * 1024 * 1024) {  // 3GB 이상
10
        log_warning("memory pressure, clearing caches");
11
        clear_caches();
12
        malloc_trim(0);
13
    }
14
}

또는 PSI (Pressure Stall Information):

1
$ cat /proc/pressure/memory
2
some avg10=0.50 avg60=0.30 avg300=0.10 total=1234567
3
full avg10=0.10 avg60=0.05 avg300=0.02 total=234567

some — 일부 프로세스가 메모리 대기.
full — 모든 프로세스가 대기.
임계값 등록 → poll/epoll 알림.

1
int fd = open("/proc/pressure/memory", O_RDWR | O_NONBLOCK);
2
write(fd, "some 150000 1000000", 19);  // 1초 중 150ms 이상 stall이면 알림
3
// poll(...)으로 대기

systemd-OOMD가 이걸 활용 — 완전 OOM 전에 memory.swap.max 늘리거나 worst 프로세스 종료.

#자동 dump 트리거

1
// 메모리 폭주 의심 시 자동으로 jemalloc dump
2
void *monitor_thread(void *arg) {
3
    long last_rss = 0;
4
    while (1) {
5
        sleep(60);
6
        long rss = get_rss();
7
        if (rss > last_rss * 1.5) {
8
            // 50% 급증 → dump
9
            mallctl("prof.dump", NULL, NULL, NULL, 0);
10
            log_info("auto-dumped at RSS=%ld", rss);
11
        }
12
        last_rss = rss;
13
    }
14
}

대규모 서비스에서 모든 누수가 자동 캡처 → 사후 분석.

#로그 통합 — Prometheus + Grafana

1
// /metrics endpoint
2
http_handler("/metrics", [](){
3
    struct mallinfo2 mi = mallinfo2();
4
    fprintf(out, "myapp_heap_used %zu\n", mi.uordblks);
5
    fprintf(out, "myapp_heap_free %zu\n", mi.fordblks);
6
    fprintf(out, "myapp_heap_arena %zu\n", mi.arena);
7
});

Prometheus가 polling. Grafana에서 RSS, heap_used, heap_free를 함께 그래프 → fragmentation 시각화.

#Java/JVM 특수 — JFR / heap dump

JVM은 자체 heap profiler.

1
# JFR (Java Flight Recorder)
2
$ jcmd $PID JFR.start filename=/tmp/leak.jfr duration=60s
3

4
# heap dump
5
$ jmap -dump:format=b,file=/tmp/heap.hprof $PID
6

7
# 분석
8
$ eclipse-mat /tmp/heap.hprof

native 부분은 위 도구로, Java heap은 JVM 도구로 — 두 길로 분리.

#Python 특수

1
import tracemalloc
2
tracemalloc.start(25)
3

4
# 의심 작업
5
process()
6

7
snapshot = tracemalloc.take_snapshot()
8
top = snapshot.statistics('lineno')
9
for stat in top[:10]:
10
    print(stat)

Python Debugging Ch 5에서 자세히. 운영 Django/Flask 서비스에 적용 가능.

#Go 특수

1
import _ "net/http/pprof"
2

3
go http.ListenAndServe(":6060", nil)
4

5
// 외부에서
6
$ go tool pprof http://localhost:6060/debug/pprof/heap

Go는 GC. 누수는 goroutine leak 또는 map에 무한 key 형태가 흔함.

#시리즈 정리

5장으로 메모리 진단 전체.

Ch 1 메모리 회계 — VSS/RSS/PSS, /proc/[pid]/smaps.
Ch 2 heaptrack — 가벼운 heap profiler.
Ch 3 jemalloc/tcmalloc + pprof.
Ch 4 glibc 자체 도구 — mtrace/mcheck/MALLOC_CHECK_.
Ch 5 (이 장) 운영 누수 진단 — cgroup, PSI, 자동 dump.

도구 선택 흐름:

개발 — ASan + Valgrind Memcheck.
스테이징 — heaptrack 또는 jemalloc prof.
운영 — jemalloc 상시 prof + smaps_rollup 모니터링.
비상 — eBPF memleak + drgn.

#정리

누수 확인 → /proc/[pid]/smaps_rollup의 PSS 추세.
누수 영역 → smaps의 Private_Dirty 정렬.
누수 콜스택 → jemalloc prof (상시) 또는 BCC memleak.
cgroup memory.max로 보호 + PSI로 graceful degradation.
자동 dump로 모든 사고 캡처.
Java/Python/Go는 자체 도구 병용.

#관련 항목 (시리즈 전체)

#외부 자료

Memory Diagnostics · 5 of 7

glibc 메모리 도구 — mtrace·mcheck·MALLOC_CHECK_

별 라이브러리 없이 glibc 만으로 메모리 디버깅. mtrace, mcheck, MALLOC_CHECK_.

2026년 5월 31일·memory

jemalloc·tcmalloc Profiling — 운영 allocator의 진단 기능

표준 glibc malloc 대체 + 내장 profiler. pprof로 시각화.

2026년 5월 31일·memory

heaptrack 분석 — 가벼운 heap profiler 활용

Valgrind보다 빠른 heap profiler. KDE 출신, 운영 환경에도 적용 가능.

2026년 5월 31일·memory

이 글을 참조하는 글 (1)

glibc 메모리 도구 — mtrace·mcheck·MALLOC_CHECK_— Memory Diagnostics

#1단계 — 누수 확인

#2단계 — 누수 영역 좁히기

#3단계 — 누수 콜스택

#옵션 A — jemalloc profiling 상시

#옵션 B — eBPF 메모리 추적

#옵션 C — heaptrack attach

#옵션 D — drgn으로 라이브 분석

#4단계 — 누수 수정 후 검증

#cgroup memory.max — 보호

#OOM 회피 — graceful degradation

#자동 dump 트리거

#로그 통합 — Prometheus + Grafana

#Java/JVM 특수 — JFR / heap dump

#Python 특수

#Go 특수

#시리즈 정리

#정리

#관련 항목 (시리즈 전체)

#외부 자료

Memory Diagnostics · 5 of 7

관련 글

glibc 메모리 도구 — mtrace·mcheck·MALLOC_CHECK_

jemalloc·tcmalloc Profiling — 운영 allocator의 진단 기능

heaptrack 분석 — 가벼운 heap profiler 활용

이 글을 참조하는 글 (1)