리눅스 uptime 명령어 사용법 - 로드 애버리지 읽는 법과 서버 느림 진단 첫 단계

이 명령어를 언제 쓰는가

"서버가 느리다"는 연락을 받았을 때 가장 먼저 치는 명령이다. 접속하자마자 uptime 한 줄이면 지금 부하가 걸려 있는지, 아니면 이미 지나간 일인지, 그리고 최근에 재부팅이 있었는지가 동시에 보인다.

진단 순서는 uptime으로 부하 유무를 확인하고 → vmstat으로 원인이 CPU인지 메모리(스왑)인지 디스크 대기인지 가르고 → iostat으로 어느 디스크가 밀리는지 좁히는 것이다. uptime은 그 첫 관문이며, 여기서 로드가 낮게 나오면 서버 부하가 아니라 애플리케이션이나 네트워크 쪽을 봐야 한다는 뜻이 된다.

기본 형식

uptime [-p] [-s]

인자 없이 실행하는 것이 기본이다. uptime은 /proc/uptime과 /proc/loadavg를 읽어 한 줄로 요약해 준다. 실제로 cat /proc/loadavg를 하면 같은 값을 원본 그대로 볼 수 있다.

자주 쓰는 옵션

옵션	의미	예시
(없음)	현재 시각, 가동 시간, 접속자 수, 로드 애버리지	`uptime`
-p	가동 시간만 사람이 읽기 쉽게(pretty)	`uptime -p`
-s	부팅한 시각을 날짜로 출력	`uptime -s`

옵션이 셋뿐이다. -p와 -s는 GNU procps 계열에만 있고 macOS/BSD의 uptime에는 없다. macOS에서 부팅 시각을 보려면 sysctl -n kern.boottime을 쓴다.

출력 읽는 법

 22:18:01 up 1:53,  1 user,  load average: 1.55, 2.35, 3.84

왼쪽부터 현재 시각, 부팅 후 경과 시간(1시간 53분), 로그인 세션 수, 그리고 최근 1분 / 5분 / 15분 평균 로드다.

참고로 macOS는 같은 정보를 조금 다른 서식으로 낸다. 콤마가 없고 복수형이다.

22:18  up  1:53, 1 user, load averages: 1.55 2.35 3.84

세 숫자를 나란히 보는 이유는 추세를 읽기 위해서다. 위 예시는 15분 평균 3.84에서 1분 평균 1.55로 내려왔으니 부하가 이미 빠지는 중이다. 반대로 0.5, 1.2, 3.0이 아니라 3.0, 1.2, 0.5 순이면 지금 막 부하가 몰리기 시작한 것이다.

로드 애버리지를 판단하는 기준

로드는 백분율이 아니다. 실행 대기 중이거나 디스크 I/O를 기다리는 프로세스의 개수 평균이다. 그래서 절대값만 보면 안 되고 CPU 코어 수로 나눠야 한다.

nproc                    # 코어 수 확인 (Ubuntu/RHEL 공통)
getconf _NPROCESSORS_ONLN # nproc가 없을 때
sysctl -n hw.ncpu        # macOS/BSD

코어가 4개인데 로드가 4.0이면 "정확히 꽉 찬" 상태다. 8.0이면 절반이 줄을 서 있다는 뜻이다. 경험적으로 로드 / 코어 수가 1을 넘어 지속되면 응답 지연이 체감되기 시작하고, 2를 넘으면 이미 문제 상황이다.

실전 예제

1) 접속 직후 상태를 한 줄로 확인한다.

uptime

2) 코어 수로 나눈 값을 바로 계산해 판단 기준을 없앤다.

echo "load/core = $(awk -v c=$(nproc) '{printf "%.2f", $1/c}' /proc/loadavg)"

3) 장애 보고서에 "언제부터 떠 있었는가"를 넣어야 할 때.

uptime -s
uptime -p

4) 부하가 오르는 중인지 내려가는 중인지 몇 분간 지켜본다.

watch -n 5 uptime

5) 여러 서버를 한 번에 훑는다.

for h in web01 web02 db01; do
  printf '%-8s %s\n' "$h" "$(ssh -n "$h" uptime)"
done

함정과 주의점

로드는 CPU 사용률이 아니다. 리눅스의 로드 애버리지에는 CPU를 기다리는 프로세스뿐 아니라 디스크 I/O를 기다리는 D 상태(uninterruptible sleep) 프로세스도 포함된다. 그래서 CPU 사용률이 5%인데 로드가 20인 상황이 실제로 벌어진다. 이건 스토리지나 NFS가 막힌 것이지 CPU 부족이 아니다. 이 구분을 하려고 다음 단계에서 vmstat의 b, wa 열을 보는 것이다. 참고로 macOS/BSD는 I/O 대기를 로드에 포함하지 않으므로 같은 숫자라도 의미가 다르다.

컨테이너 안에서 본 uptime은 호스트의 값이다. 도커 컨테이너에서 uptime을 치면 컨테이너가 뜬 시각이 아니라 호스트가 부팅한 시각이 나오고, 로드도 호스트 전체 로드다. cgroup은 /proc/loadavg를 격리하지 않기 때문이다. 컨테이너 단위 부하는 /sys/fs/cgroup의 CPU 통계나 컨테이너 모니터링 도구로 봐야 한다.

가동 시간이 짧으면 그 자체가 단서다. "느리다"는 신고를 받고 접속했는데 uptime이 10분이면 부하 문제가 아니라 방금 재부팅(또는 크래시)이 있었다는 뜻이다. 이럴 때는 last reboot와 dmesg -T로 넘어가는 것이 맞다.