☰

내 서버가 대용량 페이지를 사용해야 하는지 확인하는 방법(메모리 페이지 크기)

tag-icon • tag-icon linux redhat memory central-processing-unit mtu
내 서버가 대용량 페이지를 사용해야 하는지 확인하는 방법(메모리 페이지 크기)

클러스터에 여러 대의 서버가 있는데 일반적으로 어떤 경우에 거대한 페이지를 구성해야 하는지 알고 싶습니다.

나는 또한 몇 가지 질문이 있습니다

  1. 복용량 "메모리 페이지 크기"는 거대한 페이지와 동일합니까?

내 Linux 서버에서 기본 메모리 페이지 크기를 확인하기 위해 다음 명령을 입력했습니다.

grep Hugepagesize /proc/meminfo

Hugepagesize: 2048 kB

getconf PAGESIZE

4096

  1. 하지만 여기에서 볼 수 있듯이 우리는 서로 다른 결과를 얻습니다. 왜 그럴까요?

  2. 거대한 페이지를 사용할 때 어떤 위험이 있나요?

  3. 복용량 투명한 거대한 페이지 비활성화 - HUGE PAGES 옵션을 비활성화한다는 의미입니까?

답변1

거대한 페이지는 응용 프로그램이 임의 액세스를 수행할 대규모 매핑이 필요할 때 흥미롭습니다. 이는 TLB(번역 참조 버퍼)에 대해 가능한 최악의 경우이기 때문입니다. TLB 항목에 대한 매핑 세분성을 절충합니다.

hugepages를 포함한 페이지는 동일한 크기의 물리적 메모리 블록에만 매핑되고 해당 크기로 정렬될 수 있습니다. 따라서 2MB hugepage는 물리적 RAM의 2MB 경계에 매핑되어야 하고, 1GB hugepage는 1GB 경계에 매핑되어야 합니다. 왜냐하면 하위 비트가 페이지 내부의 데이터를 처리하고 여기에 오프셋을 추가할 수 없기 때문입니다.

이는 실제 메모리가 아직 조각화되지 않은 경우 시스템 시작 시 거대한 페이지가 일반적으로 예약된다는 것을 의미합니다. hugepage를 인식하는 애플리케이션은 hugetlbfs이를 할당하는 데 사용할 수 있습니다.

hugepage의 크기가 2MB인지 1GB인지 커널 매개변수를 사용하여 결정해야 하며 이를 혼합할 수 없습니다. 일반 4kB 페이지는 항상 사용할 수 있습니다.

가장 일반적인 사용 사례는 가상 머신(qemu/kvm은 hugepages를 사용할 수 있음)입니다. 이를 통해 VM의 전체 메모리 매핑을 소수의 TLB 항목으로 유지할 수 있으므로 절대 제거되지 않으므로 VM 내부의 메모리 액세스에는 페이지가 필요합니다. 게스트 컨텍스트 내에서만 테이블 조회가 가능합니다.

일부 데이터베이스 시스템은 hugepage도 지원하지만 이는 일반적으로 대규모 데이터 세트와 인덱스로 작업하는 경우에만 유용합니다.

질문:

  1. 일반(4kB) 페이지와 대용량(2MB 또는 1GB) 페이지가 있습니다. 페이지 크기를 쿼리하면 일반 페이지의 크기를 가져오고, 대용량 페이지 크기를 쿼리하면 대용량 페이지에 대한 설정을 가져옵니다. 일반 페이지와 거대 페이지를 모두 병렬로 사용할 수 있지만 서로 다른 거대 페이지 크기를 혼합할 수는 없습니다.

  2. 두 가지가 서로 다르기 때문에 서로 다른 결과를 얻게 됩니다. 일반 페이지의 크기는 하드웨어에 고정되어 있으므로 설정이 아닙니다.

  3. 거대한 페이지는 초기에 할당되어야 하며 메모리는 기술적으로 "사용 가능"하지만 거대한 페이지 인식 응용 프로그램 외에는 사용할 수 없으므로 이러한 응용 프로그램을 제외한 모든 응용 프로그램에는 사용 가능한 메모리가 더 적습니다. VM이나 데이터베이스와 같이 메모리를 많이 사용하는 애플리케이션 전용 시스템에서는 hugepages를 사용하기 때문에 일반적으로 문제가 되지 않습니다.

  4. 투명 거대한 페이지는 메모리를 버퍼와 캐시로 사용할 수 있도록 시도하고(3번과 반대로) 대규모 메모리 블록을 매핑하는 응용 프로그램에 거대한 페이지를 제공하려고 시도합니다. 따라서 거대한 페이지를 인식하지 못하는 응용 프로그램은 여전히 ​​그로부터 이익을 얻을 수 있습니다. 2MB/1GB 메모리 블록을 요청하면 가능하면 hugepage가 제공됩니다. 이것이 성능에 도움이 되는지, 해를 끼치는지 여부는 애플리케이션에 따라 다릅니다. hugepage를 인식하는 앱이 있고 메모리를 수동으로 할당하려는 경우 THP를 비활성화해야 합니다. 반면 hugepage를 이해하지 못하는 데이터베이스 앱이 있는 시스템에는 이점이 있을 수 있습니다.

답변2

거대한 페이지의 명백한 사용 사례는 PageTable(/proc/meminfo에 표시됨)이 수십 GB가 되는 경우입니다. 이는 메모리를 추적하는 데만 큰 메모리와 CPU 오버헤드가 발생함을 의미합니다. 이는 거대한 메모리 덩어리, 많은 수의 프로세스 또는 둘 다에서 발생합니다. 종종 데이터베이스 애플리케이션에 사용됩니다.

이제 단일 페이지 테이블 항목이 4KB 대신 2,048KB와 같이 훨씬 더 많은 메모리를 처리하므로 거대한 페이지는 해당 오버헤드를 크게 줄입니다. (다른 플랫폼에는 다양한 크기가 있습니다. 예를 들어 AIX on POWER는 16MB의 대형 페이지를 지원합니다.)

Linux의 거대한 페이지는 파일 캐싱에 사용되지 않을 수 있으며, 비공유 메모리에 대한 몇 MB의 malloc()에 대해서는 짜증나고 비효율적입니다. 따라서 관리자는 특정 목적으로만 사용할 수 있는 대용량 페이지 풀을 할당해야 합니다. 이것은 거대한 페이지를 사용하는 단점입니다.

THP(투명 거대 페이지)는 연속 메모리를 거대 페이지로 자동으로 "조각 모음"하여 관리를 덜 성가시게 만듭니다. 아이디어는 이것이 사전 할당된 거대한 페이지를 선택 사항으로 만든다는 것입니다. 이점은 워크로드에 따라 매우 다르며, CPU를 너무 많이 소비하여 그만한 가치가 없을 수도 있습니다. THP를 비활성화하면 여전히 대용량 페이지 할당을 수동으로 사용할 수 있습니다. 때때로 THP를 끄고 데이터베이스의 공유 메모리 세그먼트를 거대한 페이지에 두는 것이 가치가 있습니다.

Linux 대용량 페이지에 대한 마지막 불만 사항은 관리가 짜증난다는 것입니다.

  • 공유 메모리는 하나의 인터페이스를 사용하지만 다른 인터페이스에는 hugetlbfs 라이브러리와 파일 시스템을 사용합니다.
  • 너무 큰 페이지를 할당하고 이를 사용하도록 애플리케이션을 구성하지 않으면 메모리를 "낭비"할 수 있습니다.
  • 해당 페이지 수는 메모리 비율이 아니라 페이지 수이므로 각 호스트 크기에 맞게 조정해야 합니다.
  • 대규모 페이지를 할당하는 기능이 하나의 그룹으로 제한되는 경우가 많으므로 데이터베이스 사용자를 전환하면 예상치 못한 메모리 낭비가 발생할 수 있습니다.

관련 정보