• 느려짐 원인은 대부분 CPU / 메모리(swap) / 디스크 I/O / 프로세스 폭주 중 하나다.
• Load는 CPU 사용률이 아니라 “밀린 작업량”이다.
• wa(iowait)가 높으면 CPU 문제가 아니라 디스크 병목일 가능성이 크다.
• swap이 증가하면 체감 성능은 급격히 나빠진다.
• top → htop → 원인별 1개 명령 추가 확인이면 대부분 10분 안에 범위를 좁힐 수 있다.

1️⃣ 문제 상황

어느 날 갑자기 이런 연락이 옵니다.

• “사이트가 너무 느려요.”
• “SSH는 되는데 명령이 버벅여요.”
• “DB 쿼리가 갑자기 지연됩니다.”

이때 제 머릿속에 가장 먼저 뜨는 후보는 네 가지입니다.

1. CPU 과부하
2. 메모리 부족(swap)
3. 디스크 I/O 병목
4. 프로세스 폭주

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 상태를 먼저 보는 습관이
장애 대응 속도를 가장 빠르게 올려줍니다.

게시물 서버가 갑자기 느려질 때: TOP/HTOP로 10분 안에 범위 좁히는 방법이 하우인포-IT·테크에 처음 등장했습니다.