Load Average의 정체: CPU 사용률과 다른 점
uptime이 보여 주는 세 숫자, Load Average는 리눅스에서 가장 유명하면서 가장 자주 오독되는 지표입니다. “1.0을 넘으면 위험하다”, “CPU 사용률 같은 것이다” 같은 절반만 맞는 통념이 많습니다. 이 글은 이 숫자의 정확한 정의와, CPU 사용률과 어긋나는 전형적인 사례들을 정리합니다. 하드웨어 중급 #1에서 지표 전반을 다뤘고, 여기서는 Load Average 하나를 끝까지 파고듭니다.
$ uptime
14:32:07 up 213 days, 4:11, 1 user, load average: 6.12, 4.35, 2.08정의: 실행 중 + 실행 대기 + 디스크 대기 #
리눅스의 Load Average는 다음 태스크 수의 지수 이동 평균입니다.
- 실행 중(R): 지금 CPU 코어 위에서 도는 태스크
- 실행 대기(R): 준비는 됐는데 코어가 비기를 기다리는 태스크입니다. 서버가 느린 이유 #1에서 본 run queue입니다
- 인터럽트 불가 대기(D): 주로 디스크 I/O의 완료를 기다리며 잠든 태스크
셋째 항목이 핵심이자 함정입니다. 다른 유닉스 계열과 달리 리눅스는 디스크를 기다리는 태스크까지 로드에 셉니다. 그래서 리눅스의 Load Average는 “CPU 부하"가 아니라 “CPU 또는 디스크를 기다리는 수요"에 가깝습니다. CPU가 놀아도 디스크가 막히면 로드는 치솟습니다. 참고로 일반적인 대기(네트워크 응답, 락, sleep)는 S 상태라 로드에 잡히지 않습니다.
읽는 기준: 절대값이 아니라 코어 수 대비 #
“1.0이면 위험"은 코어가 1개이던 시절의 기준입니다. 로드는 수요의 개수이므로, 공급(코어 수)과 비교해야 의미가 생깁니다.
- 로드 ≈ 코어 수: 공급과 수요가 얼추 맞는 상태입니다. 16코어 서버의 로드 14는 건강한 만석입니다.
- 로드 ≪ 코어 수: 여유가 있습니다.
- 로드 ≫ 코어 수가 지속: 태스크들이 줄을 서고 있습니다. CPU 때문인지 디스크 때문인지는 이 숫자만으로 모릅니다(아래에서 가릅니다).
코어 수는 nproc으로 확인합니다. 컨테이너 안이라면 주의가 하나 더 필요합니다. Load Average는 호스트 전체의 값이라, 컨테이너의 CPU 제한과 무관하게 이웃의 부하까지 섞여 보입니다.
CPU 사용률과 어긋나는 네 가지 전형 #
Load Average와 CPU 사용률은 다른 것을 재므로, 어긋나는 조합마다 진단이 다릅니다.
| 사용률 | 로드 | 전형적인 원인 |
|---|---|---|
| 높음 | ≈ 코어 수 | 정상적인 연산 포화. 수요가 공급을 살짝 넘는 상태 |
| 낮음 | 높음 | 디스크 병목: D 상태 태스크가 로드를 밀어 올림. NFS 응답 정지가 극단 사례 |
| 높음 | ≫ 코어 수 | CPU 과수요. 스레드·워커 수가 코어 대비 과다한 경우 포함 |
| 낮음 | 낮은데 느림 | 로드에 안 잡히는 대기(락, 네트워크, 업스트림). 1편의 영역 |
특히 두 번째 조합이 리눅스 고유의 함정입니다. “CPU는 5%인데 로드가 40"인 서버는 CPU 문제가 아니라 스토리지 문제이고, NFS 서버가 응답을 멈추면 그 마운트를 만지는 태스크들이 전부 D 상태로 쌓여 로드가 수백까지 치솟는 악명 높은 장면이 나옵니다. 로드가 높을 때 D 상태를 바로 확인하는 명령은 이렇습니다.
$ ps -eo state,pid,wchan:30,comm | awk '$1=="D"'
D 8123 rpc_wait_bit_killable backup-agent
D 8124 rpc_wait_bit_killable backup-agentwchan(무엇을 기다리며 잠들었는지)까지 보이므로, 디스크인지 NFS인지까지 한 번에 좁혀집니다.
1분, 5분, 15분: 세 값은 추세를 위해 있습니다 #
세 값은 각각 최근 1분, 5분, 15분의 지수 이동 평균입니다. 개별 값보다 비교가 정보입니다.
- 1분 ≫ 15분 (예: 12, 4, 2): 부하가 지금 막 올라가는 중입니다. 방금 시작된 무언가(배포, 배치, 트래픽 급증)를 찾습니다.
- 1분 ≪ 15분 (예: 2, 6, 14): 부하가 빠지는 중입니다. 방금 끝난 사건의 뒤처리 국면입니다.
- 셋이 비슷하게 높음: 정착된 상태입니다. 일시 스파이크가 아니라 용량 또는 병목의 문제입니다.
모니터링 알림을 건다면 순간 스파이크에 강한 5분 값 기준이 무난하고, 임계값은 절대값이 아니라 코어 수 대비 배율(예: 코어 수의 1.5배 지속)로 잡아야 서버 사양이 바뀌어도 알림이 유효합니다.
진단 순서 정리 #
로드가 높다는 알림을 받았을 때의 순서입니다.
- 코어 수 대비로 환산합니다.
nproc대비 몇 배인지부터, 그리고 1·5·15분 비교로 올라가는 중인지 정착 상태인지 봅니다. - CPU 사용률과 대조합니다. 사용률도 높으면 CPU 수요, 사용률이 낮으면 D 상태를 의심합니다.
- D 상태를 셉니다.
ps로 D 상태 태스크와wchan을 보고, 디스크·NFS 쪽이면 iostat 진단으로 넘어갑니다. - CPU 쪽이면 run queue 진단으로:
vmstat의r, 프로세스별 CPU 소비 순위로 내려갑니다. 도구 전반은 RHEL 고급 #3에서 다뤘습니다.
정리 #
- 리눅스의 Load Average는 실행 중 + 실행 대기 + 디스크 대기(D 상태) 태스크 수의 이동 평균입니다. CPU 사용률과 다른 것을 잽니다.
- 절대값이 아니라 코어 수 대비로 읽습니다. 16코어의 로드 14는 만석이지 과부하가 아닙니다.
- 사용률은 낮은데 로드가 높으면 디스크(특히 NFS)의 D 상태 적체를 의심하고,
ps의 state·wchan으로 확인합니다. - 1·5·15분 세 값은 추세용입니다. 올라가는 중, 빠지는 중, 정착 상태를 먼저 가립니다.
- 알림 임계값은 코어 수 대비 배율로 잡습니다. 절대값 기준은 서버 사양이 바뀌면 무의미해집니다.