하드웨어 중급 #1 성능 지표 읽기 — 느리다를 숫자로 바꾸기
하드웨어 기초에서는 “느리고 비싼 이유는 CPU, 메모리, 스토리지, 네트워크 네 자원 중 하나에 있다”는 생각의 틀을 잡았습니다. 중급 시리즈는 그 틀을 실제 운영에 맞춰 씁니다. 서버가 실제로 느려졌을 때 지표를 읽고, 네 자원 중 어디가 막혔는지 가려내고, 하드웨어 수준의 처방을 내리는 일입니다.
시리즈는 9편입니다. 지표 읽기(1편)에서 출발해 CPU(2편), 메모리(3편), NUMA(4편), 스토리지 성능(5편)과 RAID 운영(6편), 스토리지 네트워크(7편), GPU 서버(8편)를 거쳐, 마지막 9편에서 느려진 서버를 처음부터 끝까지 진단하는 워크스루로 닫습니다.
첫 편의 주제는 도구가 아니라 해석입니다. top을 띄우는 법은 RHEL 고급 #3이 다룹니다. 이 글은 그 화면에 뜬 숫자가 하드웨어에서 무슨 일이 벌어지고 있다는 뜻인지를 다룹니다.
자원마다 세 가지를 묻습니다 — 사용률, 포화, 에러 #
네 자원 어디를 보든 질문은 세 가지로 같습니다. 성능 분석에서 USE(Utilization, Saturation, Errors)라고 부르는 틀입니다.
| 질문 | 뜻 | 예 |
|---|---|---|
| 사용률(Utilization) | 자원이 일한 시간의 비율 | CPU 80%, 디스크 busy 60% |
| 포화(Saturation) | 자원을 기다리며 줄 선 일의 양 | 실행 대기 큐, 디스크 I/O 큐 |
| 에러(Errors) | 자원의 동작 실패 | 디스크 I/O 에러, 패킷 드롭 |
셋 중 운영자가 가장 자주 놓치는 것이 포화입니다. 사용률은 “지금 바쁜가"이고, 포화는 “지금 줄이 생겼는가"입니다. 사용자가 체감하는 지연을 만드는 쪽은 줄, 즉 포화입니다. 사용률 100%라도 줄이 없으면 자원을 알뜰하게 쓰는 것이고, 사용률 70%라도 줄이 길면 이미 병목입니다. 순간순간 몰리는 요청(버스트)이 있으면 평균 사용률이 낮아도 줄은 생깁니다.
이번 시리즈 내내 이 틀로 갑니다. 2편의 CPU도, 5편의 디스크도 결국 “사용률은 얼마인가, 줄은 섰는가, 에러는 없는가"의 반복입니다.
로드 애버리지 — CPU 줄과 디스크 줄의 합 #
리눅스에서 가장 유명하면서 가장 자주 오해되는 지표가 로드 애버리지(load average, 실행 중이거나 실행·I/O를 기다리는 작업 수의 1·5·15분 평균)입니다.
$ uptime
14:02:11 up 41 days, 3:17, 1 user, load average: 8.42, 6.10, 4.55읽는 법의 핵심은 두 가지입니다.
- 코어 수와 비교해야 의미가 생깁니다. 로드 8은 8코어 서버에서는 “딱 맞게 바쁨"이고, 2코어 서버에서는 “6개 작업이 줄 서 있음"입니다. 기초 2편의 코어 개념이 여기서 기준선이 됩니다.
- 리눅스의 로드에는 디스크를 기다리는 작업도 포함됩니다. CPU가 한가한데 로드가 치솟는다면, 범인은 CPU가 아니라 스토리지일 가능성이 큽니다. 로드 애버리지는 “CPU 지표"가 아니라 “CPU 줄 + I/O 줄"의 합산 지표입니다.
세 숫자의 기울기도 정보입니다. 1분 값이 15분 값보다 크면 줄이 길어지는 중이고, 반대면 풀리는 중입니다.
CPU 사용률의 내역 — 같은 바쁨이 아닙니다 #
CPU 사용률은 한 덩어리 숫자가 아니라 내역이 있습니다. 어디에 시간을 썼는지에 따라 처방이 완전히 달라집니다.
| 항목 | 뜻 | 높을 때의 신호 |
|---|---|---|
| us (user) | 애플리케이션 코드 실행 | 진짜 계산이 많다. 코드 최적화나 코어 증설 |
| sy (system) | 커널 코드 실행 | 시스템 콜 폭주, 잦은 컨텍스트 스위칭 |
| wa (iowait) | 할 일이 I/O 대기뿐이라 논 시간 | 병목은 CPU가 아니라 스토리지 |
| st (steal) | 하이퍼바이저가 CPU를 안 줘서 못 돈 시간 | 가상 머신의 CPU 경합. 2편에서 자세히 |
특히 wa는 이름 때문에 오해가 잦습니다. iowait는 CPU가 일한 시간이 아니라 I/O 말고는 할 일이 없어서 논 시간입니다. wa가 40%라면 “CPU가 바쁘다"가 아니라 “CPU는 한가한데 디스크가 못 따라온다"는 뜻이라, 시선을 5편의 스토리지로 옮겨야 합니다.
네 자원의 첫 점검표 #
지표를 자원별로 묶으면, 느려진 서버 앞에서 던질 첫 질문 목록이 됩니다.
| 자원 | 사용률 | 포화 | 에러 |
|---|---|---|---|
| CPU | us+sy 비율 | 로드 vs 코어 수, 실행 대기 | (드묾) MCE 로그 |
| 메모리 | 사용량 vs available | 스왑 in/out 발생 | OOM 킬 기록 |
| 스토리지 | 디스크 busy % | I/O 큐 길이, 지연 증가 | I/O 에러, 재시도 |
| 네트워크 | 대역폭 사용량 | 송수신 큐, 재전송 | 패킷 드롭, 에러 카운터 |
각 칸을 채우는 명령은 환경마다 다르지만(vmstat, iostat, ss, 클라우드라면 CloudWatch 같은 모니터링 콘솔), 칸 자체는 어디서나 같습니다. 이 표의 칸을 위에서부터 채워 가는 것이 9편 워크스루의 뼈대가 됩니다.
자주 만나는 함정 #
- 사용률만 보고 포화를 안 본다 — “CPU 70%니까 여유 있다"는 줄의 존재를 무시한 결론입니다. 평균 70%에 버스트가 겹치면 줄은 이미 생깁니다. 사용률 옆에 항상 대기 줄 지표를 같이 둡니다.
- 로드 애버리지를 CPU 수요로만 읽는다 — 리눅스 로드에는 I/O 대기가 섞여 있습니다. 로드가 높으면 CPU와 디스크 양쪽을 다 의심해야 합니다.
- 평소 값을 모른다 — 로드 6이 비정상인지는 평소가 2였는지 5였는지에 달려 있습니다. 정상일 때의 지표를 기록해 두는 것이 진단 속도를 결정합니다.
정리 #
이번 글에서 잡은 그림입니다.
- 어떤 자원이든 사용률, 포화, 에러 세 가지를 묻습니다. 체감 지연을 만드는 쪽은 대개 포화(줄)입니다.
- 로드 애버리지는 코어 수와 비교해서 읽고, 리눅스에서는 I/O 대기까지 섞인 합산 지표임을 기억합니다.
- CPU 사용률은 us, sy, wa, st 내역으로 갈라 읽습니다. wa가 높으면 시선은 스토리지로 갑니다.
- 자원별 3질문 점검표가 진단의 출발점이고, 평소 값의 기록이 그 점검표의 기준선입니다.
다음 — CPU 심화 #
다음 글인 “하드웨어 중급 #2 CPU 심화"에서는 첫 번째 자원으로 들어갑니다. 클럭이 사양표의 숫자대로 돌지 않는 이유(터보와 스로틀링), st가 알려 주는 가상화의 그늘, 그리고 컨텍스트 스위칭의 비용까지, 기초 2편의 개념 위에 운영의 층을 올리겠습니다.