0️⃣ 5줄 요약 (운영 관점)
- 느려짐 원인은 대부분 CPU / 메모리(swap) / 디스크 I/O / 프로세스 폭주 중 하나다.
- Load는 CPU 사용률이 아니라 “밀린 작업량”이다.
- wa(iowait)가 높으면 CPU 문제가 아니라 디스크 병목일 가능성이 크다.
- swap이 증가하면 체감 성능은 급격히 나빠진다.
- top → htop → 원인별 1개 명령 추가 확인이면 대부분 10분 안에 범위를 좁힐 수 있다.
1️⃣ 문제 상황
어느 날 갑자기 이런 연락이 옵니다.
- “사이트가 너무 느려요.”
- “SSH는 되는데 명령이 버벅여요.”
- “DB 쿼리가 갑자기 지연됩니다.”
이때 제 머릿속에 가장 먼저 뜨는 후보는 네 가지입니다.
- CPU 과부하
- 메모리 부족(swap)
- 디스크 I/O 병목
- 프로세스 폭주
2️⃣ 내 환경 (예시 기준)
- Ubuntu 22.04
- 4 vCPU / 8GB RAM
- Nginx + PHP-FPM + MariaDB
- Docker 일부 사용
※ 코어 수에 따라 Load 해석이 달라지므로 환경은 항상 먼저 확인합니다.
nproc
3️⃣ 1차 가설
처음엔 대부분 “CPU가 문제인가?”부터 의심합니다.
하지만 경험상 절반 이상은 CPU가 아니었습니다.
특히:
- Load 높음 + CPU idle 많음 → 디스크 병목
- 체감 심한 느려짐 + swap 증가 → 메모리 압박
그래서 1차 스냅샷은 반드시 OS 레벨에서 봅니다.
4️⃣ 1분 스캔: top으로 상태 스냅샷
top
1️⃣ Load average
Load는 CPU 사용률이 아닙니다.
“대기 중인 작업 수”에 가깝습니다.
4코어 서버 기준:
- 0~4 → 정상 범위
- 6~10 → 병목 의심
- 10 이상 → 거의 확실히 무언가 막힘
2️⃣ CPU 라인 해석
- id 낮고 us 높음 → 연산/쿼리/압축 등 CPU 사용
- sy 높음 → 커널/네트워크/컨텍스트 스위칭
- wa 높음 → 디스크 기다리는 중 (I/O 병목)
⚠ wa가 15~20% 이상이면 디스크 문제 가능성 높음
3️⃣ 메모리 / Swap
- Swap 사용 증가 = 체감 성능 급락 시작
- RAM 사용률만 보고 판단하면 안 됨
5️⃣ 3분: htop으로 범인 찾기
htop
- F6 → CPU% 정렬
- F6 → MEM% 정렬
- 필요 시 “Show threads” 활성화
확인 포인트:
- 특정 프로세스가 계속 튀는가?
- 같은 서비스가 여러 개 과도하게 생성되는가?
- 사용자 계정이 예상과 다른가?
6️⃣ 원인별 다음 확인 (한 번만 더 본다)
① CPU 과부하 (us/sy 높음)
ps -eo pid,user,ppid,cmd,%cpu,%mem --sort=-%cpu | head
확인:
- 배치 작업인가?
- 쿼리 폭주인가?
- 무한 루프인가?
운영 팁:
재시작은 임시 해결일 뿐.
로그를 먼저 확인해야 재발 방지 가능.
② 메모리 부족 (swap 증가)
free -h
확인:
- swap 사용량
- 캐시 vs 실제 사용 메모리
운영 팁:
- 도커 메모리 제한 설정 점검
- 자바/DB 힙 설정 확인
- OOM 로그 확인
dmesg | grep -i oom
③ 디스크 I/O 병목 (wa 높음)
df -h
90% 이상이면 위험 구간.
sudo du -h -d 1 /var | sort -h | tail
로그/도커 파일 폭증 확인.
가능하면:
iostat -xz 1 3
I/O wait가 높고 await 값이 크면 디스크 병목.
운영 경험상:
- /var/log 폭증
- Docker json 로그 무제한 증가
- 백업 파일 미정리
이 세 가지가 단골입니다.
④ 프로세스 폭주 / 좀비
ps -eLf | wc -l
좀비 프로세스:
ps aux | awk '$8 ~ /Z/ { print }'
systemd 실패 확인:
systemctl --failed
크래시 루프는 CPU보다 더 체감 성능을 떨어뜨립니다.
7️⃣ 실제 원인 패턴 (운영 경험)
제가 겪은 실제 비율 체감:
- 디스크 I/O 병목: 35%
- 메모리(swap) 문제: 30%
- CPU 과부하: 20%
- 프로세스/크래시 루프: 15%
의외로 CPU는 가장 흔한 원인이 아니었습니다.
8️⃣ 해결 후 반드시 하는 것 (재발 방지)
✔ 로그 보존 및 원인 기록
✔ swap 사용률 모니터링 추가
✔ 디스크 80% 이상 알림 설정
✔ Docker 로그 제한 설정
✔ 주기적 용량 점검 자동화
임시 재시작만 하고 끝내면, 같은 장애가 반복됩니다.
9️⃣ 10분 진단 루틴 정리
1️⃣ top → Load / id / wa / swap
2️⃣ htop → CPU% / MEM% 정렬
3️⃣ 원인별 명령 1개만 추가
4️⃣ 임시 조치 + 로그 확인
5️⃣ 재발 방지 설정
🔟 자주 하는 실수
- Load만 보고 CPU 문제로 단정
- wa를 안 보고 CPU%만 보는 실수
- swap 증가를 정상으로 넘김
- 디스크 95%인데 방치
- 재시작만 하고 원인 기록 안 남김
📌 교훈
느려짐은 대부분 “OS 자원 병목”입니다.
애플리케이션부터 의심하기보다,
커널이 관리하는 CPU/메모리/I/O 상태를 먼저 보는 습관이
장애 대응 속도를 가장 빠르게 올려줍니다.
