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

리눅스 서버가 느린데 CPU 사용률은 낮고 top wa 값이 높을 때 디스크 I/O 대기, Load Average, D 상태 프로세스, iostat, vmstat, df -h, journalctl 로그를 순서대로 확인하는 방법을 설명하는 대표 이미지

 

리눅스 서버가 느려졌을 때 top 명령어를 열어보면 보통 CPU 사용률부터 보게 됩니다.

top

 

그런데 CPU 사용률은 높지 않은데 서버가 계속 느린 경우가 있습니다.

처음에는 이렇게 생각하기 쉽습니다.

CPU는 별로 안 쓰는 것 같은데
왜 서버가 느리지?
왜 명령어 반응이 늦지?
왜 서비스 응답이 밀리지?

 

이럴 때 같이 봐야 하는 값이 있습니다.

바로 wa입니다.

wa는 I/O wait를 의미합니다. CPU가 정말 아무 일도 안 하는 게 아니라, 디스크나 스토리지 응답을 기다리는 시간일 수 있습니다.

즉, CPU 사용률만 낮다고 해서 서버가 정상이라고 판단하면 안 됩니다.

top에서 wa 값은 어디에 있을까?

먼저 top을 실행합니다.

top

 

상단에 이런 줄이 보일 수 있습니다.

%Cpu(s):  4.0 us,  1.5 sy,  0.0 ni, 80.0 id, 14.5 wa,  0.0 hi,  0.0 si,  0.0 st

 

여기서 우리가 볼 값은 wa입니다.

14.5 wa

 

초보 운영자 기준으로는 이렇게 보면 됩니다.

wa
→ I/O wait
→ CPU가 디스크나 스토리지 응답을 기다리는 시간

 

id 값이 높으면 CPU가 놀고 있는 것처럼 보일 수 있습니다.

하지만 wa가 높다면 이야기가 조금 달라집니다.

CPU가 일을 안 하는 게 아니라, 처리해야 할 작업이 디스크나 스토리지 응답을 기다리느라 멈춰 있을 수 있습니다.

CPU가 낮은데 서버가 느린 이유

서버가 느리면 보통 CPU가 높을 거라고 생각하기 쉽습니다.

하지만 실제로는 이런 조합도 나옵니다.

CPU 사용률은 낮음
Load Average는 높음
서버 응답은 느림
top에서 wa 값이 높음

 

이 경우는 CPU 연산 부하보다 I/O 대기를 먼저 의심해볼 수 있습니다.

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

로그 파일이 과도하게 쓰이는 중
백업 작업이 디스크를 많이 사용하는 중
DB가 디스크 I/O를 많이 쓰는 중
NFS나 NAS 응답이 느린 상태
외부 스토리지 응답이 느린 상태
디스크 용량이 부족한 상태
컨테이너 로그가 빠르게 쌓이는 중

 

이런 경우 CPU만 보면 “별로 안 바쁜데?”라고 착각할 수 있습니다.

하지만 실제로는 작업들이 디스크 응답을 기다리며 줄을 서 있는 상태일 수 있습니다.

 

서버가 느릴 때 CPU만 보지 말고 Load Average까지 같이 봐야 하는 이유는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/41

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

 

wa 값이 높다는 것은 무슨 뜻일까?

예를 들어 이런 상태를 보겠습니다.

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

 

여기서 id는 70%입니다.

겉으로 보면 CPU가 여유 있어 보입니다.

그런데 wa가 25%입니다.

이 경우는 단순히 “CPU가 놀고 있다”고 보기 어렵습니다.

작업들이 디스크나 스토리지 응답을 기다리고 있어서 CPU가 다음 일을 진행하지 못하는 상황일 수 있습니다.

그래서 서버가 느릴 때는 아래처럼 같이 봐야 합니다.

CPU 사용률
Load Average
wa 값
프로세스 상태
디스크 I/O
디스크 용량
서비스 로그

 

운영에서는 지표 하나만 보고 결론 내리면 빗나가기 쉽습니다. 여러 단서를 맞춰보는 쪽이 안전합니다.

Load Average와 wa는 같이 봐야 합니다

앞 글에서 Load Average를 봤다면, 이번에는 wa를 같이 보면 더 좋습니다.

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

Load Average 높음
CPU 사용률 낮음
wa 값 높음

 

이 경우는 CPU를 많이 쓰는 프로세스보다 디스크 I/O 대기 쪽을 먼저 의심해볼 수 있습니다.

반대로 아래처럼 보일 수도 있습니다.

Load Average 높음
CPU 사용률 높음
wa 값 낮음

 

이 경우는 CPU를 많이 쓰는 프로세스를 먼저 확인하는 쪽이 자연스럽습니다.

즉, Load Average만 보고 끝내지 말고 top의 CPU 상세 항목까지 같이 봐야 합니다.

uptime
top
nproc

 

CPU가 높은 PID를 찾고 바로 kill 하면 안 되는 이유는 아래 글과 이어서 보면 좋습니다.

https://opsnote.tistory.com/45

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

D 상태 프로세스도 같이 확인합니다

wa가 높을 때는 프로세스 상태도 같이 보면 좋습니다.

아래 명령어로 프로세스 상태를 확인할 수 있습니다.

ps -eo pid,stat,cmd | head

 

특히 D 상태가 많이 보이는지 확인합니다.

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

 

프로세스 상태는 대략 이렇게 볼 수 있습니다.

R
→ 실행 중 또는 실행 대기

S
→ 대기 상태

D
→ I/O 대기 상태

Z
→ 좀비 프로세스

 

D 상태는 보통 uninterruptible sleep 상태로, 디스크나 스토리지 I/O 응답을 기다리는 경우에 볼 수 있습니다.

다만 여기서 바로 kill을 하면 안 됩니다.

D 상태 프로세스가 어떤 작업인지 먼저 봐야 합니다.

정상 백업 작업인지
로그 압축 작업인지
배치 작업인지
서비스 프로세스인지
NFS 접근 중인 프로세스인지
DB 관련 프로세스인지

 

운영 서버에서는 프로세스를 죽이는 것보다, 왜 그 상태가 되었는지 확인하는 것이 먼저입니다.

iostat로 디스크 I/O를 확인합니다

wa가 높고 Load Average도 높다면 디스크 I/O 상태를 확인합니다.

가능하면 iostat를 사용합니다.

iostat -xz 1 3

 

iostat는 환경에 따라 기본 설치되어 있지 않을 수 있습니다. 보통 sysstat 패키지에 포함됩니다.

운영 서버에서 패키지 설치가 필요하다면 바로 설치하기보다, 서버 정책이나 담당자 확인 후 진행하는 것이 안전합니다.

처음에는 모든 값을 외우려고 하지 않아도 됩니다.

초보 운영자 기준으로는 아래 정도부터 봐도 됩니다.

%util
→ 디스크가 얼마나 바쁘게 사용되는지

await
→ I/O 요청이 처리되기까지 걸린 평균 시간

r/s
→ 초당 읽기 요청 수

w/s
→ 초당 쓰기 요청 수

rkB/s, wkB/s
→ 초당 읽기/쓰기 데이터량

 

예를 들어 이런 조합이면 디스크 I/O 지연 가능성을 볼 수 있습니다.

Load Average 높음
wa 높음
iostat에서 await 높음
iostat에서 %util 높음

 

물론 이 값 하나만 보고 디스크 장애라고 단정하면 안 됩니다.

디스크가 바쁜 이유가 정상 백업일 수도 있고, 로그 폭증일 수도 있고, 특정 배치 작업일 수도 있습니다.

vmstat로도 흐름을 볼 수 있습니다

iostat가 없거나 간단히 흐름을 보고 싶다면 vmstat도 사용할 수 있습니다.

vmstat 1 5

 

여기서 볼 수 있는 값 중 일부는 아래와 같습니다.

wa
→ I/O wait

bi
→ block in

bo
→ block out

si
→ swap in

so
→ swap out

 

wa가 계속 높고, bi, bo 값도 같이 움직인다면 디스크 I/O 쪽을 더 확인해볼 수 있습니다.

Swap까지 같이 움직이면 메모리 압박 가능성도 함께 봐야 합니다.

 

Swap이 올라갔다고 바로 재기동하지 말고 확인하는 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/43

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

df -h로 디스크 용량도 확인합니다

wa가 높을 때 디스크 성능만 볼 것이 아니라 용량도 같이 봐야 합니다.

df -h

 

특정 경로를 확인할 수도 있습니다.

df -h /var
df -h /tmp

 

디스크가 거의 꽉 차 있으면 로그 쓰기, 임시 파일 생성, 애플리케이션 동작에 영향을 줄 수 있습니다.

특히 /var는 로그, 캐시, spool, 일부 서비스 데이터와 관련될 수 있어서 서버 운영 중 자주 봐야 하는 경로입니다.

 

서버가 느릴 때 CPU, 메모리, 디스크 상태를 보고용으로 정리하는 흐름은 아래 글과 함께 보면 좋습니다.

https://opsnote.tistory.com/47

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

로그 폭증도 I/O 대기를 만들 수 있습니다

애플리케이션 오류가 반복되면서 로그가 계속 쌓이는 경우도 있습니다.

이때는 디스크 쓰기가 늘어나고, 상황에 따라 I/O 대기가 올라갈 수 있습니다.

로그 용량은 아래처럼 확인할 수 있습니다.

du -sh /var/log/*

 

큰 로그 파일을 찾을 수도 있습니다.

find /var/log -type f -size +100M -exec ls -lh {} \;

 

하지만 운영 서버에서 로그를 바로 삭제하면 안 됩니다.

먼저 아래를 확인해야 합니다.

어떤 서비스 로그인지
현재도 쓰고 있는 로그인지
보관 정책이 있는지
장애 분석에 필요한 로그인지
logrotate 대상인지

 

로그가 커졌다고 무작정 비우면 원인 분석에 필요한 흔적이 사라질 수 있습니다.

NFS나 외부 스토리지도 확인합니다

NFS, NAS, 외부 스토리지를 사용하는 서버라면 해당 스토리지 응답 지연으로 wa가 올라갈 수 있습니다.

마운트 상태는 아래처럼 확인합니다.

df -h

 

NFS 마운트만 보고 싶다면 이렇게 확인할 수 있습니다.

mount | grep nfs

 

또는 파일시스템 타입을 같이 보고 싶다면 아래처럼 볼 수 있습니다.

df -Th

 

NFS 쪽이 느리면 서버 CPU는 낮아도 작업들이 대기 상태로 쌓일 수 있습니다.

이 경우는 서버 자체보다 스토리지, 네트워크 구간, NFS 서버 상태까지 같이 봐야 할 수 있습니다.

여기서 바로 서버 재기동으로 가면 원인 단서가 사라질 수 있습니다.

dmesg와 journalctl에서 디스크 관련 메시지를 봅니다

디스크나 스토리지 문제가 의심되면 커널 메시지도 확인할 수 있습니다.

dmesg | tail -n 100

 

systemd 환경에서는 journalctl도 같이 볼 수 있습니다.

journalctl -k -n 100 --no-pager

 

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

journalctl -u nginx -n 100 --no-pager

 

확인할 만한 키워드는 아래와 같습니다.

I/O error
timeout
reset
read error
write error
no space
buffer
filesystem
disk

 

서비스 상태도 함께 봅니다.

systemctl status nginx --no-pager

 

서비스 로그 확인은 아래 글에서 자세히 정리했습니다.

https://opsnote.tistory.com/33

리눅스 서버 서비스 장애 났을 때 journalctl로 systemd 로그 확인하는 법

 

서비스 상태 확인은 아래 글과 이어서 보면 좋습니다.

https://opsnote.tistory.com/27

리눅스 서버 서비스가 안 뜰 때 재기동부터 하지 말고 systemctl status 먼저 확인하는 법

 

wa 값이 높을 때 바로 재기동하면 안 되는 이유

서버가 느리고 wa가 높으면 바로 재기동하고 싶어질 수 있습니다.

하지만 바로 재기동하면 원인 단서가 사라질 수 있습니다.

예를 들어 원인이 이런 것일 수 있습니다.

백업 작업이 돌고 있음
로그 압축 작업이 실행 중
특정 배치가 대량 파일을 처리 중
NFS 응답이 느림
DB가 디스크를 과도하게 사용 중
스토리지 장애 징후가 있음
디스크 용량 부족으로 쓰기 작업이 실패 중

 

서버를 재기동하면 잠깐 좋아질 수는 있습니다.

하지만 같은 시간대에 다시 느려질 수 있고, 원인을 확인하기 더 어려워질 수 있습니다.

재기동 전에는 최소한 아래는 확인하는 것이 좋습니다.

top에서 wa 값
Load Average
D 상태 프로세스
iostat 또는 vmstat 결과
디스크 사용량
최근 실행된 작업
로그 증가 여부
백업 또는 배치 작업 여부
서비스 로그

 

서버 전체를 재기동해야 할지 고민되는 상황이라면 아래 체크리스트도 함께 보면 좋습니다.

https://opsnote.tistory.com/19

리눅스 서버 재기동 전 바로 껐다 켜지 말고 확인해야 할 체크리스트

 

wa 값이 높을 때 확인 순서

초보 운영자 기준으로는 아래 순서가 무난합니다.

1. top에서 wa 값 확인
2. uptime으로 Load Average 확인
3. ps로 D 상태 프로세스 확인
4. iostat 또는 vmstat로 I/O 상태 확인
5. df -h로 디스크 용량 확인
6. 로그 폭증 여부 확인
7. NFS 또는 외부 스토리지 사용 여부 확인
8. dmesg 또는 journalctl로 디스크 관련 메시지 확인
9. 서비스 상태와 애플리케이션 로그 확인
10. 조치 전 영향도 판단

 

명령어로 보면 이렇게 정리할 수 있습니다.

top
uptime
ps -eo pid,stat,cmd | grep ' D '
iostat -xz 1 3
vmstat 1 5
df -h
du -sh /var/log/*
mount | grep nfs
dmesg | tail -n 100
journalctl -k -n 100 --no-pager
systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager

 

이 흐름으로 보면 CPU 문제인지, 디스크 I/O 대기인지, 특정 작업 때문인지 방향을 잡기 좋습니다.

결과를 어떻게 해석하면 좋을까?

몇 가지 상황을 나눠보면 이해하기 쉽습니다.

wa 높음 + Load Average 높음
→ I/O 대기 가능성

wa 높음 + D 상태 프로세스 많음
→ 디스크 또는 스토리지 응답 지연 가능성

wa 높음 + iostat await 높음
→ I/O 요청 처리 지연 가능성

wa 높음 + df -h 사용률 높음
→ 디스크 용량 부족 또는 쓰기 지연 가능성

wa 높음 + NFS 사용 중
→ NFS 또는 네트워크 스토리지 응답 지연 가능성

wa 높음 + 로그 파일 급증
→ 애플리케이션 오류 반복 또는 로그 폭증 가능성

 

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

wa는 방향을 알려주는 신호에 가깝습니다. 실제 원인은 프로세스, 디스크, 스토리지, 서비스 로그를 같이 봐야 좁혀집니다.

실무 보고 예시

wa 값이 높을 때는 이렇게 보고할 수 있습니다.

서버 상태 확인 결과, CPU 사용률은 높지 않으나 top 기준 wa 값이 높게 확인되었습니다.
CPU 연산 부하보다는 디스크 I/O 대기 가능성이 있어 iostat 및 관련 프로세스를 추가 확인하겠습니다.

 

Load Average도 같이 높은 경우는 이렇게 정리할 수 있습니다.

Load Average가 CPU 개수 대비 높고, top 기준 wa 값도 함께 높게 확인됩니다.
CPU 사용 프로세스보다 I/O 대기 및 디스크 응답 지연 여부를 우선 확인하겠습니다.

 

백업 작업이 의심된다면 이렇게 쓸 수 있습니다.

wa 값 상승 시간대와 백업 작업 시간이 일부 겹치는 것으로 확인됩니다.
백업 작업으로 인한 일시적 디스크 I/O 증가 여부를 추가 확인하겠습니다.

 

NFS가 의심된다면 이렇게 정리할 수 있습니다.

NFS 마운트 경로 사용 중이며, wa 값 상승이 확인됩니다.
스토리지 응답 지연 또는 네트워크 구간 지연 가능성을 함께 확인하겠습니다.

 

디스크 용량 문제 가능성이 있다면 이렇게 쓸 수 있습니다.

wa 값 상승과 함께 특정 파일시스템 사용률이 높게 확인됩니다.
로그 증가 여부와 서비스 쓰기 오류 발생 여부를 추가 확인하겠습니다.

 

원인이 아직 불명확하면 이렇게 정리합니다.

현재 wa 값은 높게 확인되나, 단일 지표만으로 디스크 장애로 단정하기는 어렵습니다.
D 상태 프로세스, iostat, 디스크 사용률, 서비스 로그를 함께 확인해 원인 범위를 좁히겠습니다.

 

이렇게 쓰면 단순히 “서버 느립니다”보다 훨씬 명확합니다.

정리하면

리눅스 서버가 느린데 CPU 사용률이 낮다면 top에서 wa 값을 같이 봐야 합니다.

기본 확인 명령어는 아래입니다.

top

 

wa는 I/O wait입니다.

wa
→ 디스크나 스토리지 응답을 기다리는 시간

 

wa가 높다면 아래를 같이 확인합니다.

uptime
ps -eo pid,stat,cmd | grep ' D '
iostat -xz 1 3
vmstat 1 5
df -h
journalctl -k -n 100 --no-pager

 

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

CPU가 낮아도 wa가 높으면 디스크나 스토리지를 기다리는 중일 수 있습니다.

단, wa가 높다고 바로 디스크 장애로 단정하면 안 됩니다.

서버 느림 확인도 결국 같습니다.

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

 

wa 값이 높게 보인다면 CPU가 바쁜 상황이라기보다, 디스크나 스토리지 응답을 기다리는 상황일 수 있습니다.

그래서 wa만 보고 바로 디스크 장애로 단정하기보다, Load Average, 프로세스 상태, 디스크 사용률, 로그를 함께 확인하는 것이 좋습니다.

서버가 느릴 때 CPU 사용률만 보지 않고 Load Average까지 함께 확인하는 방법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/41

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

 

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

https://opsnote.tistory.com/47

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

 

리눅스 서버 장애 대응 전체 흐름은 아래 글에서 함께 보면 좋습니다.

https://opsnote.tistory.com/69

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