top, htop, ps - 리눅스 모니터링 세 가지 도구 제대로 쓰기

서버 응답이 느려졌다는 알림이 오면, SSH로 들어가서 가장 먼저 두드리는 명령어가 보통 top, htop, ps 중 하나입니다. 신입 때 저는 어디서 본 대로 top을 쳐놓고 화면만 멍하니 보다가, 뭐가 어떤 의미인지 몰라서 결국 선배한테 전화를 걸었던 기억이 있어요. 세 도구가 비슷해 보이지만 쓰는 상황과 보여주는 정보가 조금씩 다른데, 오늘은 이 셋을 제대로 한 번 정리해 보겠습니다.

개념 / 원리

세 도구는 한 줄로 요약하면 이렇습니다.

• top: 실시간 프로세스 모니터, 기본 탑재. 화면이 자동 갱신됩니다.
• htop: top의 개선판. 컬러, 트리 뷰, 마우스 조작 지원. 별도 설치 필요.
• ps: 특정 시점의 스냅샷. 갱신 안 됨. 스크립트나 파이프 친화적.

비유하자면 top/htop은 CCTV 화면을 띄워놓고 보는 거고, ps는 카메라로 사진 한 장 찰칵 찍는 겁니다. 장애 모니터링 중일 때는 CCTV, 다른 명령어와 조합해서 결과를 가공할 때는 사진 한 장이 필요한 거죠.

내부적으로 세 도구 모두 /proc/[PID]/ 디렉토리에서 정보를 읽어옵니다. 같은 원천에서 가져오지만, 보여주는 방식과 갱신 주기가 다른 거예요.

실전 예제

top

그냥 top을 치면 실시간 모니터 화면이 뜹니다. 자주 보는 컬럼은 PID, USER, %CPU, %MEM, VIRT, RES, S(상태)입니다.

top

화면을 띄운 상태에서 누를 수 있는 단축키가 핵심입니다.

P    CPU 사용률 순으로 정렬
M    메모리 사용률 순으로 정렬
1    CPU 코어별로 분리해서 표시
c    명령어를 full path로 표시
k    원하는 PID에 시그널 보내기 (kill)
W    현재 보기 설정을 ~/.toprc에 저장
q    종료

htop

설치하고 실행하면 top보다 훨씬 보기 편합니다.

sudo apt install htop    # 데비안 계열
sudo yum install htop    # RHEL 계열
htop

F5로 트리 뷰, F6으로 정렬 기준 변경, F9로 시그널 보내기. 부모-자식 프로세스 관계를 트리로 보고 싶을 때 정말 편합니다.

ps

스크립트에서 쓰거나 특정 정보만 골라보고 싶을 때 씁니다.

# 전체 프로세스 (BSD 스타일)
ps aux

# 전체 프로세스 (System V 스타일, PPID 포함)
ps -ef

# 원하는 컬럼만 골라보기 (메모리 많이 쓰는 순서)
ps -eo pid,ppid,user,%cpu,%mem,rss,vsz,comm --sort=-%mem | head -20

# 특정 PID의 메모리만
ps -o pid,rss,vsz,comm -p 12345

주의할 점

신입 때 헷갈리기 쉬운 포인트 몇 개를 정리해 두겠습니다.

첫째, top의 %CPU는 단일 코어 기준입니다. 8코어 서버에서 800%까지 가능하다는 뜻이에요. 코어별로 나눠서 보고 싶다면 1을 누르면 됩니다.

둘째, VIRT는 실제 메모리 사용량이 아닙니다. 가상 메모리 주소 공간이라서 실제 물리 메모리는 RES(=RSS)를 보셔야 합니다. JVM 같은 경우 VIRT가 수십 GB로 보여서 깜짝 놀라는 분들 많은데, 실제 사용은 RES로 판단하세요.

셋째, ps aux(BSD)와 ps -ef(System V)는 컬럼이 조금 다릅니다. aux는 %CPU, %MEM이 보이고, -ef는 PPID(부모 프로세스 ID)가 보입니다. 상황에 맞게 골라 쓰면 됩니다.

넷째, load average는 CPU 사용률이 아닙니다. 실행 가능 + 디스크 대기 중인 프로세스의 평균 개수입니다. 코어 수보다 높으면 부하가 있다고 보면 되고, 16코어 서버라면 16 이상부터 의심해 봅니다.

저는 예전에 RES와 VIRT를 헷갈려서 정상인 서버를 메모리 누수로 보고했다가 한참 망신당한 적이 있습니다. 작은 차이지만 운영 환경에서는 큰 차이가 납니다.

마무리

정리하면 세 줄입니다.

• 실시간 모니터링은 top/htop, 스냅샷·스크립트는 ps.
• 메모리는 VIRT가 아니라 RES, CPU는 코어 수 곱셈 주의.
• load average는 사용률이 아니라 실행 가능 프로세스 개수의 평균.