커널 이벤트 분석이 필요한 이유
HPC 환경에서는 CPU, GPU, 네트워크, 스토리지가 동시에 얽혀 복잡하게 동작합니다. 그런데 단순히 top이나 htop으로 확인하는 지표만으로는 문제의 본질을 파악하기 어렵습니다. GPU가 대기 상태로 멈추고, CPU는 낮은 사용률을 보이는데 애플리케이션은 여전히 느린 경우가 대표적입니다. 실제 원인은 커널 내부에서 발생하는 시스템 콜 지연, 캐시 미스, 인터럽트 과부하, NUMA 원거리 메모리 접근과 같은 보이지 않는 이벤트일 수 있습니다.
이런 상황에서는 단순 모니터링이 아니라 커널 이벤트 추적이 필요합니다. 리눅스에서 대표적인 도구가 바로 perf와 eBPF입니다. 두 가지는 각자 강점이 다르지만, 함께 활용하면 HPC 운영자가 성능 병목을 정밀하게 진단하고 개선책으로 연결할 수 있습니다.
perf: CPU 중심 분석의 정석
perf는 리눅스 커널에 기본 포함된 성능 분석 도구로, 하드웨어 성능 카운터를 기반으로 다양한 이벤트를 수집합니다. CPU 사이클, 캐시 미스율, 브랜치 예측 실패, 함수 호출 스택 등 CPU 성능 관련 지표를 가장 신뢰성 있게 확인할 수 있는 툴입니다.
주요 기능
- perf stat: IPC(Instruction Per Cycle), 캐시 미스율, 사이클 수 등 요약 지표 제공
- perf record/report: 함수 호출 스택 기록 및 분석, 병목 구간 추적
- perf top: 실시간으로 CPU를 많이 소모하는 함수 확인
- perf sched: 스케줄링 지연(latency) 분석
- perf c2c: NUMA 간 캐시 충돌(cache-to-cache) 이벤트 추적
예시 활용
# CPU 이벤트 측정 (5초)
sudo perf stat -a sleep 5
# 호출 스택 기록 및 분석
sudo perf record -F 99 -a -g -- ./hpc_app
sudo perf report
# 실시간 성능 상위 함수 확인
sudo perf top실제 HPC 운영에서는 perf stat으로 큰 그림을 먼저 보고, perf record/report으로 특정 함수나 루틴에서 CPU 사이클이 집중되는 지점을 파악하는 방식으로 자주 활용됩니다.
eBPF: 차세대 실시간 커널 관측 도구
**eBPF (extended Berkeley Packet Filter)**는 최신 리눅스 커널(5.x~6.x)에서 핵심 관측 기술로 자리잡았습니다. 원래 네트워크 패킷 필터링에서 시작했지만, 이제는 시스템 콜, 파일 I/O, 네트워크 지연, NUMA 접근 등 커널 전반의 이벤트를 실시간으로 추적할 수 있습니다.
장점
- 낮은 오버헤드 – 프로덕션 환경에서도 안전하게 사용 가능
- 유연성 – 특정 이벤트만 선택적으로 추적 가능
- 확장성 – bcc, bpftrace 같은 고수준 툴킷과 결합해 쉽게 분석 가능
HPC 환경에서 자주 쓰는 bcc 툴
- execsnoop: 프로세스 실행 이벤트 추적
- biosnoop: 블록 I/O 요청 분석
- tcptop: TCP 연결 초당 트래픽 모니터링
- cachestat: 페이지 캐시 효율 확인
- numa_balancer: NUMA 메모리 접근 패턴 분석
간단한 예시
# 프로세스별 read() 호출 횟수 카운트
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_read { @[comm] = count(); }'
# TCP 재전송 이벤트 모니터링
sudo bpftrace -e 'tracepoint:tcp:tcp_retransmit_skb { @[comm] = count(); }'이처럼 몇 줄만 작성해도 I/O 집중 구간이나 네트워크 병목을 실시간으로 확인할 수 있습니다.
perf와 eBPF 비교
| 구분 | perf | eBPF |
| 기본 원리 | CPU 하드웨어 성능 카운터 기반 | 커널에 안전하게 삽입되는 BPF 프로그램 기반 |
| 강점 | 신뢰성, 오랜 기간 검증, CPU 이벤트 분석 강력 | 낮은 오버헤드, 실시간 추적, 이벤트 범위 확장 |
| 분석 범위 | CPU 사이클, 캐시 미스, 함수 호출 스택, 스케줄링 지연 | 시스템 콜, 파일 I/O, 네트워크 지연, NUMA 접근 등 |
| 활용 사례 | MPI 통신 루틴 분석, BLAS 최적화, CPU IPC 개선 | Lustre 메타데이터 병목, TCP 재전송, GPU ↔ CPU DMA 지연 |
| 단점 | 이벤트 종류 제한, 고빈도 샘플링 시 부하 | 러닝커브 높음, 커널 버전 의존성 큼 |
| HPC 운영에서의 역할 | 전체 성능 병목 후보를 빠르게 좁힘 | 특정 지점을 정밀하게 추적하고 원인 규명 |
HPC 운영 사례
한 AI 학습용 HPC 클러스터에서 GPU 활용률이 낮아지는 현상이 있었습니다.
- perf stat 결과, CPU는 한가했지만 L3 캐시 미스율이 비정상적으로 높았습니다.
- perf record/report 분석으로 데이터 로딩 루틴이 많은 CPU 사이클을 소모하고 있다는 사실이 확인되었습니다.
- eBPF(bpftrace) 추적 결과, 해당 루틴이 NUMA 원거리 메모리에 반복적으로 접근하는 것이 원인이었습니다.
- 운영자는 numactl --membind를 사용해 데이터 로더를 GPU와 동일 NUMA 노드에 바인딩했습니다.
그 결과, 데이터 로딩 시간이 20% 단축, GPU 활용률은 15% 개선, 전체 학습 속도는 약 8% 향상되었습니다.
또 다른 사례로, Lustre 파일시스템에서 eBPF 기반 I/O 추적을 통해 특정 컨테이너가 메타데이터 서버를 과도하게 점유한다는 사실을 발견하고, 스케줄러 정책을 조정하여 안정성을 확보한 경험도 있습니다.
실무 팁과 주의사항
- perf는 샘플링 주기를 지나치게 높이면 시스템에 부담을 줄 수 있으므로 적절히 조정해야 합니다.
- eBPF는 커널 버전 의존성이 있으므로, HPC 환경에서는 가급적 최신 5.x~6.x 커널을 유지하는 것이 바람직합니다.
- 두 도구에서 얻은 결과는 반드시 애플리케이션 로그, Slurm 잡 기록, 모니터링 지표와 교차 검증해야 정확도를 확보할 수 있습니다.
- Slurm 잡 스크립트에 perf/eBPF 실행을 포함하면 워크로드별 성능 데이터를 자동 수집할 수 있어 운영 효율이 크게 높아집니다.
- GPU 연계 워크로드에서는 CPU 이벤트 분석과 함께 PCIe/NVLink 전송 지연도 확인해야 전체 병목을 제대로 파악할 수 있습니다.
정리하며
HPC 환경에서의 성능 병목은 단순한 CPU 사용률 수치만으로 설명되지 않습니다. 커널 이벤트 수준의 정밀 분석이 필요하며, 이를 위해 perf와 eBPF는 반드시 갖추어야 할 도구입니다. perf는 CPU 중심의 전통적 분석 도구로 신뢰성이 높고, eBPF는 최신 HPC 환경에서 세부 이벤트를 실시간으로 추적할 수 있는 확장성을 제공합니다. 두 가지를 조합하면 HPC 운영자는 보이지 않는 병목을 정확히 찾아내고, NUMA 최적화·메모리 정책 조정·I/O 정책 변경 같은 실질적 개선으로 이어갈 수 있습니다.