HPC & GPU Engineering/AI Infrastructure Engineer

[HPC/GPU 클러스터 운영 Linux Deep Dive 4편] HugePages와 메모리 관리 최적화 – HPC 워크로드의 메모리 효율 극대화

ygtoken 2025. 8. 12. 10:58
728x90

왜 HugePages가 중요한가

 
리눅스 메모리 관리에서 기본 페이지 크기는 보통 4KB입니다. 이는 범용 워크로드에는 문제가 없지만, HPC나 대규모 GPU 연계 환경에서는 페이지 테이블의 크기와 TLB(Translation Lookaside Buffer) 미스율이 성능에 영향을 미칩니다.
특히 MPI 기반 대규모 계산, 딥러닝 트레이닝, In-memory DB, 대규모 데이터 분석 등은 대량의 연속 메모리 접근이 발생합니다. 이때 작은 페이지를 많이 관리하면 커널이 유지해야 하는 페이지 테이블 엔트리가 방대해져 오버헤드가 커집니다.
 
HugePages는 2MB 또는 1GB와 같은 큰 페이지 크기를 사용해 페이지 수를 줄이고, TLB 효율을 높이며, 메모리 접근 지연을 줄이는 방법입니다.
 
 

HugePages의 구조와 종류

 
리눅스에서는 크게 두 가지 방식으로 HugePages를 제공합니다.

종류설명장점단점
Static HugePages (Persistent)부팅 시 고정된 수의 큰 페이지를 예약예측 가능, 성능 안정성유연성 부족, 예약 크기 변경 시 재부팅 필요
Transparent HugePages (THP)커널이 자동으로 페이지를 병합설정 편의성, 동적 관리커널 스케줄링 개입, 일부 워크로드에서 성능 저하 가능
HPC에서는 대부분 Static HugePages를 권장합니다. THP는 동적 변환 과정에서 지연이 발생할 수 있고, 예측 가능한 성능이 중요하기 때문입니다.

 
 

메모리 접근 흐름 비교

 
기본 페이지(4KB)와 HugePages(2MB) 사용 시의 TLB 엔트리 수와 메모리 접근 경로를 비교하면 다음과 같습니다.

페이지 크기1GB 메모리 당 페이지 수TLB 엔트리 요구량(예시)
4KB262,144262,144개
2MB512512개
1GB11개

이 차이는 대규모 데이터 처리에서 캐시 효율TLB 히트율 향상으로 직결됩니다.
 
 

그림 1) HugePages 크기별 TLB 영향 비교 (4KB vs 2MB vs 1GB)

 

HPC 환경에서 HugePages 설정

 
HPC 클러스터에서는 Slurm, Kubernetes 등 스케줄러와 연계해 HugePages를 미리 확보해 두는 것이 일반적입니다.
 

1) 현재 HugePages 설정 확인

grep Huge /proc/meminfo

 

2) Static HugePages 설정 예시

(예: 2MB 페이지를 2048개 예약 = 4GB)

echo 2048 > /proc/sys/vm/nr_hugepages

 
또는 /etc/sysctl.conf에 영구 반영:

vm.nr_hugepages=2048

 

3) 특정 NUMA 노드에 HugePages 할당

 
NUMA 환경에서 로컬 메모리 바인딩을 위해:

echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages

 

4) Transparent HugePages 관리

 
THP 비활성화 (HPC 권장 설정):

echo never > /sys/kernel/mm/transparent_hugepage/enabled

 
 

그림 2) NUMA 연계 – 노드별 HugePages 예약/바인딩/로컬 할당

 

실제 적용 사례

 
삼성전자 DS부문 HPC 클러스터에서 대규모 EDA(전자설계자동화) 시뮬레이션에 HugePages를 적용한 사례가 있습니다.
기존 4KB 페이지 기반 메모리 할당에서는 CPU TLB miss가 빈번하게 발생했고, 작업당 평균 810%의 실행 시간 지연이 있었습니다.
Static HugePages(2MB)로 전환 후, TLB miss 비율이 절반 이하로 줄고, 실행 시간이 평균 79% 단축되었습니다.
 
GPU 서버에서도 PyTorch + NCCL 기반 멀티 GPU 학습 시, CPU ↔ GPU 데이터 전송 버퍼를 HugePages에 매핑해 I/O 레이턴시를 줄인 사례가 있습니다.
 
 

장점과 단점

장점

  • TLB 효율 향상: 큰 페이지로 TLB miss 감소
  • 성능 안정성: HPC 반복 작업에서 일정한 메모리 접근 속도
  • NUMA 최적화 용이: 로컬 노드에 큰 페이지 예약 가능

단점

  • 메모리 단편화 가능성: 장기간 운영 시 연속 메모리 확보가 어려움
  • 유연성 부족: Static 방식은 예약 크기 변경 시 재부팅 필요
  • 일부 워크로드 비호환: 특정 앱은 HugePages를 지원하지 않음

 
 

실무 팁과 주의사항

  • HPC 운영 전, 애플리케이션이 HugePages를 지원하는지 확인
  • NUMA 노드별로 필요한 양만큼만 예약 (과다 예약은 메모리 낭비)
  • THP는 HPC에서는 꺼두고, 필요 시 실험적으로만 사용
  • Kubernetes 환경에서는 spec.containers[].resources.limits.hugepages-2Mi 형태로 리소스 요청
  • Slurm에서는 --mem과 함께 --constraint=hugepages 등 노드 속성을 활용
# Slurm에서 HugePages 예약 노드에 작업 실행 예시
srun --constraint=hugepages --mem=64G ./hpc_job

 

정리하며

HugePages는 HPC 워크로드의 메모리 관리 최적화에서 필수적인 기술입니다.
특히 대규모 연속 메모리 접근이 잦은 AI 학습, EDA, CFD, 빅데이터 분석에서 HugePages 적용만으로도 TLB 효율이 개선되고 성능이 안정화됩니다.
운영자는 워크로드 특성과 NUMA 구조를 고려해 페이지 크기, 예약 방식, 바인딩 전략을 종합적으로 설계해야 합니다.
 

728x90