페이지 테이블 메모리 오버헤드란 무엇인가요
우리 컴퓨터가 동시에 여러 프로그램을 실행하고 수많은 데이터를 처리할 때, 마치 마법처럼 모든 것이 순조롭게 돌아가는 것처럼 보입니다. 하지만 이 모든 과정 뒤에는 운영체제의 정교한 메모리 관리 기술이 숨어 있습니다. 그중에서도 가상 메모리와 페이지 테이블은 핵심적인 역할을 담당합니다.
가상 메모리는 각 프로그램이 실제 물리 메모리의 크기에 구애받지 않고 마치 자신만의 거대한 메모리 공간을 가지고 있는 것처럼 느끼게 해주는 기술입니다. 프로그램은 가상 주소를 사용하고, 운영체제는 이 가상 주소를 실제 물리 메모리의 주소로 변환해줍니다. 이 변환 과정을 담당하는 것이 바로 페이지 테이블입니다.
페이지 테이블은 일종의 ‘주소록’이라고 생각할 수 있습니다. 프로그램의 가상 메모리 공간을 일정한 크기의 ‘페이지’ 단위로 나누고, 이 페이지들이 실제 물리 메모리의 어느 ‘프레임’에 저장되어 있는지 기록해둡니다. 즉, 페이지 테이블은 가상 주소와 물리 주소를 매핑하는 정보를 담고 있는 자료구조입니다.
그런데 이 페이지 테이블도 결국 메모리에 저장되어야 합니다. 수많은 프로그램이 실행되고, 각 프로그램이 방대한 가상 메모리 공간을 가질수록 이 페이지 테이블의 크기 역시 커지게 됩니다. 이렇게 페이지 테이블 자체를 저장하기 위해 사용되는 메모리 공간을 페이지 테이블 메모리 오버헤드라고 부릅니다. 이는 실제 프로그램 데이터나 코드 저장을 위해 사용되는 메모리가 아니라, 메모리 관리를 위해 ‘추가적으로’ 필요한 메모리라는 점에서 오버헤드(부담)라고 할 수 있습니다.
페이지 테이블 오버헤드는 얼마나 발생할까요
페이지 테이블 오버헤드의 크기는 여러 요인에 따라 달라집니다. 주요 요인으로는 페이지 크기, 시스템 아키텍처(32비트/64비트), 그리고 실행 중인 프로세스의 수 등이 있습니다.
페이지 크기와 오버헤드
대부분의 운영체제는 4KB(킬로바이트)를 기본 페이지 크기로 사용합니다. 예를 들어, 64비트 시스템에서 각 페이지 테이블 엔트리(PTE)가 8바이트(64비트 주소를 저장하기 위함)라고 가정해봅시다.
- 단일 프로세스의 가상 주소 공간
만약 한 프로세스가 4GB(기가바이트)의 가상 메모리 공간을 모두 사용한다고 가정하면, 필요한 페이지 엔트리의 수는 다음과 같습니다:
4GB / 4KB = 4 1024 1024 KB / 4 KB = 1,048,576개 (약 100만 개)
각 엔트리가 8바이트이므로, 이 프로세스의 페이지 테이블이 차지하는 메모리 오버헤드는 다음과 같습니다:
1,048,576 8 바이트 = 8,388,608 바이트 = 8MB (메가바이트)
단일 프로세스만으로도 8MB의 메모리가 페이지 테이블을 위해 사용되는 것입니다. 이는 전체 시스템 메모리에 비하면 작을 수 있지만, 여러 프로세스가 동시에 실행될 경우 이 오버헤드는 상당히 커질 수 있습니다.
- 다중 프로세스 환경
만약 100개의 프로세스가 동시에 실행되고 각 프로세스가 4GB의 가상 메모리를 사용한다면, 이론적으로는 100 8MB = 800MB의 메모리가 페이지 테이블 오버헤드로 사용될 수 있습니다. 물론 실제로는 모든 프로세스가 4GB 전체를 사용하는 경우는 드물고, 운영체제가 오버헤드를 줄이기 위한 다양한 기술을 사용하므로 이보다는 적게 발생합니다.
시스템 아키텍처의 영향
- 32비트 시스템
32비트 시스템은 최대 4GB의 가상 주소 공간을 가집니다. 페이지 테이블 엔트리는 보통 4바이트입니다. 이 경우, 4GB 가상 공간에 대한 페이지 테이블은 4GB / 4KB * 4바이트 = 4MB의 오버헤드를 가집니다.
- 64비트 시스템
64비트 시스템은 훨씬 더 큰 가상 주소 공간(최대 16엑사바이트)을 가질 수 있습니다. 페이지 테이블 엔트리는 보통 8바이트입니다. 앞서 계산했듯이, 4GB 가상 공간에 대해서는 8MB의 오버헤드를 가집니다. 실제로는 64비트 시스템이 모든 가상 주소 공간을 매핑하지 않고 일부만 사용하므로, 실제 오버헤드는 ‘사용 중인’ 가상 메모리 범위에 비례합니다. 하지만 잠재적인 오버헤드는 32비트 시스템보다 훨씬 큽니다.
오버헤드를 줄이기 위한 기술들
페이지 테이블 오버헤드가 잠재적으로 매우 커질 수 있기 때문에, 운영체제 설계자들은 이 문제를 해결하기 위한 다양한 기법들을 고안했습니다.
다단계 페이지 테이블
가장 널리 사용되는 방법 중 하나입니다. 페이지 테이블을 단일 계층으로 두지 않고 여러 계층으로 나눕니다. 마치 전화번호부를 ‘가나다’ 순으로 나누고, 다시 각 글자 내에서 ‘이름’ 순으로 나누는 것과 비슷합니다. 이렇게 하면 모든 가상 주소 공간에 대한 페이지 테이블 엔트리를 한꺼번에 메모리에 올릴 필요 없이, 필요한 부분만 메모리에 로드할 수 있어 오버헤드를 크게 줄일 수 있습니다.
예를 들어, 64비트 시스템에서는 4단계 또는 5단계 페이지 테이블을 사용하는 것이 일반적입니다. 최상위 페이지 테이블은 작지만, 그 하위 페이지 테이블은 필요한 경우에만 생성되고 메모리에 적재됩니다.
역 페이지 테이블
전통적인 페이지 테이블은 프로세스마다 하나씩 존재하며 가상 주소를 물리 주소로 매핑합니다. 반면, 역 페이지 테이블은 시스템 전체에 하나만 존재하며 물리 주소를 가상 주소로 매핑합니다. 즉, ‘이 물리 메모리 프레임에는 어떤 프로세스의 어떤 페이지가 저장되어 있다’는 정보를 담고 있습니다.
이 방식의 장점은 물리 메모리 크기에 비례하여 페이지 테이블 크기가 결정되므로, 가상 메모리 크기가 아무리 커져도 페이지 테이블 오버헤드가 크게 늘어나지 않는다는 점입니다. 하지만 가상 주소에서 물리 주소를 찾기 위해서는 역 페이지 테이블 전체를 탐색해야 하므로 검색 시간이 길어질 수 있다는 단점이 있습니다. IBM AS/400 시스템 등 일부 시스템에서 사용됩니다.
TLB 트랜슬레이션 룩어사이드 버퍼의 역할
페이지 테이블 오버헤드를 직접적으로 줄이는 기술은 아니지만, 페이지 테이블 접근으로 인한 성능 저하를 크게 완화하는 중요한 하드웨어 캐시입니다. TLB는 CPU 내부에 있는 작은 고속 캐시로, 최근에 변환된 가상 주소와 물리 주소 매핑 정보를 저장합니다.
CPU가 가상 주소를 물리 주소로 변환해야 할 때, 가장 먼저 TLB를 확인합니다. 만약 TLB에 해당 정보가 있다면(TLB 히트), 페이지 테이블을 메모리에서 찾아볼 필요 없이 즉시 물리 주소를 얻을 수 있습니다. TLB 히트율이 높으면 페이지 테이블 접근으로 인한 메모리 오버헤드의 “시간적” 부담이 크게 줄어들어 시스템 성능이 향상됩니다. TLB는 페이지 테이블 오버헤드를 줄이기 위한 필수적인 동반자라고 할 수 있습니다.
큰 페이지 Huge pages 사용
기본 4KB 페이지 대신 2MB, 1GB와 같은 더 큰 페이지를 사용하는 방법입니다. 페이지 크기가 커지면 전체 가상 주소 공간을 매핑하는 데 필요한 페이지 엔트리의 수가 줄어듭니다.
예를 들어, 4GB 가상 메모리를 4KB 페이지로 매핑하려면 약 100만 개의 엔트리가 필요하지만, 2MB 페이지로 매핑하면 4GB / 2MB = 2048개의 엔트리만 있으면 됩니다. 이는 페이지 테이블의 크기를 획기적으로 줄여줍니다.
하지만 큰 페이지를 사용하면 페이지 내부 단편화(internal fragmentation)가 발생할 가능성이 높아집니다. 즉, 페이지의 일부만 사용하고 나머지는 낭비될 수 있습니다. 주로 데이터베이스나 가상화 환경처럼 대량의 연속된 메모리를 사용하는 애플리케이션에서 성능 향상을 위해 활용됩니다.
실생활에서의 활용과 유용한 팁
페이지 테이블 오버헤드는 일반 사용자가 직접적으로 체감하기 어려운 개념이지만, 시스템 관리자나 개발자에게는 매우 중요한 고려 사항입니다.
시스템 관리자를 위한 팁
- 메모리 사용량 모니터링
운영체제가