PID가 핵심
모든 프로세스에는 고유 번호(PID)가 있습니다. 종료하거나 상세를 확인할 때 이 번호로 지정합니다. ps 출력의 두 번째 열이 대개 PID입니다.
이 파트에서 다루는 내용
프로세스 확인프로세스 종료CPU와 메모리디스크 점검
01
무엇이 실행 중인지부터 확인합니다
서버 문제의 첫 질문은 항상 같습니다. 지금 무엇이 돌고 있는가입니다. 애플리케이션이 떠 있는지, 예상보다 많은 프로세스가 있는지, 무엇이 자원을 쓰는지 확인하는 것이 진단의 시작입니다.
프로세스를 보는 도구는 두 가지입니다. 한 순간을 찍어 보는 ps 와, 실시간으로 지켜보는 top 입니다.
grep 으로 좁히기
ps 출력은 수십, 수백 줄입니다. Part 2에서 배운 grep 으로 찾는 프로그램만 걸러 봅니다. 도구가 이렇게 이어집니다.
grep 자기 자신
ps -ef | grep java 를 하면 grep 명령 자체도 결과에 나옵니다. 프로세스가 하나 더 있는 것처럼 보여 헷갈립니다. 실제 대상만 세어야 합니다.
ps -ef실행 중인 모든 프로세스를 한 번에 출력ps -ef | grep java특정 프로그램의 프로세스만 걸러 보기topCPU·메모리를 실시간으로 확인. q 로 종료top -o %MEM메모리 사용량 순으로 정렬해 보기pgrep -f app.jar조건에 맞는 프로세스의 PID만 출력02
프로세스를 멈추는 데도 순서가 있습니다
멈추지 않는 프로세스를 종료할 때, 처음부터 강제 종료하지 않습니다. 정상적으로 마칠 기회를 먼저 주고, 안 되면 그때 강제합니다.
강제 종료는 처리 중이던 작업을 중간에 끊습니다. 데이터가 어중간하게 남을 수 있어 마지막 수단으로 씁니다.
먼저 kill, 안 되면 kill -9
기본 kill 은 종료 신호를 보내 정상적으로 마치게 합니다. 응답이 없을 때만 -9 로 강제합니다. 처음부터 -9 를 쓰는 습관은 위험합니다.
pkill 은 범위 주의
이름 조건에 맞는 프로세스를 모두 종료합니다. 조건이 넓으면 의도치 않은 프로세스까지 끊깁니다. pgrep 으로 대상을 먼저 확인한 뒤 실행합니다.
종료가 근본 해결은 아님
강제 종료로 급한 불은 끄지만, 왜 멈췄는지는 로그로 확인해야 재발을 막습니다. 트랙 C에서 다룹니다.
kill <PID>정상 종료 요청. 프로세스가 마무리할 기회를 줌kill -9 <PID>강제 종료. 마무리 없이 즉시 중단pkill -f app.jar이름으로 찾아 종료. 대상 확인 필수kill -l보낼 수 있는 신호 목록 확인03
느려질 때는 CPU와 메모리를 봅니다
서버가 느리다는 신고가 들어오면 무엇이 자원을 소진하는지 확인합니다. CPU를 오래 점유하는 프로세스인지, 메모리가 부족한지에 따라 대응이 다릅니다.
메모리 부족의 신호
free 로 남은 메모리가 거의 없고 swap 사용이 늘고 있다면 메모리 부족입니다. 심하면 시스템이 프로세스를 강제로 종료합니다. 로그에 그 흔적이 남습니다.
부하 평균 읽기
uptime 이 보여 주는 세 숫자는 1분·5분·15분 평균 부하입니다. CPU 코어 수보다 지속적으로 높으면 처리량이 밀리고 있다는 뜻입니다.
자바 애플리케이션
자바 프로세스가 메모리를 많이 쓰는 것은 정상일 수 있습니다. 다만 계속 늘어난다면 누수를 의심합니다. 컨테이너 환경에서는 메모리 한도 설정도 함께 확인합니다.
topCPU·메모리 사용 상위 프로세스 실시간 확인free -h전체 메모리와 남은 양을 사람이 읽기 쉽게 표시uptime부하 평균(load average)으로 최근 혼잡도 확인ps -eo pid,ppid,%cpu,%mem,cmd --sort=-%mem | head메모리 사용 상위 프로세스 정렬04
디스크가 차면 갑자기 여러 곳이 멈춥니다
디스크가 가득 차면 로그를 못 쓰고, 임시 파일을 못 만들고, DB가 멈춥니다. 원인이 여러 곳에서 동시에 터지는 것처럼 보여 진단이 어렵습니다. 그래서 서버가 이상하면 디스크부터 확인하는 것이 좋은 습관입니다.
df 로 어느 디스크인지
먼저 df 로 어느 파일시스템이 찼는지 봅니다. 사용률 100%에 가까운 곳이 범인입니다. 여러 디스크가 있으면 엉뚱한 곳을 뒤지지 않게 이것부터 봅니다.
du 로 범인 찾기
찬 디스크 안에서 du 로 어느 디렉터리가 큰지 좁혀 갑니다. 위에서부터 하나씩 내려가며 용량이 큰 쪽을 따라갑니다.
로그가 흔한 원인
로테이션 설정이 없거나 잘못된 로그가 디스크를 채우는 경우가 가장 많습니다. Docker 코스와 Spring Boot 코스에서 다룬 로그 관리와 이어집니다.
삭제 전 확인
용량을 차지하는 파일을 지우기 전에 무엇인지 확인합니다. 사용 중인 로그나 데이터를 지우면 더 큰 문제가 됩니다. 특히 삭제된 파일을 프로세스가 붙들고 있으면 공간이 바로 돌아오지 않습니다.
df -h파일시스템별 사용량과 남은 공간 확인. 가장 먼저du -sh *현재 위치 각 항목의 크기 확인du -sh /var/log/*특정 디렉터리 안에서 용량 차지 대상 찾기find / -size +500M 2>/dev/null500MB 넘는 큰 파일 찾기 (트랙 A find 활용)진단 순서
서버가 이상하면 세 가지를 순서대로 봅니다. 무엇이 도는가(ps·top), 메모리는 충분한가(free), 디스크는 남았는가(df). 이 세 명령이 서버 문제 대부분의 출발점입니다. 원인을 찾은 뒤에야 종료나 정리 같은 조치를 합니다.
체크