517. 거대 페이지 (Huge Page)

핵심 인사이트 (3줄 요약)

1. 본질: 거대 페이지 (Huge Page)는 기본 4KB 페이지보다 훨씬 큰 2MB·1GB 단위로 가상 메모리를 매핑해, 같은 TLB (Translation Lookaside Buffer) 엔트리로 더 넓은 주소 공간을 덮게 만드는 번역 단위 최적화다.
2. 가치: 메모리 집약 워크로드에서는 TLB 미스, 페이지 워크 (Page Walk), 페이지 테이블 메모리 사용량을 함께 줄여 데이터베이스, 하이퍼바이저, 인공지능 추론의 실효 성능을 끌어올린다.
3. 판단 포인트: 성능 이득은 "페이지가 크다"보다 "크게 묶어도 되는 메모리인가"에 달려 있으며, 메모리 파편화, 압축·병합 지연, NUMA (Non-Uniform Memory Access) 배치, Copy-on-Write 분할 비용을 함께 봐야 한다.

Ⅰ. 개요 및 필요성

거대 페이지는 운영체제가 기본 페이지보다 훨씬 큰 단위로 가상 주소를 물리 메모리에 매핑하는 방식이다. 보통 범용 운영체제는 4KB 페이지를 기본으로 쓰지만, 현대 서버는 수백 GB에서 수 TB까지 메모리를 다루므로 이 단위가 너무 잘게 느껴질 때가 많다. 이때 CPU (Central Processing Unit)는 실제 계산보다 주소 변환용 캐시를 찾고, 없으면 페이지 테이블을 여러 단계 따라가는 데 더 많은 시간을 쓰게 된다.

문제의 본질은 메모리 용량 증가 속도와 TLB 커버리지 증가 속도가 같지 않다는 점이다. 예를 들어 TLB 엔트리 수가 같다면 4KB 페이지는 몇 MB 수준만 덮지만, 2MB 거대 페이지는 같은 엔트리로 수 GB까지 덮을 수 있다. 특히 대형 버퍼 풀, 분석 엔진, 가상 머신 메모리처럼 넓고 연속적인 영역을 오래 쓰는 워크로드에서는 "데이터를 읽기 전 주소 변환부터 막히는" 현상이 더 두드러진다.

이 그림은 왜 거대 페이지가 TLB 문제를 먼저 겨냥하는지 보여준다.

┌──────────────────────────────────────────────────────────────────────┐
│              페이지가 커질수록 같은 TLB가 덮는 범위가 넓어진다       │
├──────────────────────────────────────────────────────────────────────┤
│ TLB entries = 2,048 가정                                             │
│                                                                      │
│ 4KB page   : 2,048 × 4KB   =      8MB                                │
│ 2MB page   : 2,048 × 2MB   =      4GB                                │
│ 1GB page   : 2,048 × 1GB   =      2TB                                │
│                                                                      │
│ 메모리는 TB급으로 커졌는데 TLB 엔트리 수는 크게 늘지 않는다         │
│ → 페이지를 크게 묶지 않으면 주소 변환이 먼저 병목이 된다            │
└──────────────────────────────────────────────────────────────────────┘

즉 거대 페이지는 메모리를 더 많이 만드는 기술이 아니라, 주소 변환의 관리 단위를 굵게 만들어 번역 비용을 줄이는 기술이다. 이 관점을 잡아야 이후의 TLB, 가상화, 메모리 파편화 이슈가 하나로 묶인다.

• 📢 섹션 요약 비유: 거대 페이지는 도시 지도를 작은 블록 단위 대신 큰 구역 단위로 보는 것과 같다. 골목 하나하나는 덜 자세하지만, 넓은 지역을 훨씬 빨리 찾을 수 있다.

Ⅱ. 아키텍처 및 핵심 원리

거대 페이지의 핵심은 번역 계층을 일부 건너뛰고, 한 번의 번역으로 더 많은 바이트를 대표하게 만드는 것이다. x86-64 4단계 페이지 테이블을 기준으로 보면 4KB 페이지는 PML4 → PDPT → PD → PT → Frame 경로를 따라가지만, 2MB 페이지는 PD 엔트리에서 PS (Page Size) 비트를 세워 PT 단계를 건너뛴다. 1GB 페이지는 PDPT 단계에서 바로 큰 프레임을 가리켜 하위 테이블을 더 많이 생략한다.

이 차이는 페이지 워크 횟수와 페이지 테이블 메모리 사용량을 동시에 바꾼다. 예를 들어 1GB 영역을 4KB 페이지로 매핑하면 262,144개의 엔트리가 필요하지만, 2MB 거대 페이지면 512개, 1GB 거대 페이지면 사실상 1개 엔트리로 표현된다. 따라서 거대 페이지는 "TLB 미스가 줄어든다"에 그치지 않고, 미스가 났을 때 뒤지는 장부 자체도 훨씬 얇아진다.

운영체제는 보통 두 방식으로 이를 제공한다. 하나는 부팅 시점이나 관리자가 미리 큰 페이지 풀을 예약해 두는 명시적 거대 페이지이고, 다른 하나는 THP (Transparent Huge Pages)처럼 커널이 4KB 페이지들을 관찰하다가 조건이 맞으면 자동으로 2MB 페이지로 승격하는 방식이다. 전자는 예측 가능성이 높고, 후자는 쓰기 쉽지만 병합·압축 시점의 지연 변동을 동반할 수 있다.

핵심 공식은 단순하다. TLB Reach = TLB 엔트리 수 × 페이지 크기. 거대 페이지는 이 식의 오른쪽 항 하나를 크게 만들어, 주소 변환 구조 전체를 유리하게 바꾼다.

• 📢 섹션 요약 비유: 거대 페이지는 서류철을 낱장 대신 묶음 단위로 관리하는 것과 같다. 찾을 때는 빨라지지만, 중간 한 장만 수정하려면 다시 묶음을 풀어야 할 수 있다.

Ⅲ. 비교 및 연결

거대 페이지는 "무조건 큰 페이지가 최고"라는 단순 선택이 아니다. 실제로는 기본 4KB, 자동 거대 페이지, 명시적 거대 페이지가 서로 다른 장단점을 가진다. 중요한 비교 축은 성능 그 자체보다 예측 가능성, 메모리 유연성, 운영 복잡도다.

이 주제는 가상화와 특히 강하게 연결된다. EPT (Extended Page Tables)나 NPT (Nested Page Tables)를 쓰는 가상 머신은 게스트와 호스트 양쪽 번역 계층을 함께 지나가므로, 기본 페이지만 고집하면 중첩 페이지 워크 비용이 빠르게 커진다. 반대로 게스트 메모리와 호스트 메모리 모두에서 거대 페이지를 잘 쓰면, 번역 계층이 얕아져 가상화 오버헤드를 눈에 띄게 줄일 수 있다.

또한 NUMA 환경에서는 "큰 페이지"보다 "가까운 큰 페이지"가 더 중요하다. 2MB 페이지라도 다른 소켓의 원격 메모리에 놓이면, TLB 이득을 일부 얻더라도 원격 접근 지연이 상쇄할 수 있다. 즉 거대 페이지는 TLB 기술이면서 동시에 메모리 배치 기술이기도 하다.

• 📢 섹션 요약 비유: 4KB는 낱권 책, THP는 사서가 자동으로 묶어 주는 합본, 명시적 거대 페이지는 출판사에서 미리 전집 세트를 주문하는 것과 같다. 무엇이 좋은지는 독서 방식과 보관 공간에 따라 달라진다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 거대 페이지는 "켜면 빨라진다"보다 "어떤 메모리 영역에만 크게 묶는 것이 맞는가"로 접근해야 한다. 대형 데이터베이스 버퍼 캐시, 인메모리 키-값 저장소, 하이퍼바이저의 게스트 메모리, 장기 유지되는 분석 배열처럼 크고 오래 살아 있는 영역은 대표적인 적합 대상이다. 반대로 fork()가 잦거나, Copy-on-Write가 빈번하거나, 메모리 점유가 요동치는 서비스에서는 거대 페이지 분할과 회수가 오히려 지연의 원인이 될 수 있다.

특히 지연 민감형 서비스에서는 THP를 기본으로 켜기보다 madvise 방식이나 명시적 거대 페이지를 검토하는 경우가 많다. 이유는 처리량 평균값보다 tail latency가 더 중요하기 때문이다. 자동 병합 스레드가 백그라운드에서 메모리를 압축하거나 거대 페이지 승격을 시도하는 순간, 예측하지 못한 지연 스파이크가 나타날 수 있다.

판단 체크리스트

1. dTLB-load-misses, page walk 관련 성능 카운터가 실제 병목으로 확인되는가?
2. 대상 메모리 영역이 크고, 오래 살아 있고, 연속 접근 비중이 높은가?
3. NUMA 노드 배치와 부팅 시점 예약으로 충분한 연속 메모리를 확보할 수 있는가?
4. 스와핑, 메모리 풍선 확장, Copy-on-Write, 스냅샷 분할 비용을 감당할 수 있는가?
5. 평균 처리량이 중요한가, 아니면 예측 가능한 지연이 더 중요한가?

피해야 할 안티패턴

• 메모리 파편화가 심한 장시간 가동 서버에 1GB 페이지를 즉흥적으로 강제하는 운영

• THP를 켠 뒤 지연 스파이크 원인을 측정하지 않고 "커널이 알아서 해 줄 것"이라 가정하는 판단

• 거대 페이지 이득만 보고 NUMA 원격 배치나 Copy-on-Write 분할 비용을 무시하는 설계

• 📢 섹션 요약 비유: 거대 페이지 적용은 큰 화물 컨테이너를 쓰는 물류 설계와 같다. 장기적으로 대량 화물에는 유리하지만, 자주 뜯고 다시 싸야 하는 소포 업무에는 오히려 불편하다.

Ⅴ. 기대효과 및 결론

거대 페이지를 올바르게 적용하면 CPU가 주소 변환에 허비하는 시간을 줄이고, 페이지 테이블 메타데이터도 줄여 메모리 계층 전체를 더 효율적으로 쓸 수 있다. 그래서 같은 코어 수, 같은 메모리 용량에서도 데이터베이스 쿼리 처리량, 가상 머신 밀도, 분석 워크로드의 실효 처리량이 눈에 띄게 좋아질 수 있다.

하지만 거대 페이지는 만능 스위치가 아니다. 페이지가 커질수록 보호 단위, 스와핑 단위, 분할 비용도 함께 커지므로 유연성은 줄어든다. 앞으로의 방향은 "모든 곳을 크게"가 아니라, 혼합 페이지 크기 정책, 자동 승격·강등 개선, 티어드 메모리와 CXL (Compute Express Link) 환경을 고려한 영역별 페이지 크기 최적화로 갈 가능성이 크다.

결론적으로 거대 페이지는 메모리 용량 기술이 아니라 주소 변환 비용을 다루는 성능 기술이다. 이 개념을 "TLB reach를 넓히는 레버"로 기억하면, 왜 어떤 시스템은 거대 페이지로 빨라지고 어떤 시스템은 오히려 운영이 어려워지는지 자연스럽게 설명할 수 있다.

• 📢 섹션 요약 비유: 거대 페이지는 창고 선반을 큰 박스 중심으로 다시 짜는 일과 같다. 자주 나가는 대량 물건은 빨라지지만, 작은 물건까지 전부 큰 박스에 넣으면 오히려 찾기 불편해진다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

기본 4KB 페이지 중심 가상 메모리
        │
        ▼
메모리 용량 증가 · TLB reach 한계
        │
        ▼
거대 페이지 (2MB / 1GB)
        │
        ├─▶ THP (Transparent Huge Pages)
        ├─▶ 명시적 HugeTLBfs 예약
        │
        ▼
가상화 EPT / NPT 최적화
        │
        ▼
혼합 페이지 크기 정책 · 티어드 메모리 · CXL 시대의 영역별 최적화

이 흐름은 "세밀한 페이지 관리"에서 출발해, "번역 비용 절감"을 거쳐, 결국 워크로드별로 페이지 크기를 다르게 쓰는 방향으로 발전하는 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

1. 거대 페이지는 작은 공책 여러 권 대신 큰 스케치북 한 권으로 그림을 정리하는 것과 같아요.
2. 한 번에 넓은 내용을 볼 수 있어서 찾기는 빨라지지만, 한쪽 구석만 고치려면 조금 번거로워질 수 있어요.
3. 그래서 컴퓨터는 큰 그림을 오래 볼 때만 큰 스케치북을 쓰는 게 더 똑똑하답니다.