왜 전통적인 모니터링 툴이 여전히 중요한가
HPC 환경을 운영하시다 보면 Prometheus, Grafana, OpenTelemetry 같은 최신 모니터링 스택을 많이 사용하실 것입니다. 하지만 운영 현장에서 문제를 빠르게 진단하려면 여전히 기본 제공되는 경량 CLI 툴이 필요합니다. 특히 sar, vmstat, iostat은 설치가 간단하고 오버헤드가 거의 없어 장애 상황이나 긴급 점검 시 즉시 활용할 수 있습니다.
이 세 가지 도구는 HPC 노드의 CPU, 메모리, I/O 성능 상태를 빠르게 요약해주므로, Slurm 잡 실행 중 발생하는 병목을 초기에 파악하는 데 매우 유용합니다.
sar(System Activity Report)
sar는 sysstat 패키지에 포함된 도구로, CPU·메모리·I/O·네트워크를 장기간 기록하고 분석하는 데 특화되어 있습니다.
주요 기능
- CPU 사용률, 인터럽트 발생 빈도 확인
- 메모리 및 스왑 사용량 모니터링
- 블록 디바이스 I/O 추적
- 네트워크 트래픽 측정
활용 예시
# 1초 간격으로 5회 CPU 사용률 확인
sar -u 1 5
# 메모리 사용 현황 확인
sar -r 1 3
# 블록 디바이스 I/O 통계 확인
sar -d 1 3sar는 기본적으로 데이터를 /var/log/sa/에 저장하기 때문에, 과거 데이터를 불러와 특정 시점의 성능 문제를 재현하는 데에도 사용할 수 있습니다. HPC에서는 잡 실행 시간과 sar 로그를 대조하여, 특정 시점에 I/O 지연이나 CPU 스파이크가 있었는지 확인할 수 있습니다.
vmstat(Virtual Memory Statistics)
vmstat은 이름처럼 메모리 관련 지표뿐 아니라 CPU, 프로세스, I/O까지 종합적으로 보여줍니다.
주요 컬럼 해석
- procs: 실행 중·대기 중 프로세스 수
- memory: 사용 가능한 메모리, 캐시, 스왑
- cpu: 사용자 모드·시스템 모드·대기 시간 비율
- io: 블록 장치 읽기·쓰기 요청
활용 예시
# 2초 간격으로 시스템 상태 출력
vmstat 2
# 10회만 출력
vmstat 2 10HPC 환경에서 자주 보는 항목은 **r 값(런큐 길이)**과 **wa 값(I/O wait 비율)**입니다. r 값이 CPU 코어 수를 초과하면 스케줄링 병목을 의미하고, wa 값이 높으면 디스크 I/O 지연을 의미합니다. GPU 잡을 돌릴 때 CPU는 한가한데 전체 속도가 느리다면, vmstat의 wa 값을 반드시 확인해야 합니다.
iostat(I/O Statistics)
iostat은 I/O 장치별 성능을 세밀하게 보여주는 도구입니다. HPC 환경에서는 병렬 파일시스템(Lustre, BeeGFS, Ceph)이나 NVMe SSD의 성능을 검증할 때 특히 많이 활용합니다.
주요 지표
- r/s, w/s: 초당 읽기·쓰기 요청 수
- rkB/s, wkB/s: 초당 읽기·쓰기 데이터량
- await: 평균 I/O 대기 시간
- %util: 장치 사용률(100%에 가까우면 병목 발생)
활용 예시
# 디스크별 I/O 성능 모니터링 (2초 간격)
iostat -x 2만약 %util이 100%에 근접한다면, 해당 장치가 포화 상태임을 의미합니다. HPC에서는 특정 노드의 NVMe가 계속 100%라면, 잡 스케줄링 정책을 조정하거나 병렬 파일시스템으로 I/O를 분산시켜야 합니다.
세 가지 도구의 상호 보완적 사용
- sar: 장기간 기록 및 분석에 강함 → “지난주 특정 잡 실행 당시 CPU가 얼마나 바빴나?” 같은 질문에 답변
- vmstat: 실시간 종합 모니터링 → “지금 이 순간 CPU, 메모리, I/O가 어떻게 움직이고 있나?” 확인
- iostat: 디스크 장치별 상세 분석 → “특정 NVMe가 포화 상태인가?“를 즉시 판단
HPC 운영 사례
한 반도체 설계 HPC 클러스터에서 EDA 워크로드가 자주 지연되는 문제가 있었습니다.
- vmstat으로 확인한 결과, CPU 사용률은 낮았으나 wa 값이 평균 40% 이상으로 비정상적으로 높았습니다.
- iostat으로 장치별 성능을 확인했더니, 특정 Lustre OST 장치의 %util 값이 99%에 도달해 있었습니다.
- 이후 sar -d 로그를 확인해보니, 매일 특정 시간대에 같은 OST에 집중적인 접근이 발생하고 있음을 확인했습니다.
이 결과를 토대로 운영자는 I/O 집중 잡을 다른 시간대에 분산 스케줄링하고, Lustre OST 간 부하를 균형 있게 배분했습니다. 그 결과 잡 평균 대기 시간이 크게 줄어들었습니다.
실무 팁과 주의사항
- HPC 클러스터에서는 Slurm prolog/epilog 스크립트에 sar/vmstat/iostat 실행을 넣어 잡 실행 중 시스템 상태를 자동 기록하는 방식을 권장합니다.
- sar 로그는 장기 보관이 가능하므로, 과거 장애 상황을 재현할 때 매우 유용합니다.
- vmstat은 CPU wait를, iostat은 장치 util을 동시에 확인하여 CPU vs I/O 병목을 정확히 구분하시는 것이 좋습니다.
- 세 도구 모두 오버헤드가 작아 프로덕션 환경에서 안전하게 사용할 수 있지만, 측정 주기를 지나치게 짧게 설정하면 로그가 과도하게 쌓일 수 있으니 주의가 필요합니다.
정리하며
현대 HPC 모니터링은 Grafana, OpenTelemetry 같은 고급 플랫폼으로 점점 이동하고 있습니다. 그러나 긴급 상황에서 몇 초 안에 시스템 상태를 확인하려면 여전히 sar, vmstat, iostat 같은 전통적 CLI 도구가 가장 빠르고 확실한 해결책입니다.
운영자는 이 세 가지를 숙달해두셔야, 잡이 지연되거나 GPU 활용률이 떨어질 때 신속하게 CPU, 메모리, I/O 중 어느 부분이 문제인지 판단할 수 있습니다. 결국 이 작은 도구들이 HPC 운영의 안정성과 신뢰성을 지탱하는 중요한 기반이 됩니다.