개요

Linux 환경에서 SGA 영역(TOTAL_SHM_SIZE)를 크게 설정하고 SESSION 수 (MAX_SEISSON_COUNT)를 많게 설정한 경우 Memory Swap Out/In, Out of Memory, 서버 행과 같은 현상이 발생할 수 있습니다. 이에 대한 해결 방안으로서 적용할 수 있는 Huge page에 대해 안내합니다. 

참고

현상 및 Tibero Huge Page 세부 설정 방안은 'Memory Swap Out/In, Out of Memory, 서버 행 해결방법 (Linux)' 게시글에서 확인하실 수 있습니다. 

방법

Huge Page

• CPU는 Physical Memory(이하: RSS)에 접근하기 위해 Virtual Memory(이하: VSS)를 통해 접근합니다.
• CPU는 VSS를 RSS로 변환하기 위해 Page Table을 사용합니다.
• Process의 Memory 사용량이 많아질 수록 Page Table의 크기 역시 커지고 관리 오버헤드가 증가합니다.
• Linux는 기본적으로 4KB 단위의 Page Size로 Memory로 관리합니다.
• 대용량 Memory를 사용하는 애플리케이션의 경우, 4KB 단위의 작은 Page를 너무 많이 관리해야 하므로 Page Table 크기와 Translation Lockaside Buffer(이하: TLB) Miss 빈도가 증가할 수 있습니다.

getconf -a |grep -i PAGESIZE
PAGESIZE                           4096

MMU 및 TLB

• CPU는 VSS를 통해 RSS로 접근을 해야합니다.
• VSS와 RSS 중간에 Memory Management Unit (이하: MMU)가 중간에서 주소 변환을 수행합니다.
• MMU는 Page Table을 참조하여, 변환 과정을 거치게 됩니다. 
• CPU가 MMU를 통해 RSS로 접근을 시도하는 경우 매번 Page Table을 참조하여, 접근하기 때문에 성능 저하가 있습니다.
• MMU에서 변환하는 속도를 높이기 위해 TLB가 사용되며, TLB는 최근에 변환된 주소 매핑 정보를 캐시 형태로 저장합니다.

• CPU가 VSS를 통해 MMU에 RSS 주소를 요청하면, 먼저 TLB를 조회합니다.

  - MMU에 값이 있으면, Page Table 접근 없이 바로 RSS 주소로 변환
  - MMU에 값이 없으면, Page Table 접근하여, 값을 변환하여 TLB에 캐시

Huge Page 사용 이유

Huge Page는 MMU/TLB 구조의 한계를 완화하기 위한 기술입니다.

Memory 관리를 HugePage를 적용하여 Page를 사용 하게 되면, TLB Miss를 줄일 수 있습니다. 
또한. MMU가 처리해야 할 Page 변환 횟수를 줄여 CPU의 Memory 접근 성능을 높입니다.

Page Table 처리

• VSS는 4단계 Page Table을 거쳐 RSS로 변환합니다.
• CR3 -> PGD -> PUD -> PMD -> PTE -> Physical Memory (RSS)

4KB Page Size의 Memory 접근 (Non-HugePage)

CPU가 2MB Memory 접근하기 위해 4단계인 PTE 과정까지 512 액세스가 필요하다.

• PGD -> PUD -> PMD -> PTE, 4단계를 512회 액세스

2MB Page Size의 Memory 접근 (HugePage Size 2MB)

CPU가 2MB Memory 접근하기 위해 3단계인 PMD 과정까지 3번 액세스가 필요합니다.

• PGD-> PUD -> PMD, 3단계를 1회 액세스

  - PMD 단위: 2MB
  - PTE 단위: 4KB

Page Table 크기 비교 

Non-HugePage와 Huge Page의 page table 크기 비교를 아래 예시를 통해 설명합니다.

Case 1. Non-Huge Page: 4KB 단위로 적용한 경우의 Memory 처리

50GB의 Shared Memory를 1,000개의 Process가 접근할 수 있다고 가정합니다. 
50GB의 Shared Memory를 RSS에서 접근하기 위한 Entry는 다음과 같습니다.

• 50GB의 RSS 접근을 위해 만들어지는 PTE Entry는 13,107,200개
• 1,000개의 Process에서 50GB에 접근하기 위해 Process별 PTE 용량은 100MB
• 1,000개의 Process가 50GB에 접근하기 위한 Page Table 총 용량은 약 97GB

위와 같은 상황에서 서버에서 필요로 하는 Page Table 용량은 97GB로 굉장히 높은 수치입니다.

Case 2. Huge Page: 2MB 단위로 적용한 경우의 Memory 처리

50GB의 Shared Memory를 1000개의 Process가 접근할 수 있다고 가정합니다.
50GB의 Shared Memory를 RSS 접근하기 위한 Entry는 다음과 같습니다.

• 50GB의 RSS 접근을 위해 만들어지는 PDU Entry는 25,600개
• PDU는 2MB 단위로 처리 하기 때문에 PTE 단계는 생략
• 1,000개의 Process에서 50GB에 접근하기 위해 Prcess별 PDU 용량은 0.19MB
• 1,000개의 Process가 50GB에 접근하기 위한 Page Table 총 용량은 약 195MB

위 예시와 같이, 4KB 단위 (non-hugepage)와 2MB 단위 (hugepage)의 Page Table 용량은 큰 차이가 있으며 HugePage를 사용함으로써 Page Table에서 사용하는 Memory 용량을 대폭 줄일 수 있습니다. 

Non-HugePage와 Huge Page의 차이

• Memory 산정 시 TOTAL_SHM_SIZE와 MAX_SESSION_COUNT 두 값에 따라 Page Table 용량이 정해진다.
• Page Table 크기까지 고려하여, Huge Page 적용 여부를 결정하면 된다.
• Linux에서 Huge Page 크기를 2MB와 1GB로 설정할 수 있다. 
  • Tibero에서는 2MB로만 설정해도 충분히 크기 때문에 1GB로 설정하는 내용은 제외

Referance

Huge Page 적용 전 Kernel Page Table Memory Usage

[root@DB01 /]# cat /proc/meminfo |grep -i hugepagesize
Hugepagesize:       62914560 kB

[root@DB02/]# cat /proc/meminfo |grep -i hugepagesize
Hugepagesize:       66914531 kB

• 서버 Memory TOTAL: 250GB
  • MAX_SESSION_COUNT=5000
  • TOTAL_SHM_SIZE=130G
  • MEMORY_TAGET=160G
  • USE_HUGE_PAGE=N (Default: N, Tibero 6에서는 _USE_HUGE_PAGE 파라미터 사용)
  • 총 Page Table 크기: 126G
• Tibero Database 기동 후 정상 운영되다, 점진적으로 Page Table의 용량이 늘어나 Memory 부족 현상 발생
• Memory 부족으로 인해, Swap Out/In 빈번하게 발생하여, 성능 저하 발생
• 서버 성능 저하 발생으로 행 걸림 현상으로 120초간 응답 없는 Process를 Kernel에서 KILL함
• 이로 인해 Tibero Instance 다운 발생

[root@DB01 /]# cat /proc/meminfo |grep -i hugepagesize
Hugepagesize:       203120 kB

[root@DB02 /]# cat /proc/meminfo |grep -i hugepagesize
Hugepagesize:       212713 kB