이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
ps top htop으로 Process 보기에서 붙잡아야 할 핵심 판단 기준은 무엇인가?process 관찰은 가장 싼 증거 수집이다라는 기준은 어떤 JVM/OS 신호로 확인되는가?- Java/Spring 코드에서
ps top htop으로 Process 보기판단 기준은 어떤 장애 신호로 드러나는가?
개요
이 문서의 주제는 ps top htop으로 Process 보기이다. Linux에서 Java process와 thread 상태를 ps, top, htop으로 보는 방법을 정리한다.
먼저 붙잡을 기준은 다음 문장이다. process 관찰은 가장 싼 증거 수집이다. ps와 top은 Java 코드 위치를 직접 말해 주지는 않지만, PID가 살아 있는지, 어떤 user로 실행되는지, CPU/RSS/thread 상태가 어떻게 변하는지 가장 빠르게 남긴다.
핵심 모델
- 판단 기준: process 관찰은 가장 싼 증거 수집이다.
ps는 특정 시점의 PID, user, parent, 실행 인자, 상태, CPU/RSS를 증거로 남긴다.top -H -p <pid>나htop은 process 안의 thread별 CPU 편중을 볼 때 유용하다.STAT의R,S,D,Z는 process가 실행 중인지, 대기 중인지, I/O에서 빠져나오지 못하는지 구분하게 해 준다.- Java RSS는 heap만이 아니라 metaspace, thread stack, direct buffer, mmap 영역을 포함한다.
- Process 관찰은 thread dump, GC log, Actuator metric을 찍기 전 대상 PID와 시간축을 고정하는 단계다.
문서별 핵심 구분
ps는 특정 시점의 process 정보를 안정적으로 남긴다.top -H는 thread 단위 CPU 변화를 관찰한다.- process 상태는 Java 로그보다 먼저 볼 수 있는 운영 증거다.
원리
Linux에서 Java 서버는 하나의 process로 보이고, 그 안에 여러 Java thread와 JVM 내부 thread가 함께 존재한다. 운영 중 첫 질문은 “내가 보고 있는 PID가 맞는가”이다.
ps는 snapshot을 남기는 데 강하다. 실행 user, parent process, command line, elapsed time을 보면 배포 직후 새 process인지, 오래 떠 있던 process인지, 기대한 JVM option으로 실행됐는지 확인할 수 있다.
top -H -p <pid>는 thread 단위 CPU 편중을 보는 데 강하다. 특정 thread가 CPU를 독점한다면 그 LWP id를 16진수로 바꿔 thread dump의 nid와 연결할 수 있다.
RSS와 %MEM은 heap 사용량과 다르다. Heap은 낮은데 RSS가 높으면 direct buffer, thread stack, mmap, native memory, glibc arena 같은 JVM 밖 메모리를 의심해야 한다.
Java/Spring 연결
- Spring Boot process의 command line에는 active profile, JVM option, agent, heap 설정이 드러난다.
top -H에서 높은 CPU를 쓰는 LWP는 thread dump의nid와 연결해 실제 Java stack으로 추적한다.- Actuator
process.cpu.usage,jvm.threads.live,jvm.memory.used는 OSps/top값과 같은 시각에 비교해야 한다. - RSS가 heap보다 크면 Spring bean leak보다 먼저 direct buffer, thread stack, native memory 가능성을 열어 둔다.
- Process가 살아 있어도 request thread가 모두 blocking이면 health endpoint도 늦거나 실패할 수 있다.
- Spring 코드 리뷰에서는
ps top htop으로 Process 보기판단 기준이 어떤 thread, pool, timeout, resource 설정으로 드러나는지 확인한다.
코드와 설정 예시
date -Is
ps -o pid,ppid,user,stat,pcpu,pmem,etime,args -p <pid>
top -H -p <pid>예시는 PID와 시각을 먼저 고정한 뒤 process snapshot과 thread별 CPU를 같이 보는 흐름이다. top -H에서 튀는 thread id는 thread dump의 nid와 맞춰 Java stack까지 추적한다.
관찰 명령
ps -ef | grep java
ps -o pid,ppid,user,stat,pcpu,pmem,etime,args -p <pid>
top -H -p <pid>ps top htop으로 Process 보기 관찰 명령은 결론이 아니라 가설 확인 도구다. 운영 중에는 반복 간격, 대상 PID, 수집 시각을 함께 남기고 출력이 큰 명령은 범위를 제한한다.
지표 해석
| 신호 | 먼저 의심할 것 | 다음 확인 |
|---|---|---|
STAT=R과 CPU 높음 | CPU bound, busy loop | top -H, thread dump |
STAT=D 증가 | uninterruptible I/O wait | disk/NFS 상태, iostat |
| RSS 증가, heap 낮음 | native/direct/thread stack 증가 | NMT, direct buffer, thread 수 |
ETIME 짧고 PID 반복 변경 | crash loop, restart 반복 | systemd/journalctl |
ps top htop으로 Process 보기에서는 핵심 신호와 보조 지표를 같은 시간축에서 맞춘다. 먼저 변한 신호와 뒤따라 포화된 신호를 분리해야 원인과 결과를 구분할 수 있다.
장애 상황에서 보는 순서
- 장애 대상 host에서 실제 Java PID와 command line을 확인한다.
ps로 user, STAT,%CPU,%MEM, RSS, elapsed time을 남긴다.top -H -p <pid>로 thread별 CPU 편중을 확인한다.- CPU가 튀는 LWP id를 thread dump의
nid와 연결한다. - RSS나 thread 수가 이상하면 JVM heap, native memory, FD/socket 지표로 확장한다.
이 순서는 ps top htop으로 Process 보기 후보를 빠르게 좁히기 위한 기본 루틴이다. 결론을 내리기 전에는 애플리케이션 증거와 JVM/OS 증거를 최소 한 번 이상 맞춘다.
실전 팁
ps출력에는 PID뿐 아니라 PPID, user, STAT, elapsed time, args를 같이 남긴다.top -H에서 튄 thread는 10진수 LWP id를 16진수로 바꿔 thread dump와 맞춘다.- RSS가 높다고 heap leak으로 바로 결론내지 말고 JVM 밖 메모리 가능성을 남긴다.
- PID가 자주 바뀌면 현재 process의 증상만 보지 말고 restart 이력을 확인한다.
- 장애 회고에는 “어떤 PID를 봤는지”와 “그 PID가 언제부터 떠 있었는지”를 남긴다.
주니어 팁
ps한 줄을 볼 때 PID, user, STAT, CPU, RSS가 각각 무엇을 증명하는지 분리해 읽는다.top에서 본 thread id가 Java thread dump의nid와 연결된다는 점을 익힌다.%MEM과 heap used가 다를 수 있다는 사실을 기억한다.
시니어 팁
- Process 관찰 runbook은 PID 확인, thread CPU 매핑, RSS/heap 분리까지 한 흐름으로 둔다.
- Container 환경에서는 host
top의 CPU와 container quota 기준 CPU를 구분해 해석한다. - Alert에는 process 재시작, thread 수 급증, RSS 증가, CPU 편중처럼 JVM 전 증거를 포함한다.
Guru급 팁
ps top htop으로 Process 보기주제는 단일 snapshot보다 변화 방향이 중요하다. 같은 명령을 간격을 두고 실행해 상태가 증가, 유지, 회복 중 어디인지 본다.- 고급 도구는
ps top htop으로 Process 보기가설을 좁힐 때만 사용하고 기본 지표와 모순되는지 먼저 확인한다. ps top htop으로 Process 보기조치 후에는 CPU, memory, socket, disk, pool 중 다음 포화 지점이 어디로 이동했는지 확인한다.
위험 신호!
- PID를 확인하지 않은 상태에서 thread dump나 kill 명령을 실행한다.
%CPU만 보고 어떤 Java thread가 쓰는지nid매핑을 하지 않는다.- RSS 증가를 heap leak으로 단정하고 native/direct memory 가능성을 지운다.
- PID가 바뀐 사실을 놓쳐 crash loop를 정상 process로 오해한다.
- Process snapshot 없이 로그만 보고 장애 타임라인을 만든다.
확인 질문
확인 질문
- 장애 중 가장 먼저 PID와 command line을 확인하는 이유는 무엇인가?
- 이후 thread dump, JFR, log, socket, FD 지표를 모두 같은 process에 연결해야 하기 때문이다.
top -H에서 CPU가 높은 thread를 Java 코드와 연결하려면 무엇을 해야 하는가?
- LWP id를 16진수로 변환해 thread dump의
nid와 맞춘 뒤 해당 Java stack을 읽어야 한다.- RSS가 증가했는데 heap 사용량은 낮다면 무엇을 의심해야 하는가?
- Direct buffer, thread stack, metaspace, mmap, native allocation처럼 JVM heap 밖 메모리를 의심해야 한다.