CPU는 한가한데 서버는 느리다: 리눅스 Load Average 읽는 법

서버 응답은 느린데 CPU 사용률 그래프에는 여유가 있습니다. 반면 load 값은 평소보다 높게 보입니다. 두 지표가 서로 모순되는 것일까요? 먼저 각각 무엇을 세고 어느 시간을 보여주는지 맞춰 봐야 합니다.

이 글은 Linux 서버의 부하 평균을 읽는 정보성 가이드입니다. 명령 예시는 procps-ng 도구와 관련 /proc 파일을 기준으로 하며, 실제 운영 서버에서 실행한 결과나 장애 사례를 제시하는 글은 아닙니다.

Load Average는 CPU 사용률과 무엇이 다른가요?

Load Average는 실행 가능·무중단 대기를 반영한 평균이며 CPU 사용 시간의 비율이 아닙니다.

Linux의 /proc/loadavg 매뉴얼은 앞의 세 값을 R 상태 작업과 D 상태 대기를 반영하는 부하 평균으로 설명합니다. uptime 매뉴얼도 실행 중이거나 CPU를 기다리는 상태와 무중단 대기를 구분합니다.

CPU 사용률은 시간 배분을 읽는 쪽입니다. 예를 들어 vmstat의 CPU 항목에서 us·sy·id는 각각 사용자 코드·커널 코드·유휴 상태에 쓴 시간의 비율입니다. 도구마다 표시 항목이 다르므로 대시보드의 CPU 그래프가 무엇을 합산했는지도 확인해야 하죠.

또한 uptime 문서는 load가 CPU 개수로 정규화되지 않는다고 명시합니다. 같은 숫자를 모든 서버의 공통 경보선으로 쓰기 전에 대상 CPU 구성과 작업 상태를 확인하세요. load를 CPU 개수로 나눈 비율도 그 자체로 CPU 사용률이 되지는 않습니다.

1분·5분·15분 값은 어떤 흐름을 보여주나요?

세 값은 서로 다른 시간 규모의 부하 평균이므로 순간 작업 수나 분리된 구간별 건수로 읽지 않습니다.

/proc/loadavg의 앞 세 필드는 순서대로 1·5·15분 부하 평균입니다. 다만 최근 구간의 작업 수를 단순 합산한 표는 아닙니다. Linux 커널의 계산 구현은 과거 영향이 지수적으로 줄어드는 평균이라고 설명합니다.

짧은 쪽 평균이 긴 쪽보다 높다면 최근 부하가 상대적으로 컸는지 살펴볼 계기가 됩니다. 그러나 한 번의 관측만으로 바로 지금도 증가 중이라고 확정하지 마세요. 현재 상태를 확인하는 동안에도 앞선 부하의 영향이 평균에 남을 수 있죠. 이는 평균 계산 방식에서 도출한 해석상 주의점입니다.

기록에는 세 값과 조회 시각을 함께 남겨 보세요. 지연이 발생한 시각과 대시보드의 집계 간격도 맞춥니다. 서로 다른 시점의 CPU 그래프와 load 화면을 비교하면, 지표 차이와 시간 차이를 혼동할 수 있어요.

CPU 사용률이 낮아도 load가 높을 수 있나요?

무중단 대기도 부하 평균에 반영되므로 CPU가 바쁘지 않은 상황에서도 load가 높을 수 있습니다.

ps 매뉴얼의 상태 코드에서 R은 실행 중이거나 실행 가능한 상태이고, D는 보통 I/O와 관련된 무중단 수면 상태입니다. S로 표시되는 일반적인 이벤트 대기와도 구분해야 하죠.

따라서 load가 높다는 결과만으로 CPU가 계산을 계속 수행하고 있다고 볼 수는 없습니다. D 상태가 보인다고 곧바로 로컬 디스크 고장이라고 결론 내릴 수도 없어요. 상태 문자는 조사 방향을 정하는 단서이며, 기다리는 대상과 원인을 증명하는 결과는 아닙니다.

CPU 통계의 wa도 원인 확정값으로 다루지 않습니다. /proc/stat 매뉴얼은 iowait 계산의 한계와 값의 신뢰성 문제를 설명합니다. 한 항목만으로 특정 장치의 병목을 확정하기보다 작업 상태·장치 기록과 대조하는 편이 좋죠.

실행 상태와 자원 압력은 무엇으로 함께 확인하나요?

현재 작업 상태와 CPU 통계를 함께 읽고 지원 환경에서는 PSI로 자원 대기 영향을 대조합니다.

아래는 설정을 변경하지 않는 조회 예시입니다. 설치된 도구의 버전과 /proc의 제공·접근 범위부터 확인하세요. 명령이 실행된 호스트와 조사 대상이 같은지도 기록합니다.

vmstat의 r은 실행 중이거나 실행 시간을 기다리는 작업, b는 I/O 완료를 기다리며 막힌 작업 수를 보여줍니다. 예시의 1은 갱신 간격(초), 5는 출력 횟수예요. CPU 등 평균 통계의 첫 보고는 부팅 이후 기준이고 이후는 지정 간격 기준이며, 프로세스·메모리 항목은 두 경우 모두 순간 상태입니다.

ps의 -e는 전체 프로세스를 선택하고 -L은 스레드를 표시하며 -o는 출력 열을 정합니다. 한 번의 스냅샷이므로 잠깐 나타났다 사라지는 대기를 모두 담았다고 생각하면 안 되죠. 출력의 STAT에는 상태 문자 외에 부가 문자가 붙을 수도 있습니다.

Linux PSI 공식 문서는 /proc/pressure 아래 cpu·memory·io 파일을 설명합니다. some은 해당 자원 때문에 일부 작업이 멈춰 있던 시간 비율이며, avg10·avg60·avg300은 10·60·300초 규모의 추세를 나타냅니다. total의 단위는 마이크로초입니다.

PSI 비율은 CPU 사용률과 다릅니다. 특히 시스템 수준 CPU full은 정의되지 않으므로 이를 일반적인 압력 판정값으로 해석하지 않습니다. 파일을 읽을 수 없을 때도 자원 압력이 없었다고 기록하지 마세요. 컨테이너 안의 /proc 결과를 해당 컨테이너만의 지표라고 가정하기보다, 호스트·컨테이너와 수집 도구의 관측 범위를 확인해야 해요.

증설을 결정하기 전 어떤 기록을 대조하나요?

느려진 요청의 시간과 서버를 맞춘 뒤 부하 평균·작업 상태·자원 압력의 변화를 함께 확인합니다.

진단 기록은 같은 사건을 설명할 수 있어야 합니다. 평균이 높았다는 사실, 현재 R·D 작업이 보인다는 사실, 고객 요청이 느렸다는 사실을 각각 적고 시점을 연결해 보세요. 아래 표는 이 글이 제안하는 기록 방식이며 자동 원인 판정표는 아닙니다.

CPU 시간과 실행 대기 자료가 같은 시점에 문제를 가리키는지, 대기 작업과 다른 자원 기록을 더 살펴야 하는지부터 나눕니다. CPU를 늘리거나 작업을 종료하기 전에 원인 가설과 확인 자료를 맞추는 순서예요. 모든 서버에 같은 load 임계값을 제시하지는 않습니다.

파일 생성 실패와 용량·inode의 관계는 디스크 여유가 있는데 파일을 못 만든다면: df -h와 df -i를 함께 보는 이유에서 다룹니다. 이번 글은 저장 공간을 정리하는 절차가 아니라 서로 다른 성능 지표를 읽는 데 집중합니다.

여러 서비스의 로그·메트릭·트레이스를 연결하는 큰 흐름은 옵저버빌리티(관측성)가 모니터링과 다른 이유, 로그·메트릭·트레이스 입문 가이드에서 이어서 볼 수 있습니다. 기존 도구 비교나 도입 순서보다 이번 진단에서는 대상·시점·작업 상태를 먼저 맞춰 보세요.

이것만 기억하세요

자주 묻는 질문 (FAQ)