[Linux] 운영 서버 프로세스 이상 진단: 좀비, 메모리 누수, CPU 과점유 실전 대응

ps aux의 STAT 컬럼은 프로세스의 현재 상태를 한 글자로 나타냅니다. 이 코드를 읽으면 "왜 느린지"에 대한 첫 번째 단서를 얻을 수 있습니다.

STAT 뒤에 붙는 수식어도 중요합니다: s = 세션 리더, + = 포어그라운드, l = 멀티스레드, < = 높은 우선순위, N = nice 적용(낮은 우선순위)

앞의 STAT 표에서 좀비(Z)는 "종료됐지만 부모가 회수 안 함", 고아는 "부모가 먼저 죽음"이라고 했습니다. 왜 이런 상태가 생기는지는 프로세스가 어떻게 태어나고 죽는지를 알아야 이해됩니다. 리눅스에서 새 프로세스는 무에서 생기지 않고 항상 부모를 복제(fork)한 뒤 다른 프로그램으로 갈아끼우는(exec) 방식으로 만들어집니다. bash에서 ls를 치는 것도, 컨테이너에서 앱이 뜨는 것도 모두 이 4단계 흐름의 결과입니다.

[부모]  bash (PID 2000)
   │
   │  ① fork()  ── 부모를 통째로 복제. 메모리는 Copy-on-Write로
   │              일단 공유하다 어느 쪽이 쓰면 그 페이지만 복사
   ▼
   ├──────────────────────────────┐
 부모(PID 2000)                 자식(새 PID 2001)
   │                              │
   │                              │  ② exec()  ── 자기 프로세스 이미지를
   │                              │              /bin/ls 로 통째 교체
   │                              │              (PID는 그대로, 내용만 바뀜)
   │                              │
   │  ③ wait() 로 자식 종료를 대기   │  ④ exit(code) ── 일 끝나면 종료코드 반환
   │            ◄──────────────────┘
   │  종료코드 수거 → 자식을 프로세스 테이블에서 제거(완전 소멸)
   ▼
[부모 계속 실행]

각 단계가 하는 일과, 어긋나면 어떤 증상인가:

좀비와 고아는 이 흐름의 두 가지 어긋남입니다. 좀비(Z)는 ③이 빠진 경우 — 자식은 이미 exit했는데(④) 부모가 wait로 거두지 않아, 자원은 거의 없이 종료 코드만 프로세스 테이블에 남습니다. 이미 죽었으니 kill이 통하지 않고, 부모가 wait하거나 부모가 사라져야만 정리됩니다. 고아는 ③보다 먼저 부모가 죽은 경우 — 이때 자식은 PID 1(systemd)에게 입양되고, PID 1은 주기적으로 wait하는 특별한 역할을 하므로 입양된 자식이 종료되면 곧바로 거둬 좀비가 영구화되지 않게 합니다. 그래서 "좀비가 안 사라진다"의 해결책은 좀비를 kill하는 게 아니라 부모를 재시작해 PID 1이 입양·회수하게 만드는 것입니다.

프로세스는 이 사이에서 STAT 상태를 오갑니다 — fork/exec 직후 실행 가능해지면 R, I/O를 기다리며 잠들면 S(깨울 수 있음)·D(디스크 등 인터럽트 불가), 정지 신호를 받으면 T, exit 후 미수거 상태가 Z입니다. ps -ef --forest로 부모-자식(PPID) 관계를 트리로 보면, 어느 부모가 자식을 안 거두고 있는지(좀비의 원인)를 바로 짚을 수 있습니다.

같은 프로세스라도 호스트와 컨테이너에서 보이는 PID가 다릅니다. 이걸 모르면 엉뚱한 PID를 죽여 다른 컨테이너나 호스트를 통째로 내릴 수 있기 때문에, 컨테이너 환경에서 프로세스를 다루기 전에 반드시 짚어야 합니다.

컨테이너는 PID 네임스페이스로 격리되어, 컨테이너 안에서 ps aux를 하면 그 컨테이너의 메인 프로세스가 PID 1로 보입니다. 하지만 호스트에서 보면 같은 프로세스가 847 같은 다른 번호를 가집니다. 그래서 컨테이너 내부에서 kill 1은 그 컨테이너만 종료하지만, 호스트에서 kill 1은 systemd를 죽여 시스템 전체가 다운됩니다. 호스트에서 컨테이너 프로세스를 확인하려면 cat /proc/<호스트PID>/cgroup으로 어느 컨테이너 소속인지, docker inspect <컨테이너> | grep Pid로 매핑을 먼저 확인합니다.

확대

ps aux의 USER 컬럼이 root인 서비스 프로세스를 보면 경계해야 합니다. 그 프로세스에 취약점이 하나라도 있으면 공격자가 곧바로 서버 전체 권한을 얻기 때문입니다.

서비스를 전용 계정(예: myapp)으로 실행하면 취약점이 뚫려도 피해가 그 계정이 접근 가능한 범위로 제한됩니다. systemd 서비스에 User=/Group=으로 전용 계정을 지정하고, NoNewPrivileges=yes(SUID 권한 상승 차단)·ProtectSystem=full(/usr·/etc 읽기 전용)·PrivateTmp=yes(/tmp 격리)를 더하면 최소 권한 원칙이 적용됩니다. 핵심은 단일 서비스의 취약점이 서버 전체 장악으로 번지지 않게 막는 것입니다.

확대

지금까지 '느린 서버'의 범인을 프로세스 안에서(과점유·좀비·D 상태) 찾았습니다. 그런데 top의 프로세스 %CPU는 낮고 load도 높지 않은데 응답만 느린 경우가 있습니다. 이때는 범인이 프로세스 밖 — 가상화 계층이나 cgroup 제한 — 에 있습니다.

• top의 CPU 줄을 끝까지 읽어야 합니다: us(유저)·sy(커널) 말고 st(steal)와 wa(iowait)가 힌트입니다. **st(steal time)**는 '내 VM이 CPU를 쓰려 했는데 하이퍼바이저가 다른 VM에 줘서 뺏긴 시간'입니다. st가 높으면 내 프로세스는 죄가 없고, 물리 호스트가 과매각(oversubscribed)됐거나 시끄러운 이웃(noisy neighbor)이 있는 것입니다.
• 컨테이너는 CPU에도 상한이 있습니다: 메모리에 limit이 있듯 CPU에도 cgroup 쿼터(CFS quota)가 걸립니다. 예를 들어 '0.5 코어' 제한은 100ms 주기마다 50ms만 쓰게 하고, 그 안에서 다 쓰면 남은 주기 동안 강제로 멈춥니다(throttle). 이때 컨테이너 안에서 본 %CPU는 낮은데 실제로는 계속 정지당해 지연이 튑니다.
• 스로틀링은 평균 사용률에 숨습니다: 1초 평균 CPU가 40%여도, 100ms 창 단위로는 앞 50ms 폭주 후 뒤 50ms 정지가 반복될 수 있습니다. 그래서 '사용률은 낮은데 p99 지연이 나쁜' 전형적 패턴이 됩니다. 증거는 사용률이 아니라 cpu.stat의 nr_throttled·throttled_time입니다.
• 진단 지점이 다릅니다: steal은 top·vmstat의 st, mpstat의 %steal로 봅니다. 스로틀링은 컨테이너 cgroup의 cpu.stat을 봐야 하고, 호스트에서 %CPU만 보면 절대 안 잡힙니다.

핵심은 '느림'의 책임이 항상 내 프로세스에 있지는 않다는 것입니다. 프로세스 안(과점유·I/O)을 봤는데 깨끗하다면, 그 위의 **가상화(steal)와 cgroup 제한(throttle)**으로 시선을 올려야 합니다.