기타 Lobsters · 2일 전

1985년에 멈춘 메모리 규격, '대용량 페이지'로 바꾸면 속도 3배 빨라진다?

핵심 요약
  • x86 아키텍처는 1985년 이후 4KB 기본 페이지 크기를 고수해 최신 CPU에서도 대용량 작업 시 캐시 병목 현상이 발생합니다.
  • 실제 벤치마크 결과 2MB 크기의 대용량 페이지(Huge Pages)를 사용할 경우 무작위 메모리 접근 속도가 약 2.9배 빨라졌습니다.
  • 과거 메모리 낭비와 호환성 문제가 있었으나, 현재는 메모리 할당자 지원과 커널 설정 개선으로 안정적인 성능 개선 수단이 되었습니다.
요약 컴퓨터의 가상 메모리 주소를 물리 주소로 변환하는 데 사용되는 x86 아키텍처의 기본 페이지 크기는 1985년 '인텔 386' CPU가 출시된 이래 지금까지도 4 KiB를 유지하고 있습니다. 문제는 현대의 CPU에 탑재된 주소 변환 캐시(TLB, Translation Lookaside Buffer) 크기가 매우 작다는 점입니다. 최신 프로세서인 AMD Zen 4조차 L2 TLB 항목이 3,072개에 불과해, 약 12 MiB 이상의 작업 세트(working set)를 다루는 순간 캐시 누락(TLB 미스)이 발생하며 메모리 접근 지연이 크게 늘어납니다.\n\n이에 따라 훨씬 큰 단위의 메모리 페이지(휴지 페이지, Huge Pages)를 사용하는 기법이 다시 주목받고 있습니다. 실제로 구글은 2021년 자체 메모리 할당자(TCMalloc)에 2 MiB 크기의 휴지 페이지를 적극 활용하는 'Temeraire' 시스템을 도입해 자사 서버 전반의 초당 처리량(RPS)을 7% 끌어올렸다고 발표한 바 있습니다. 블로그 작성자가 인텔 타이거레이크(i5-1135G7) 환경에서 4 GiB 메모리에 무작위로 접근하는 테스트를 진행한 결과, 2 MiB 휴지 페이지를 썼을 때 기존 4 KiB 대비 속도가 약 2.9배(1 GiB 페이지는 3.1배) 빨라졌습니다.\n\n하지만 대용량 페이지가 무조건 장점만 있는 것은 아닙니다. 리눅스 커널이 처음 투명한 대용량 페이지(THP, Transparent Huge Pages)를 도입했을 당시에는 모든 프로세스에 강제 활성화되어 있어 메모리 단편화로 인한 낭비, 백그라운드 작업으로 인한 레이턴시 급증 등 심각한 성능 저하를 유발했습니다. 또한 4 KiB 가정에 얽매인 수많은 소프트웨어와의 호환성 문제도 발목을 잡았습니다. 현재는 애플리케이션이 직접 시스템 콜(madvise)을 통해 명시적으로 휴지 페이지 사용을 요청하도록 기본 정책이 바뀌었고, jemalloc이나 glibc malloc 등 주요 할당자들의 지원도 개선되어 대용량 RAM을 다루는 소프트웨어라면 휴지 페이지 도입이 손쉬운 성능 향상 수단이 될 수 있다고 작성자는 정리했습니다.
Sponsored · 광고