[Linux] ps / top 프로세스와 시스템 상태 완전 정복 🧠

리눅스 ps top 프로세스 모니터링 명령어를 한 번에 정리한 실무 가이드입니다. CPU 100% 장애, 메모리 부족, 좀비 프로세스 등 문제를 ps와 top으로 진단·해결하는 방법을 단계별로 설명합니다.

리눅스 서버를 운영하다 보면 어느 날 갑자기 이런 상황이 찾아옵니다.

• “CPU가 100%인데, 어떤 프로세스가 범인인지 모르겠다.”
• “메모리 사용량이 계속 올라가는데 로그도 조용하다.”
• “프로세스가 좀비(Z) 상태로 잔뜩 쌓여 있다.”
• “서버가 멈춘 것처럼 느린데, 어디부터 봐야 할지 모르겠다.”

이런 문제를 해결하는 가장 기본이자 강력한 도구가 ps와 top입니다.
둘만 제대로 이해해도 장애 원인의 70%는 눈에 보이는 형태로 드러납니다.

오늘은 실제 운영 환경에서 사용하는 방식 그대로,
CPU 병목 → 메모리 누수 → 좀비 프로세스 → 중복 실행 스크립트 → 프로세스 트리 분석까지
단계별로 정리해보겠습니다.

---

🔑 이 글의 핵심 키워드

• 리눅스 ps top 프로세스 모니터링
• CPU 100% 장애 분석
• 메모리 부족 진단
• 좀비 프로세스(Zombie) 확인
• 데몬/서비스 트리 구조 파악

---

1. ps는 “현재 상태를 정확히 찍는” 도구

프로세스 컬럼의 의미를 시각적으로 정리한 다이어그램

먼저 ps(Process Status)입니다.
리눅스 ps top 프로세스 모니터링의 출발점이라고 보면 됩니다.
가장 많이 쓰는 기본 형태는 이거 하나입니다.

ps aux

 

1) ps aux 옵션 구조

• a : 다른 사용자 프로세스까지 포함
• u : CPU/메모리 등 사용자 중심 포맷으로 출력
• x : 터미널(TTY)이 없는 프로세스까지 포함

정리하면:

ps aux = “실행 중인 거의 모든 프로세스를 사람이 보기 좋은 형태로 다 보여줘”

2) ps aux 출력 컬럼 이해하기

예시 출력:

ps aux
USER   PID  %CPU %MEM    VSZ    RSS  TTY   STAT  START   TIME  COMMAND
root     1   0.0  0.1   2788   1348  ?     Ss    10:00   0:01  /sbin/init
root   234   1.2  3.1 140000  25432  ?     Sl    10:03   0:20  /usr/bin/python3 app.py
www    400   5.3  4.5 230000  35200  ?     Rl    10:05   1:10  nginx: worker process

 

여기서 리눅스 ps top 프로세스 모니터링에서 꼭 알아야 할 핵심 컬럼은 다음 5개입니다.

컬럼	설명
PID	프로세스 ID
%CPU	CPU 사용률
%MEM	메모리 사용률
STAT	프로세스 상태(S, R, Z, T 등)
COMMAND	어떤 명령으로 실행된 프로세스인지

나머지 VSZ, RSS도 중요하지만,
처음에는 PID / %CPU / %MEM / STAT / COMMAND만 제대로 읽어도 장애 분석의 70%는 해결됩니다.

---

2. ps 실전 패턴 : 장애 현장에서 가장 많이 쓰는 명령

이제 자주 쓰는 ps 패턴들을 보면서,
“실제 장애가 났을 때 어떻게 쓰는지” 눈에 익혀봅시다.

1) 특정 프로세스만 빠르게 찾기

예: nginx 관련 프로세스 찾기

ps aux | grep nginx

 

하지만 이렇게 하면 grep nginx 자기 자신도 같이 뜹니다.
그래서 보통은 이렇게 한 줄 더 추가합니다.

ps aux | grep nginx | grep -v grep

 

조금 더 깔끔하게 하고 싶다면 pgrep, pidof를 사용할 수도 있습니다.

pgrep nginx           # nginx의 PID만 출력
pidof nginx           # nginx 프로세스들의 PID

 

2) CPU 사용률 TOP 10 프로세스 보기

CPU를 가장 많이 사용하는 프로세스를 확인하려면:

ps aux --sort=-%cpu | head

 

혹은 정렬 키를 명시적으로 쓰는 패턴도 자주 사용합니다.

ps aux | sort -nrk 3 | head -10

 

• -nrk 3 : 3번째 컬럼(%CPU)을 기준으로 숫자 내림차순 정렬

3) 메모리 사용률 TOP 10

메모리 누수를 의심할 때:

ps aux --sort=-%mem | head
# 또는
ps aux | sort -nrk 4 | head -10

 

여기서 %MEM이 높은 프로세스를 먼저 의심해보면 됩니다.

4) 특정 사용자 프로세스만 보기

웹서버 계정(www, nginx 등)만 보고 싶을 때:

ps -u www

 

서비스 계정별로 리소스를 어떻게 쓰는지 확인할 때 유용합니다.

5) 부모-자식 관계를 트리로 보기 (–forest)

부모-자식 프로세스를 한눈에 보는 ps --forest 다이어그램

시스템 데몬 구조 분석에 필수입니다.

ps -ef --forest

 

• 어떤 데몬 아래에 어떤 워커가 매달려 있는지
• 스크립트가 몇 단계로 실행되는지
• 시각적으로 파악하기 좋습니다.

---

3. top “실시간 화면” 추적 도

이제 top입니다.
ps가 “정지된 사진”이라면 top은 “실시간 CCTV”입니다.

top

 

실행하면 대략 이런 화면이 나옵니다.

리눅스 top 명령어로 서버의 CPU, 메모리, 프로세스 상태를 실시간 모니터링하는 실제 화면 예시

1) top 상단 요약 영역

리눅스 ps top 프로세스 모니터링에서 꼭 봐야 하는 항목들입니다.

1. load average
2. Tasks (총 프로세스 수, running/sleeping/zombie)
3. %Cpu(s) (us, sy, id 등)
4. Mem / Swap 요약

우선 load average부터 정확히 이해해봅시다.

2) load average 해석

load average: 0.12, 0.23, 0.45

• 앞에서부터 1분 / 5분 / 15분 평균 부하
• “얼마나 많은 작업이 CPU를 기다리고 있었는지”를 의미

가장 중요한 기준은 “코어 수”입니다.

• 1코어 서버에서 load 1.0 = CPU 풀로 사용 중
• 4코어 서버에서 load 4.0 = 전체 코어가 거의 꽉 찬 상태

대략적인 느낌:

• 4코어 서버 기준
  • load 4 이내 → 정상
  • 5~7 → CPU가 바빠지기 시작
  • 8~10 이상 → 지연/병목 발생 가능성이 높음

load가 높으면 “CPU 사용률이 높은 프로세스가 있는지” 먼저 확인합니다.

3) CPU 상태(us, sy, wa 등)

예시:

%Cpu(s): 10.3 us, 1.5 sy, 0.0 ni, 88.0 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st

 

• us : user space에서 실행되는 CPU 비율 (일반 앱/서비스)
• sy : kernel space (시스템 콜, 드라이버 등)
• id : idle, 놀고 있는 비율
• wa : I/O wait (디스크/네트워크 대기)
• si : soft interrupt
• hi : hard interrupt

장애 분석 포인트:

• us가 높다 → 앱 또는 스크립트 코드가 CPU를 많이 씀
• sy가 높다 → 커널/시스템 호출이 많은 작업 (패킷 처리, I/O 등)
• wa가 높다 → CPU는 놀고 있는데 I/O 대기 때문에 느린 경우 (디스크 병목)

4) Mem/Swap 요약 읽는 법

KiB Mem : 4049920 total, 223000 free, 210000 buffers, 1024000 cached
KiB Swap: 2097148 total,  10240 used, 2086908 free

 

• total : 전체 메모리
• free : 완전히 놀고 있는 메모리
• buffers, cached : 파일 캐시, 블록 디바이스 버퍼 등

주의할 점:
리눅스는 메모리를 “남는 대로 캐시로 써버리기 때문에” free만 보고 부족하다고 판단하면 안 됩니다.
보통은:

• swap 사용량이 급격히 증가하고
• cache/buffer가 줄고
• 프로세스 메모리가 계속 늘어날 때 → 메모리 누수 의심

5) top 실무 단축키

top를 잘 쓰려면 키보드 단축키를 몇 개만 익히면 됩니다.

키	기능 설명
P	CPU 사용률 높은 순 정렬
M	메모리 사용률 높은 순 정렬
1	코어별(CPU별) 사용률 표시
k	프로세스 종료(kill)
q	top 종료
h	도움말
SHIFT + > / <	정렬 기준 컬럼 이동

실무에서 가장 많이 쓰는 조합:

• CPU 문제다 → top 실행 후 바로 P
• 메모리 문제다 → top 실행 후 바로 M
• 멀티코어 상황 확인 → 1 눌러서 코어별로 분리해서 보기

---

4. 실제 장애 상황별 접근법

이제 실제 장애 상황을 가정해 보면서,
ps와 top을 어떻게 쓰는지 단계별로 정리해볼게요.

예제 1) “서버가 갑자기 너무 느려요” (CPU 100% 상황)

• 먼저 top 실행

top

• CPU가 꽉 찼는지 확인
  • load average가 코어 수 대비 너무 높은지
  • %Cpu(s)에서 us/sy가 비정상적으로 높은지
• top 화면에서 P를 눌러 CPU 사용률 정렬
  • 상단에 %CPU가 100%에 가깝거나, 코어 수 이상으로 나오는 프로세스를 찾습니다.
• 문제 PID 확보 후, 세부 정보 확인

ps aux | grep PID

 

• 필요 시 종료

kill -9 PID

주의:
무조건 kill -9부터 쓰지 말고,
가능하면 서비스 graceful stop → 그래도 안 먹으면 강제 종료 순으로 접근하는 게 좋습니다.

예제 2) 메모리가 부족해 보일 때

• top 실행 후 메모리 요약 확인
• M 키로 정렬해서 %MEM 높은 순으로 확인
• 상단에 있는 프로세스를 ps로 한 번 더 확인

ps aux --sort=-%mem | head

 

• 특정 앱이 계속 메모리를 먹고 있다면 →
  • 해당 버그 의심
  • 로그/옵션/캐시 설정 확인

예제 3) 좀비 프로세스(Zombie) 많이 생겼을 때

• ps에서 상태가 Z인 프로세스 찾기

ps aux | awk '$8 ~ /Z/' 
# 또는
ps aux | grep ' Z '

 

• 좀비는 부모 프로세스가 wait()를 호출하지 않아서 생기는 것이므로,
• 부모 PID를 찾는 게 중요합니다.

ps -ef --forest

 

• 트리 구조에서 부모 프로세스를 확인 →
  • 부모를 재시작하거나
  • 부모 프로그램의 코드 수정 필요

좀비 자체는 CPU/메모리를 거의 쓰지 않지만,
대량으로 쌓이면 리소스 제한에 걸릴 수 있으므로 관리 대상입니다.

---

예제 4) 동일 스크립트가 여러 번 중복 실행되는 경우

실제로 장애의 상당수는 중복 실행된 shell/python 스크립트입니다.

• 예: 특정 백업 스크립트가 매번 쌓일 때

ps aux | grep backup.sh | grep -v grep

 

• 개수를 세고 싶으면:

ps aux | grep backup.sh | grep -v grep | wc -l

 

• 필요하다면 한 번에 정리:

pkill -f backup.sh

 

(운영 환경에서는 무조건 pkill 쓰기 전에 꼭 한 번 더 확인하세요.)

---

예제 5) 데몬/서비스 트리 구조 확인

서비스 구조를 확인할 때 가장 좋은 패턴:

ps -ef --forest | grep nginx
ps -ef --forest | grep httpd
ps -ef --forest | grep mysqld

 

• 마스터 프로세스 → 워커 프로세스
• 런처 스크립트 → 실제 실행 바이너리

이 흐름을 한 번 이해해두면,
“어디를 재시작해야 하는지”, “누가 누구를 띄우는지”가 한눈에 들어옵니다.

---

5. ps / top / grep / awk 조합

리눅스 프로세스 분석을 위한 ps·top·grep·awk 조합 구조 다이어그램

리눅스 ps top 프로세스 모니터링은 결국 파이프라인의 조합입니다.

1) CPU 사용 TOP 5 (정석 패턴)

ps aux | sort -nrk 3 | head -5

 

• 3번 컬럼이 %CPU
• 가장 위에 있는 프로세스부터 확인

---

2) 메모리 사용 TOP 5

ps aux | sort -nrk 4 | head -5

 

3) 특정 프로세스만 top으로 실시간 보기

예: nginx만 top으로 추적하고 싶다면:

top -p $(pidof nginx)

 

여러 PID를 한 번에 넣을 수도 있습니다.

top -p 1234,2345,3456

 

---

6. 초보자가 자주 하는 실수와 리눅스 ps top 프로세스 모니터링 팁

실수	이유	해결 방법
그냥 ps만 입력	기본 ps는 정보가 너무 단순함	항상 ps aux 또는 ps -ef 사용
grep 자기 자신이 검색됨	grep도 프로세스로 뜸	grep -v grep, pgrep, pidof 활용
load average 숫자만 보고 놀람	CPU 코어 수를 고려하지 않음	“코어 수 × 1.0”을 기준으로 판단
top에서 CPU 정렬 못함	단축키를 모름	top 실행 후 P, 메모리는 M
좀비 프로세스만 죽이려 함	원인은 부모 프로세스인데 자식만 봄	ps -ef --forest로 부모 PID까지 확인
메모리 부족을 free만 보고 판단	캐시/버퍼를 이해하지 못함	Swap 사용량, cache/buffer 변화도 함께 확인

---

7. 리눅스 ps top 프로세스 모니터링은 어떤 효과를 주는가?

이 글에서 다룬 내용만 익혀도 다음과 같은 효과가 있습니다.

• CPU 100% 장애를 ps/top 조합으로 직접 진단할 수 있다.
• 메모리 누수 의심 상황에서 어떤 프로세스가 문제인지 빠르게 찾을 수 있다.
• 좀비 프로세스, 중복 실행된 스크립트 등 숨은 문제를 찾을 수 있다.
• 데몬/서비스의 프로세스 트리 구조를 이해하고 관리할 수 있다.
• 장애가 났을 때 “어디부터 봐야 할지” 루틴이 생겨서 대응 속도가 빨라진다.

결국, 리눅스 ps top 프로세스 모니터링을 익힌다는 건

“리눅스 시스템 안에서 실제로 무슨 일이 일어나는지 눈으로 볼 수 있는 능력”을 갖는 것입니다.

---

핵심 요약

• ps는 정적인 스냅샷, top은 실시간 모니터링 도구
• ps aux, ps -ef --forest, top + P/M/1 조합이 실무 기본
• CPU 문제 → top + P → ps로 상세 확인 → 필요 시 kill
• 메모리 문제 → top + M → ps aux --sort=-%mem
• 좀비/중복 스크립트 → ps + grep/awk + 트리 구조 확인
• 리눅스 ps top 프로세스 모니터링을 익히면 장애 대응 속도가 극적으로 빨라진다

 

 

이전글 보기

[Linux] awk / sed — 텍스트 처리·로그 분석 실무 가이드 📑

 

다음글 보기

[Linux] ss / netstat — 포트·소켓 분석 완전 정복 🌐