리눅스 서버가 느린데 CPU는 낮을 때 Load Average와 wa로 확인하는 실제 점검 흐름

LOAD CHECK CPU 낮은데 서버가 느릴 때 Load Average → wa → 로그 확인

 

리눅스 서버를 운영하다 보면 이런 말을 들을 때가 있습니다.

서버가 느립니다.
화면이 늦게 뜹니다.
요청 응답이 평소보다 오래 걸립니다.

처음에는 CPU부터 보게 됩니다.

top을 열어봤는데 CPU 사용률이 생각보다 높지 않습니다.
그러면 초보 운영자 입장에서는 이런 생각이 들 수 있습니다.

CPU는 낮은데 왜 서버가 느리지?
서버 문제는 아닌가?
애플리케이션 문제인가?
그냥 일시적인 현상인가?

저도 처음에는 CPU 사용률만 보고 판단하려고 했습니다.
그런데 운영 서버에서는 CPU 사용률이 낮아 보여도 서버가 느릴 수 있습니다.

이럴 때 같이 봐야 하는 것이 Load Average와 wa입니다.

Load Average는 서버에 얼마나 많은 작업이 밀려 있는지 보는 데 도움이 됩니다.
wa는 CPU가 일을 못 해서 노는 것이 아니라, 디스크나 스토리지 응답을 기다리는 상황인지 확인할 때 도움이 됩니다.

이번 글에서는 리눅스 서버가 느린데 CPU 사용률은 낮아 보일 때, Load Average와 wa를 이용해서 원인을 좁혀가는 실제 점검 흐름을 정리해보겠습니다.

핵심은 단순합니다.

CPU가 낮다고 서버가 정상인 것은 아닙니다.

운영 서버에서는 항상 확인 → 판단 → 조치 → 재확인 순서가 먼저입니다.

---

1. 먼저 “서버가 느리다”를 나눠서 봅니다

“서버가 느리다”는 말은 생각보다 넓습니다.

느리다는 표현 안에는 여러 상황이 섞여 있을 수 있습니다.

• 웹 화면이 늦게 뜸
• API 응답이 늦음
• SSH 접속이 느림
• 명령어 실행이 느림
• 배치 작업이 오래 걸림
• 파일 읽기나 쓰기가 느림
• 특정 시간대에만 느림
• 특정 서비스만 느림
• 서버 전체가 느림

이 상황들은 모두 비슷하게 들리지만 확인 방향이 다를 수 있습니다.

그래서 처음에는 이렇게 나눠야 합니다.

서버가 느리다.
그러면 CPU 문제인지, 메모리 문제인지, 디스크 I/O 문제인지, 서비스 문제인지 나눠서 본다.

여기서 바로 재기동부터 하면 안 됩니다.

서버가 느린 원인은 CPU 사용률 하나로 결정되지 않습니다.
Load Average, wa, 메모리, Swap, 디스크 사용률, 로그, 프로세스 상태를 함께 봐야 합니다.

---

2. uptime으로 Load Average를 먼저 봅니다

서버가 느릴 때 가볍게 먼저 볼 수 있는 명령어는 uptime입니다.

uptime

결과에는 현재 시간, 서버 부팅 후 경과 시간, 로그인 사용자 수, Load Average가 나옵니다.

예를 들어 이런 식입니다.

load average: 4.20, 5.10, 4.80

Load Average는 보통 1분, 5분, 15분 평균으로 표시됩니다.

여기서 중요한 것은 숫자 하나만 보고 바로 장애라고 판단하지 않는 것입니다.

Load Average는 CPU 코어 수와 함께 봐야 합니다.

예를 들어 CPU가 1코어인 서버에서 Load Average가 4라면 꽤 높은 상태일 수 있습니다.
하지만 CPU가 8코어인 서버에서 Load Average가 4라면 상대적으로 여유가 있을 수도 있습니다.

CPU 코어 수는 아래처럼 확인할 수 있습니다.

nproc

또는 이렇게 볼 수도 있습니다.

lscpu

초보 운영자라면 이 문장만 기억해도 좋습니다.

Load Average는 숫자만 보지 말고 CPU 코어 수와 함께 봐야 합니다.

Load Average를 보는 기본 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/41

리눅스 서버 CPU 낮다고 정상이라 하지 말고 Load Average까지 확인하는 법

 

---

3. CPU 사용률이 낮아도 Load Average가 높을 수 있습니다

처음에는 이 부분이 가장 헷갈립니다.

CPU 사용률이 낮아 보이는데 Load Average가 높을 수 있습니다.

그 이유는 Load Average가 단순히 CPU 사용률만 의미하지 않기 때문입니다.

리눅스에서 Load Average는 실행 중이거나 실행을 기다리는 작업, 그리고 일부 대기 상태의 작업까지 영향을 받을 수 있습니다.

즉, CPU가 바빠서 높은 경우도 있지만, 디스크나 스토리지 응답을 기다리는 작업이 많아도 높게 보일 수 있습니다.

예를 들어 이런 상황입니다.

CPU 사용률은 낮음
Load Average는 높음
서버는 느림
명령어 실행도 늦음

이 경우에는 CPU만 보고 “정상”이라고 판단하면 안 됩니다.

이제 다음으로 봐야 할 것은 top의 wa 값입니다.

---

4. top에서 wa 값을 확인합니다

서버가 느릴 때는 top을 자주 봅니다.

top

top 화면 상단에는 CPU 사용률이 항목별로 표시됩니다.

그중에서 wa를 봐야 합니다.

wa는 I/O wait을 의미합니다.
쉽게 말하면 CPU가 디스크나 스토리지 응답을 기다리는 시간입니다.

예를 들어 이런 식으로 보일 수 있습니다.

%Cpu(s):  3.0 us,  1.0 sy,  0.0 ni, 70.0 id, 25.0 wa

여기서 id는 idle, 즉 CPU가 쉬는 비율입니다.
wa는 I/O wait입니다.

CPU 사용률이 낮아 보이는데 wa가 높다면, CPU가 일을 못 해서 노는 것이 아니라 디스크나 스토리지 응답을 기다리고 있을 수 있습니다.

이때는 이렇게 생각해야 합니다.

CPU가 낮다.
그런데 wa가 높다.
그러면 디스크 I/O나 스토리지 지연을 의심한다.

top에서 wa 값을 보는 방법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/42

리눅스 서버 CPU 낮다고 정상이라 하지 말고 top wa 값까지 확인하는 법

 

---

5. wa가 높다고 바로 디스크 장애로 단정하지 않습니다

여기서도 바로 결론을 내리면 안 됩니다.

wa가 높다고 해서 무조건 디스크 장애라는 뜻은 아닙니다.

아래 상황에서도 wa가 높게 보일 수 있습니다.

• 대용량 로그 쓰기
• 백업 작업
• 압축 또는 해제 작업
• DB 디스크 I/O 증가
• 스토리지 지연
• NFS나 NAS 응답 지연
• 과도한 파일 읽기/쓰기
• 특정 프로세스의 I/O 집중

그래서 wa가 높다면 먼저 어떤 작업이 디스크를 많이 쓰는지 확인해야 합니다.

가능하면 iostat을 사용해서 디스크 I/O 상태를 봅니다.

iostat -x 1 3

만약 iostat이 없다면 프로세스 상태와 로그, 디스크 사용률부터 확인합니다.

ps -eo pid,stat,cmd | grep ' D '

D 상태는 보통 uninterruptible sleep 상태로, I/O 대기와 관련된 힌트가 될 수 있습니다.

단, 이 결과도 단독으로 판단하면 안 됩니다.
어떤 프로세스가 어떤 파일이나 장치에서 대기 중인지 추가 확인이 필요합니다.

---

6. 디스크 용량과 inode도 같이 봅니다

서버가 느릴 때 디스크 I/O만 볼 것이 아니라 디스크 사용률도 함께 봐야 합니다.

디스크가 꽉 찼거나, inode가 부족하면 서비스가 느려지거나 파일 생성에 실패할 수 있습니다.

먼저 전체 사용률을 봅니다.

df -h

그리고 inode도 봅니다.

df -i

디스크가 90% 이상 찼다면 로그 증가, 임시 파일 증가, 백업 파일 증가, 업로드 파일 증가를 확인해야 합니다.

용량이 남아 있어도 inode가 부족하면 새 파일을 만들지 못할 수 있습니다.

디스크 용량 문제를 전체 순서로 보고 싶다면 아래 글을 함께 보면 좋습니다.

https://opsnote.tistory.com/70

리눅스 서버 디스크 용량 문제 확인 순서 총정리

 

디스크 용량 90% 알림을 받았을 때 실제 점검 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/72

리눅스 서버 디스크 용량 90% 알림을 받았을 때 실제 점검 흐름 정리

 

---

7. 메모리와 Swap도 함께 확인합니다

서버가 느릴 때 CPU와 디스크만 보면 부족합니다.

메모리 상태도 함께 봐야 합니다.

free -m

여기서 used만 보면 안 됩니다.

available, buff/cache, Swap을 같이 봐야 합니다.

메모리가 부족해서 Swap 사용량이 늘어나면 서버 응답이 느려질 수 있습니다.
특히 디스크 I/O가 느린 환경에서 Swap까지 많이 쓰면 체감 성능이 크게 떨어질 수 있습니다.

Swap 사용량도 확인합니다.

free -m

또는 top에서도 Swap 사용량을 볼 수 있습니다.

메모리 확인 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/44

리눅스 서버 메모리 used만 보면 판단이 틀리는 이유와 available 확인법

 

Swap 사용량이 올라갔을 때 바로 재기동하지 말고 확인하는 순서는 아래 글에서 볼 수 있습니다.

https://opsnote.tistory.com/43

리눅스 서버 Swap 올라갔다고 바로 재기동하지 말고 확인하는 순서

 

---

8. 어떤 프로세스가 영향을 주는지 봅니다

Load Average가 높거나 wa가 높다면 어떤 프로세스가 영향을 주는지 봐야 합니다.

CPU를 많이 쓰는 프로세스는 top에서 바로 보일 수 있습니다.

메모리를 많이 쓰는 프로세스는 아래처럼 볼 수 있습니다.

ps aux --sort=-%mem | head

CPU 사용률 기준으로 보고 싶다면 아래처럼 볼 수 있습니다.

ps aux --sort=-%cpu | head

특정 PID가 의심된다면 그 PID가 어떤 서비스와 연결되어 있는지도 봐야 합니다.

ps -fp PID

ls -l /proc/PID/exe

cat /proc/PID/cmdline

CPU 사용률이 높은 PID를 찾고 서비스 영향도를 확인하는 방법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/45

리눅스 서버 CPU 100% 알림 떴을 때, 재기동 전 범인(PID)부터 찾는 법

 

특정 PID가 어떤 서비스인지 확인하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/46

리눅스 서버 특정 PID가 어떤 서비스인지 확인하는 법

 

---

9. 로그에서 같은 시간대의 오류를 확인합니다

서버가 느릴 때는 리소스 수치만 보는 것으로 끝내면 안 됩니다.

같은 시간대에 로그가 어떻게 찍혔는지도 봐야 합니다.

서비스 로그를 확인합니다.

journalctl -u 서비스명 -n 100 --no-pager

애플리케이션 로그가 있다면 최근 로그를 봅니다.

tail -n 100 /var/log/example-app/app.log

에러만 좁혀서 볼 수도 있습니다.

grep -i -E "error|exception|timeout|fail" /var/log/example-app/app.log

서버가 느려지는 시간대에 timeout, DB connection error, disk error, permission error 같은 로그가 반복된다면 리소스 수치와 함께 봐야 합니다.

로그 확인은 결국 장애 원인을 좁히는 과정입니다.

로그를 안전하게 보는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/20

리눅스 서버 로그 확인할 때 cat부터 치지 말고 tail과 less로 안전하게 보는 법

 

실시간 로그 확인이 필요하다면 아래 글도 함께 보면 좋습니다.

https://opsnote.tistory.com/21

리눅스 서버 장애 났을 때 tail -f로 실시간 로그 확인하는 법

 

---

10. 조치 전에 영향도를 먼저 정리합니다

서버가 느리다고 해서 바로 재기동하거나 프로세스를 종료하면 안 됩니다.

특히 운영 서버에서는 아래 조치가 모두 영향이 있을 수 있습니다.

• 서비스 restart
• 서버 reboot
• 프로세스 kill
• 로그 삭제
• 디스크 정리
• DB 재기동
• 스토리지 마운트 변경
• 백업 작업 중단

조치 전에는 최소한 아래 내용을 정리하는 것이 좋습니다.

확인된 사실:
Load Average, CPU, wa, 메모리, Swap, 디스크, 로그 상태

추정 원인:
CPU 사용 증가, I/O wait 증가, 메모리 부족, Swap 사용, 로그 폭증, 특정 프로세스 문제

조치 계획:
서비스 재기동, 프로세스 확인, 로그 정리, 백업 작업 조정, 담당자 확인

영향 범위:
접속 사용자, 배치 작업, 데이터 처리, 서비스 중단 가능성

원복 방법:
변경 전 상태, 설정 백업, 조치 전 수치, 서비스 재기동 전 로그

운영 서버에서는 빠른 조치보다 안전한 조치가 중요합니다.

---

11. 조치 후에는 다시 같은 지표를 확인합니다

조치가 끝났다면 다시 확인해야 합니다.

처음 봤던 지표를 다시 봅니다.

uptime

top

df -h

free -m

journalctl -u 서비스명 -n 100 --no-pager

조치 후에는 아래를 봅니다.

• Load Average가 내려가는가?
• wa 값이 줄어드는가?
• 메모리 available이 충분한가?
• Swap 사용량이 계속 증가하지 않는가?
• 디스크 사용률이 안정적인가?
• 같은 오류 로그가 반복되지 않는가?
• 사용자가 체감하는 응답이 회복됐는가?

서버 느림 문제는 조치보다 재확인이 더 중요할 때가 많습니다.

---

12. 보고는 숫자와 해석을 함께 남깁니다

서버가 느렸다는 보고는 단순히 “느렸습니다”라고 쓰면 부족합니다.

숫자와 해석을 함께 남기는 것이 좋습니다.

예시는 이렇게 정리할 수 있습니다.

[현상]
웹 서비스 응답 지연 신고 접수

[확인]
uptime 확인 결과 Load Average 8 이상 확인
top 확인 결과 CPU 사용률은 높지 않았으나 wa 값 25% 이상 확인
df -h 확인 결과 디스크 사용률 특이사항 없음
free -m 확인 결과 available 메모리 부족은 확인되지 않음
journalctl 확인 결과 같은 시간대 timeout 로그 반복 확인

[추정]
CPU 과부하보다는 디스크 I/O 대기 또는 외부 스토리지 응답 지연 가능성 확인

[조치]
해당 시간대 백업 작업 및 로그 증가 여부 확인
서비스 로그 추가 확인 후 담당자 공유

[결과]
조치 후 Load Average와 wa 감소 확인
서비스 응답 지연 완화 확인

[추가 확인]
동일 시간대 반복 여부 모니터링 예정

이렇게 쓰면 단순한 느낌이 아니라, 어떤 근거로 판단했는지가 남습니다.

“서버가 느려서 재기동했습니다”보다 훨씬 낫습니다.

---

13. 정리하면

리눅스 서버가 느릴 때 CPU 사용률만 보고 판단하면 놓치는 부분이 많습니다.

CPU가 낮아 보여도 서버가 느릴 수 있습니다.

운영 서버에서는 아래 순서로 보는 것이 좋습니다.

1. uptime으로 Load Average를 확인합니다.
2. CPU 코어 수와 Load Average를 함께 봅니다.
3. top에서 CPU 사용률과 wa 값을 확인합니다.
4. wa가 높다면 디스크 I/O 대기를 의심합니다.
5. df -h, df -i로 디스크와 inode를 확인합니다.
6. free -m으로 메모리와 Swap을 확인합니다.
7. 프로세스 상태와 로그를 함께 봅니다.
8. 조치 후 같은 지표를 다시 확인합니다.

초보 운영자라면 이 문장만 기억해도 좋습니다.

CPU가 낮다고 서버가 정상인 것은 아닙니다. Load Average와 wa를 함께 확인하세요.

서버 느림 대응도 결국 같습니다.

확인 → 판단 → 조치 → 재확인

서버가 느릴 때 CPU, 메모리, 디스크 상태를 함께 정리하는 방법은 아래 글에서 볼 수 있습니다.

https://opsnote.tistory.com/47

리눅스 서버 느림 보고할 때 CPU, 메모리, 디스크 상태 정리하는 방법

 

Load Average와 wa를 명령어별로 따로 보고 싶다면 아래 글들도 함께 보면 좋습니다.

https://opsnote.tistory.com/41

리눅스 서버 CPU 낮다고 정상이라 하지 말고 Load Average까지 확인하는 법

 

https://opsnote.tistory.com/42

리눅스 서버 CPU 낮다고 정상이라 하지 말고 top wa 값까지 확인하는 법

 

메모리와 Swap 확인은 아래 글들도 이어서 볼 수 있습니다.

https://opsnote.tistory.com/44

리눅스 서버 메모리 used만 보면 판단이 틀리는 이유와 available 확인법

 

https://opsnote.tistory.com/43

리눅스 서버 Swap 올라갔다고 바로 재기동하지 말고 확인하는 순서

 

CPU가 높은 PID와 서비스 영향도 확인은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/45

리눅스 서버 CPU 100% 알림 떴을 때, 재기동 전 범인(PID)부터 찾는 법

 

https://opsnote.tistory.com/46

리눅스 서버 특정 PID가 어떤 서비스인지 확인하는 법

 

리눅스 서버 장애 대응 전체 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/69

초보 운영자를 위한 리눅스 서버 장애 대응 순서 총정리