리눅스 서버가 갑자기 느려졌을 때 가장 먼저 의심하는 것 중 하나가 CPU 사용률입니다.
서버가 버벅이거나, 접속이 느려지거나, 서비스 응답이 늦어질 때 top을 열어보면 특정 프로세스가 CPU를 많이 쓰고 있는 경우가 있습니다.
top이때 초보 운영자가 하기 쉬운 실수가 있습니다.
CPU 높은 프로세스를 보고 바로 kill 하는 것입니다.
물론 장애 상황에서는 빨리 조치하고 싶은 마음이 듭니다.
하지만 CPU 사용률이 높다고 무조건 문제가 되는 프로세스는 아닙니다. 배치 작업일 수도 있고, 정상적인 트래픽 처리 중일 수도 있고, 백업이나 로그 처리 작업일 수도 있습니다.
그래서 먼저 해야 할 일은 이겁니다.
CPU 높은 PID 확인
→ 어떤 프로세스인지 확인
→ 어떤 서비스인지 확인
→ 영향도 판단
→ 조치 여부 결정이번 글에서는 리눅스 서버에서 CPU 사용률이 높은 프로세스를 확인하는 기본 순서를 초보 운영자 눈높이로 정리해보겠습니다.
먼저 top으로 전체 CPU 상태 확인하기
가장 먼저 확인할 명령어는 top입니다.
top상단에는 서버 전체 CPU 상태가 나오고, 아래에는 프로세스 목록이 나옵니다.
예를 들어 이런 식입니다.
%Cpu(s): 85.0 us, 5.0 sy, 0.0 ni, 8.0 id, 2.0 wa여기서 초보자가 먼저 볼 값은 대략 아래입니다.
us = 사용자 프로세스가 사용하는 CPU
sy = 커널이 사용하는 CPU
id = idle, 놀고 있는 CPU
wa = I/O wait, 디스크 대기CPU가 높다고 해서 항상 같은 원인은 아닙니다.
us가 높으면 애플리케이션이나 사용자 프로세스 쪽을 의심할 수 있고,
wa가 높으면 CPU보다 디스크 I/O 대기 쪽을 봐야 할 수 있습니다.
이번 글에서는 특히 특정 프로세스가 CPU를 많이 쓰는 경우를 기준으로 정리하겠습니다.
top에서 CPU 높은 프로세스 보기
top 화면 아래쪽에는 프로세스 목록이 나옵니다.
보통 %CPU 기준으로 정렬되어 보입니다.
예시입니다.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1234 appuser 20 0 2500m 850m 120m R 98.7 10.8 12:33.21 java
2345 mysql 20 0 1800m 600m 80m S 35.2 7.6 5:20.10 mysqld
3456 root 20 0 500m 100m 30m S 5.0 1.2 0:40.00 nginx여기서 먼저 볼 것은 PID, %CPU, COMMAND입니다.
PID = 프로세스 번호
%CPU = CPU 사용률
COMMAND = 실행 명령 또는 프로세스 이름예를 들어 1234 PID의 java 프로세스가 CPU를 많이 쓰고 있다면, 이 PID가 어떤 서비스인지 더 확인해야 합니다.
여기서 바로 kill -9 1234를 치면 안 됩니다.
ps 명령어로 CPU 높은 프로세스 확인하기
top은 화면으로 보기 좋고, ps는 명령어 결과로 정리해서 보기 좋습니다.
CPU 사용률이 높은 프로세스를 확인하려면 아래 명령어를 사용할 수 있습니다.
ps -eo pid,ppid,user,cmd,%cpu,%mem --sort=-%cpu | head예시 결과입니다.
PID PPID USER CMD %CPU %MEM
1234 1 appuser java -jar app.jar 98.7 10.8
2345 1 mysql /usr/sbin/mysqld 35.2 7.6
3456 1 nginx nginx: worker process 5.0 1.2여기서 PID만 보는 게 아니라 PPID, USER, CMD도 같이 봐야 합니다.
PID = 현재 프로세스 ID
PPID = 부모 프로세스 ID
USER = 실행 계정
CMD = 실제 실행 명령특히 CMD를 보면 단순히 java인지, 어떤 jar를 실행 중인지, 어떤 옵션으로 실행됐는지 알 수 있습니다.
CPU 높은 PID를 찾았으면 서비스부터 확인하기
CPU 높은 PID를 찾았다면 다음은 이 PID가 어떤 서비스인지 확인해야 합니다.
먼저 상세 명령어를 봅니다.
ps -fp 1234예시입니다.
UID PID PPID C STIME TTY TIME CMD
appuser 1234 1 85 10:20 ? 00:12:33 java -jar /app/service/app.jar이렇게 보면 /app/service/app.jar를 실행 중인 Java 프로세스라는 것을 알 수 있습니다.
더 자세히 보고 싶다면 /proc 경로도 확인할 수 있습니다.
readlink -f /proc/1234/exe실행 경로는 아래처럼 볼 수 있습니다.
pwdx 1234예시입니다.
1234: /app/service이 정보를 보고 “이 PID가 어떤 서비스인지”를 먼저 파악해야 합니다.
다음 글에서는 이 부분을 더 자세히 다룰 예정입니다.
CPU 사용률이 높다고 무조건 장애는 아니다
CPU 사용률이 높게 보인다고 해서 무조건 문제가 되는 건 아닙니다.
예를 들어 이런 상황이 있습니다.
정상 배치 작업 수행 중
트래픽 증가로 요청 처리 중
백업이나 압축 작업 중
로그 분석 작업 실행 중
DB 쿼리 처리 중
배포 직후 캐시 생성 중이런 작업들은 순간적으로 CPU를 많이 사용할 수 있습니다.
그래서 CPU가 높을 때는 아래를 같이 확인해야 합니다.
언제부터 높아졌는지
계속 높은지, 순간적으로 높은지
어떤 계정으로 실행 중인지
어떤 서비스와 연결되는지
최근 배포나 작업이 있었는지
서비스 장애가 실제로 발생했는지숫자 하나만 보고 판단하면 위험합니다.
CPU가 계속 높은지 흐름 보기
한 번 찍은 CPU 사용률만 보고 판단하면 안 됩니다.
짧은 순간만 높았다가 내려갈 수도 있기 때문입니다.
top으로 몇 초 동안 흐름을 봅니다.
top또는 ps를 반복해서 볼 수도 있습니다.
watch -n 1 "ps -eo pid,ppid,user,cmd,%cpu,%mem --sort=-%cpu | head"운영 중에는 너무 오래 켜둘 필요는 없지만, 장애 확인 중에는 CPU가 계속 높은지, 특정 PID가 계속 상위에 있는지 보는 데 도움이 됩니다.
예를 들어:
같은 PID가 계속 90% 이상
→ 해당 프로세스 집중 확인
PID가 계속 바뀜
→ 여러 작업이 번갈아 CPU 사용 중일 수 있음
짧게 높았다가 내려감
→ 일시적 작업일 수 있음흐름을 보면 조치 방향이 달라집니다.
CPU 높은 프로세스가 Java라면
운영 서버에서 CPU 높은 프로세스가 java인 경우가 많습니다.
ps -eo pid,ppid,user,cmd,%cpu,%mem --sort=-%cpu | head예시입니다.
1234 appuser java -jar /app/service/app.jar 98.7 10.8이 경우 바로 kill하기보다 아래를 먼저 봅니다.
어떤 애플리케이션인지
배포 직후인지
트래픽이 증가했는지
로그에 에러가 반복되는지
스레드 덤프 확인이 필요한지
서비스 이중화가 되어 있는지Java 프로세스는 서비스 본체일 가능성이 높아서, 잘못 종료하면 바로 장애가 날 수 있습니다.
초보 운영자라면 단독 판단으로 kill하기보다 담당자 확인이나 절차를 따르는 게 안전합니다.
CPU 높은 프로세스가 DB라면
mysqld, postgres, mongod 같은 DB 프로세스가 CPU를 많이 쓰는 경우도 있습니다.
예시입니다.
2345 mysql /usr/sbin/mysqld 85.3 20.1DB 프로세스가 CPU를 많이 쓴다고 바로 종료하면 안 됩니다.
먼저 확인할 것은 아래입니다.
쿼리 증가 여부
슬로우 쿼리 여부
배치 작업 여부
접속 수 증가 여부
디스크 I/O 상태
락 대기 여부DB는 다른 서비스들이 의존하고 있는 경우가 많기 때문에, 조치 전 영향도 확인이 특히 중요합니다.
CPU 높은 프로세스가 압축이나 백업 작업이라면
가끔 gzip, tar, rsync, backup 같은 프로세스가 CPU를 많이 쓰는 경우도 있습니다.
예시입니다.
4567 root gzip large-log-file.log 95.0 0.5이 경우는 장애 프로세스라기보다 작업 프로세스일 수 있습니다.
확인할 것은 아래입니다.
정기 백업 시간인지
로그 압축 작업인지
수동 작업인지
디스크 사용량과 관련 있는지
서비스 영향이 있는지작업성 프로세스라면 무조건 죽이기보다, 작업 중단 시 영향과 재실행 가능 여부를 확인해야 합니다.
바로 kill 하기 전에 확인할 것
CPU가 높을 때 가장 위험한 명령 중 하나가 이것입니다.
kill -9 1234kill -9는 강제 종료입니다.
정상 종료 절차를 거치지 않고 프로세스를 죽이기 때문에 운영 서버에서는 조심해야 합니다.
바로 kill 하기 전에 최소한 아래는 확인합니다.
이 PID가 어떤 서비스인지
이중화가 되어 있는지
죽이면 사용자 영향이 있는지
자동 재기동되는 서비스인지
현재 장애가 실제로 발생 중인지
로그상 원인이 보이는지
담당자 확인이 필요한지가능하면 먼저 일반 종료 신호를 고려합니다.
kill 1234하지만 이것도 서비스 영향이 있을 수 있으니, 운영 환경에서는 절차를 따르는 것이 안전합니다.
운영 서버에서 확인하는 순서
CPU 사용률이 높은 프로세스를 발견했을 때는 저는 보통 아래 순서로 봅니다.
1. top으로 전체 CPU 상태 확인
2. CPU 높은 PID 확인
3. ps로 PID 상세 명령 확인
4. 실행 계정과 경로 확인
5. 어떤 서비스인지 확인
6. 로그와 최근 작업 이력 확인
7. 서비스 영향도 판단
8. 필요 시 조치명령어로 정리하면 아래와 같습니다.
topps -eo pid,ppid,user,cmd,%cpu,%mem --sort=-%cpu | headps -fp 1234pwdx 1234readlink -f /proc/1234/exe로그 확인 예시는 서비스 환경에 따라 다르지만, systemd 서비스라면 아래처럼 볼 수 있습니다.
journalctl -u 서비스명 -n 100 --no-pager이렇게 보면 단순히 “CPU 높은 PID”가 아니라, 실제로 어떤 서비스가 어떤 상태인지 방향을 잡을 수 있습니다.
실무 보고 예시
CPU 높은 프로세스를 확인한 상황이라면 이렇게 보고할 수 있습니다.
서버 CPU 사용률 확인 결과, 특정 PID의 CPU 사용률이 높게 확인되었습니다.
해당 PID의 실행 명령 및 서비스 연관성을 확인 중이며, 서비스 영향도 확인 후 조치 여부를 판단하겠습니다.특정 서비스로 확인됐다면:
CPU 사용률이 높은 PID는 app 서비스 프로세스로 확인되었습니다.
현재 서비스 응답 상태와 애플리케이션 로그를 함께 확인하고 있습니다.작업성 프로세스로 보인다면:
CPU 사용률이 높은 프로세스는 로그 압축 작업으로 확인됩니다.
작업 시간대 및 서비스 영향 여부를 확인 후 중단 필요성을 검토하겠습니다.이렇게 쓰면 “CPU 높아서 kill 하겠습니다”보다 훨씬 안전하고 실무적입니다.
정리
리눅스 서버에서 CPU 사용률이 높을 때는 먼저 어떤 프로세스가 CPU를 쓰는지 확인해야 합니다.
기본 명령어는 아래입니다.
topps -eo pid,ppid,user,cmd,%cpu,%mem --sort=-%cpu | headPID 상세 확인은 아래처럼 볼 수 있습니다.
ps -fp PID
pwdx PID
readlink -f /proc/PID/exe초보 운영자라면 이 문장만 기억해도 좋습니다.
CPU 높은 PID를 찾는 것보다, 그 PID가 어떤 서비스인지 확인하는 게 먼저다.CPU 문제도 결국 확인 → 판단 → 조치 순서가 중요합니다.
CPU 사용률이 높은 프로세스를 찾았다면, 바로 kill 하기보다 그 PID가 어떤 서비스와 연결되어 있는지 먼저 확인해야 합니다.
CPU 문제는 단순히 사용률 숫자만 보는 것이 아니라, 실행 계정, 프로세스 경로, 서비스 영향도, 최근 로그를 함께 봐야 안전하게 판단할 수 있습니다.
특정 PID가 어떤 서비스인지 확인하는 방법은 아래 글에서 이어서 볼 수 있습니다.
https://opsnote.tistory.com/46
리눅스 서버 특정 PID가 어떤 서비스인지 확인하는 법
리눅스 서버에서 CPU나 메모리 사용률이 높은 프로세스를 확인하다 보면 특정 PID가 눈에 들어올 때가 있습니다.top또는:ps -eo pid,ppid,user,cmd,%cpu,%mem --sort=-%cpu | head예를 들어 이런 식입니다.PID PPID US
opsnote.tistory.com
서버가 느릴 때 CPU, 메모리, 디스크 상태를 함께 정리하는 방법은 아래 글에서 볼 수 있습니다.
https://opsnote.tistory.com/47
리눅스 서버 느림 보고할 때 CPU, 메모리, 디스크 상태 정리하는 방법
리눅스 서버가 느려졌다는 이야기를 들으면 초보 운영자는 먼저 명령어부터 떠올리게 됩니다.topfree -mdf -huptime그런데 실제 운영에서는 명령어를 실행하는 것만큼 중요한 게 하나 더 있습니다.확
opsnote.tistory.com
리눅스 서버 장애 대응 전체 흐름은 아래 글에서 함께 보면 좋습니다.
https://opsnote.tistory.com/69
초보 운영자를 위한 리눅스 서버 장애 대응 순서 총정리
리눅스 서버를 운영하다 보면 어느 날 갑자기 이런 말을 듣게 됩니다.서버가 느립니다.접속이 안 됩니다.서비스가 안 뜹니다.디스크가 가득 찼습니다.로그가 계속 쌓입니다.재기동하면 될까요?
opsnote.tistory.com
'리눅스' 카테고리의 다른 글
| 리눅스 서버 느림 보고할 때 CPU, 메모리, 디스크 상태 정리하는 방법 (0) | 2026.06.24 |
|---|---|
| 리눅스 서버 특정 PID가 어떤 서비스인지 확인하는 법 (0) | 2026.06.23 |
| 리눅스 서버 메모리 used만 보면 판단이 틀리는 이유와 available 확인법 (0) | 2026.06.21 |
| 리눅스 서버 Swap 올라갔다고 바로 재기동하지 말고 확인하는 순서 (0) | 2026.06.20 |
| 리눅스 서버 CPU 낮다고 정상이라 하지 말고 top wa 값까지 확인하는 법 (0) | 2026.06.19 |