여기서는 멈추세요
- 명령 출력의 서버·서비스·경로가 예상 대상과 다르면 변경 단계로 넘어가지 않습니다.
- 현재 접속 세션, 백업 또는 콘솔 복구 경로를 확보하지 못했다면 상태 변경 명령을 실행하지 않습니다.
PERFORMANCE
서버 CPU 사용률이 계속 높을 때
로드 평균과 CPU 점유 프로세스를 구분하고 서비스 로그를 확인한 뒤 재시작 여부를 판단합니다.CPU 100%load averagetop프로세스 점유율서버 느림
환경Ubuntu · Debian · RHEL 계열
분류CPU·메모리
검토일2026-08-27
진행5단계 · 조회 우선
SAFE OPERATING BOUNDARY
중단·복구 기준부터 확인하세요
복구 기준
변경 전 설정과 출력값을 기록하고, 예상과 다른 결과가 나오면 추가 변경을 멈춘 뒤 승인된 운영 복구 절차로 되돌립니다.
담당자에게 전달할 자료
- 장애 발생 시각·정상화 시각과 원문 오류 메시지
- 민감정보를 제거한 조회 명령 출력과 변경 전후 차이
- 조치 후 동일 조건으로 수행한 재검증 결과
BEFORE YOU START
이런 증상에서 시작합니다
- 응답 지연
- SSH 입력 지연
- 로드 평균 상승
- 타임아웃 증가
CHECK THE BRANCH
놓치기 쉬운 원인 분기
한 코어만 포화된 경우
전체 CPU 백분율이 낮아 보여도 단일 스레드 프로세스가 한 코어를 모두 사용할 수 있으므로 스레드 단위 사용률을 확인합니다.
CPU보다 대기가 큰 경우
load average는 CPU 사용률 자체가 아닙니다. vmstat의 wa와 /proc/pressure/io를 함께 확인해 I/O 대기와 구분합니다.
가상 서버인 경우
vmstat의 st 값이 높으면 게스트 내부 프로세스보다 하이퍼바이저 CPU 경합 가능성을 별도로 검토합니다.
FOLLOW THE FLOW
순서대로 확인하기
조회시스템을 변경하지 않는 확인 단계
현재 부하와 지속 시간 확인
순간 피크인지 장시간 누적인지 먼저 구분합니다.
업타임과 load average
uptimeCPU·메모리 실시간 확인
top -o %CPU결과 읽기
load average를 CPU 코어 수와 함께 보고, top의 us·sy·wa 값을 구분합니다.
다음 판단
wa가 높으면 CPU가 아니라 디스크 I/O 문제일 수 있습니다.
조회시스템을 변경하지 않는 확인 단계
점유 프로세스 목록화
PID, 사용자, 실행 시간을 함께 확인합니다.
CPU 상위 20개
ps -eo pid,ppid,user,%cpu,%mem,stat,etime,comm --sort=-%cpu | head -20결과 읽기
짧게 끝나는 정상 배치인지 계속 유지되는 프로세스인지 봅니다.
다음 판단
PID와 서비스 이름을 기록합니다.
조회시스템을 변경하지 않는 확인 단계
서비스 상태와 직전 로그 확인
SERVICE_NAME을 실제 unit 이름으로 바꿉니다.
서비스 상태
systemctl status SERVICE_NAME --no-pager -l최근 15분 로그
journalctl -u SERVICE_NAME --since '-15 min' --no-pager결과 읽기
반복 오류, 무한 재시도, 요청 폭증 흔적을 찾습니다.
다음 판단
원인이 외부 트래픽인지 애플리케이션 내부인지 분리합니다.
주의서버 부하나 권한을 고려할 단계
프로세스 종료 전 영향 확인
kill -9부터 실행하지 않습니다. 자식 프로세스와 연결 상태를 먼저 확인합니다.
프로세스 트리
ps -ef --forest | less열린 연결 요약
sudo ss -s결과 읽기
정상 종료가 가능한 서비스라면 systemd를 통해 제어합니다.
다음 판단
장애 전파와 재기동 시간을 확인한 뒤 변경 단계로 이동합니다.
변경데이터·서비스 상태가 달라질 수 있는 단계
운영 절차에 따라 재시작하고 검증
SERVICE_NAME이 정확한지 재확인하고 이중화·점검 시간을 고려합니다.
변경 단계입니다. 실행 전 대상 이름과 경로, 서비스 중단 영향, 복구 방법을 다시 확인하세요.
서비스 재시작
sudo systemctl restart SERVICE_NAME재시작 후 상태
systemctl is-active SERVICE_NAME && uptime결과 읽기
active 상태와 load average 하락, 응답 시간 회복을 함께 확인합니다.
다음 판단
재발하면 프로파일링과 요청량·배치 주기 분석이 필요합니다.
PRIMARY REFERENCES
공식 문서
- procps-ng 공식 문서
- systemd systemctl 공식 매뉴얼
- systemd journalctl 공식 매뉴얼
- Linux Kernel — Pressure Stall Information
배포판과 버전에 따라 옵션·로그 위치가 다를 수 있습니다. 실행 전 서버의 --help와 로컬 매뉴얼을 함께 확인하세요.