수강생을 위해 준비한 기사 번역 "리눅스 관리자".

이전에는 Linux에서 Hugepages를 테스트하고 활성화하는 방법에 대해 이야기했습니다.
이 기사는 실제로 Hugepages를 사용할 수 있는 장소가 있는 경우에만 유용합니다. 나는 Hugepages가 마법처럼 생산성을 향상시킬 것이라는 전망에 속는 사람들을 많이 만났습니다. 그러나 hugepaging은 복잡한 주제이므로 잘못 사용하면 성능이 저하될 수 있습니다.

1부: Linux에서 hugepages가 활성화되어 있는지 확인(원본 여기에)

문제 :
시스템에서 HugePages가 활성화되어 있는지 확인해야 합니다.

솔루션 :
매우 간단합니다.

cat /sys/kernel/mm/transparent_hugepage/enabled

당신은 다음과 같은 것을 얻을 것입니다 :

always [madvise] never

사용 가능한 옵션 목록이 표시됩니다(항상, 미치게, 절대로), 현재 활성화된 옵션은 괄호 안에 표시됩니다(기본적으로 미치게 하다).

미치게 하다 그 의미 transparent hugepages 다음을 사용하여 명시적으로 hugepage를 요청하는 메모리 영역에 대해서만 활성화됩니다. 미치광이(2).

항상 그 의미 transparent hugepages 모든 프로세스에 대해 항상 활성화되어 있습니다. 이는 일반적으로 성능을 향상시키지만 많은 프로세스가 적은 양의 메모리를 소비하는 사용 사례가 있는 경우 전체 메모리 로드가 크게 증가할 수 있습니다.

못 그 의미 transparent hugepages madvise를 사용하여 요청하더라도 포함되지 않습니다. 자세한 내용을 알아보려면 다음으로 문의하세요. 선적 서류 비치 리눅스 커널.

기본값을 변경하는 방법

옵션 1: 직접 변경 sysfs (재부팅 후 매개변수는 기본값으로 돌아갑니다):

echo always >/sys/kernel/mm/transparent_hugepage/enabled
echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
echo never >/sys/kernel/mm/transparent_hugepage/enabled

옵션 2: 수정된 구성으로 커널을 다시 컴파일하여 시스템 기본값을 변경합니다(이 옵션은 사용자 정의 커널을 사용하는 경우에만 권장됩니다).

항상 기본적으로 설정하려면 다음을 사용하십시오.

CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# Comment out CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y

madvise를 기본값으로 설정하려면 다음을 사용하십시오.

CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
# Comment out CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y

2부: HugePages의 장점과 단점

Hugepages 사용의 장점, 단점 및 가능한 함정을 선택적으로 설명하려고 노력할 것입니다. 기술적으로 복잡하고 현학적인 기사는 Hugepages가 만병통치약이라고 착각하는 사람들에게는 이해하기 어려울 수 있으므로 단순성을 위해 정확성을 희생하겠습니다. 많은 주제가 실제로 복잡하고 따라서 크게 단순화되었다는 점을 명심할 가치가 있습니다.

우리는 Linux를 실행하는 64비트 x86 시스템에 대해 이야기하고 있으며 거의 모든 최신 Linux의 경우와 마찬가지로 시스템이 투명한 hugepage를 지원한다고 가정하고 있다는 점에 유의하십시오(거대 페이지를 덮어쓰지 않는다는 것은 단점이 아니기 때문입니다). 환경.

자세한 기술 설명은 아래 링크에 첨부하겠습니다.

가상 메모리

C++ 프로그래머라면 메모리의 개체에 특정 주소(포인터 값)가 있다는 것을 알고 있을 것입니다.

그러나 이러한 주소가 반드시 메모리의 물리적 주소(RAM 주소)를 반영하는 것은 아닙니다. 가상 메모리의 주소를 나타냅니다. 프로세서에는 커널이 가상 메모리를 물리적 위치에 매핑하는 데 도움이 되는 특수 MMU(메모리 관리 장치) 모듈이 있습니다.

이 접근 방식에는 많은 장점이 있지만 가장 중요한 것은 다음과 같습니다.

성능(다양한 이유로)
프로그램 격리, 즉 어떤 프로그램도 다른 프로그램의 메모리에서 읽을 수 없습니다.

페이지란 무엇입니까?

가상 메모리는 페이지로 나누어집니다. 각 개별 페이지는 특정 물리적 메모리를 가리키거나, RAM의 영역을 가리킬 수도 있고, 비디오 카드와 같은 물리적 장치에 할당된 주소를 가리킬 수도 있습니다.

처리하는 대부분의 페이지는 RAM을 가리키거나 스왑됩니다. 즉, 하드 드라이브나 SSD에 저장됩니다. 커널은 각 페이지의 물리적 레이아웃을 관리합니다. 스푸핑된 페이지에 액세스하면 커널은 메모리에 액세스하려는 스레드를 중지하고 하드 드라이브/SSD에서 페이지를 RAM으로 읽은 다음 스레드를 계속 실행합니다.

이 프로세스는 스트림 투명하므로 반드시 HDD/SSD에서 직접 읽을 필요는 없습니다. 일반 페이지의 크기는 4096바이트입니다. Hugepages 크기는 2MB입니다.

번역 연관 버퍼(TLB)

프로그램이 메모리 페이지에 액세스할 때 CPU는 데이터를 읽을 물리적 페이지(즉, 가상 주소 맵이 있어야 함)를 알아야 합니다.

커널에는 사용되는 페이지에 대한 모든 정보가 포함된 데이터 구조(페이지 테이블)가 있습니다. 이 데이터 구조를 사용하면 가상 주소를 실제 주소에 매핑할 수 있습니다.

그러나 페이지 테이블은 상당히 복잡하고 느리기 때문에 프로세스가 메모리에 액세스할 때마다 전체 데이터 구조를 분석할 수는 없습니다.

다행히 우리 프로세서에는 가상 주소와 물리적 주소 간의 매핑을 캐시하는 TLB가 있습니다. 즉, 첫 번째 액세스 시도에서 페이지 테이블을 구문 분석해야 하지만 페이지에 대한 모든 후속 액세스는 TLB에서 처리될 수 있으므로 빠른 작업이 가능합니다.

물리적 장치로 구현되기 때문에(애초에 속도가 빨라짐) 용량이 제한됩니다. 따라서 더 많은 페이지에 액세스하려는 경우 TLB는 모든 페이지에 대한 매핑을 저장할 수 없으므로 프로그램 실행 속도가 훨씬 느려집니다.

거대한 페이지가 구조하러 옵니다

그렇다면 TLB 오버플로를 방지하려면 어떻게 해야 할까요? (우리는 프로그램에 여전히 동일한 양의 메모리가 필요하다고 가정합니다).

이것이 바로 Hugepages가 등장하는 곳입니다. 단 하나의 TLB 항목이 필요한 4096바이트 대신 이제 하나의 TLB 항목이 무려 2MB를 가리킬 수 있습니다. TLB에 512개의 항목이 있다고 가정해 보겠습니다. 여기서는 Hugepages 없이 일치시킬 수 있습니다.

4096 b⋅512=2 MB

그렇다면 우리는 어떻게 그들과 비교할 수 있습니까?

2 MB⋅512=1 GB

이것이 바로 Hugepages가 멋진 이유입니다. 많은 노력을 들이지 않고도 생산성을 향상시킬 수 있습니다. 그러나 여기에는 중요한 경고가 있습니다.

거대한 페이지 스푸핑

커널은 각 메모리 페이지가 사용되는 빈도를 자동으로 모니터링합니다. 물리적 메모리(RAM)가 충분하지 않으면 커널은 덜 중요한(덜 자주 사용되는) 페이지를 하드 디스크로 이동하여 더 중요한 페이지를 위해 일부 RAM을 확보합니다.
원칙적으로 Hugepages에도 동일하게 적용됩니다. 그러나 커널은 개별 바이트가 아닌 전체 페이지만 교환할 수 있습니다.

다음과 같은 프로그램이 있다고 가정해 보겠습니다.

char* mymemory = malloc(2*1024*1024); // Возьмем это за одну Hugepage!
// Заполним mymemory какими-либо данными
// Сделаем много других вещей,
// которые приведут к подмене страницы mymemory
// ...
// Запросим доступ только к первому байту
putchar(mymemory[0]);

이 경우 커널은 사용자가 2바이트를 읽을 수 있도록 하드 드라이브/SSD에서 최대 4096MB의 정보를 대체(읽기)해야 합니다. 일반 페이지의 경우 하드 드라이브/SSD에서 XNUMX바이트만 읽어야 합니다.

따라서 hugepage를 재정의하면 전체 페이지에 액세스해야 하는 경우에만 읽는 것이 더 빠릅니다. 이는 메모리의 다른 부분에 무작위로 액세스하려고 시도하고 몇 킬로바이트만 읽는 경우 일반 페이지를 사용해야 하며 다른 것에 대해 걱정하지 않아야 함을 의미합니다.

반면에 대량의 메모리에 순차적으로 액세스해야 하는 경우 hugepages가 성능을 향상시킵니다. 그러나 추상적인 소프트웨어가 아닌 직접 테스트하여 무엇이 더 빨리 작동하는지 확인해야 합니다.

메모리 할당

C를 작성하면 다음을 사용하여 힙에서 임의로 작은(또는 거의 임의로 큰) 메모리 양을 요청할 수 있다는 것을 알 수 있습니다. malloc(). 30바이트의 메모리가 필요하다고 가정해 보겠습니다.

char* mymemory = malloc(30);

프로그래머에게는 운영 체제에 30바이트의 메모리를 "요청"하고 일부 가상 메모리에 대한 포인터를 반환하는 것처럼 보일 수 있습니다. 하지만 실제로는 malloc () 함수 내에서 호출하는 C 함수일 뿐입니다. brk 및 sbrk 운영 체제에서 메모리를 요청하거나 해제합니다.

그러나 각 할당에 대해 점점 더 많은 메모리를 요청하는 것은 비효율적입니다. 일부 메모리 세그먼트가 이미 해제되었을 가능성이 높습니다. (free()), 재사용할 수 있습니다. malloc() 해제된 메모리를 재사용하기 위해 매우 복잡한 알고리즘을 구현합니다.

동시에 모든 일이 당신에게는 눈에 띄지 않게 일어나는데 왜 걱정해야합니까? 하지만 도전이기 때문에 free() 그런 뜻은 아니야 메모리는 반드시 운영 체제로 즉시 반환됩니다..

메모리 조각화라는 것이 있습니다. 극단적인 경우에는 몇 바이트만 사용되는 힙 세그먼트가 있고 그 사이의 모든 항목은 해제됩니다. (free()).

메모리 조각화는 엄청나게 복잡한 주제이므로 프로그램을 조금만 변경해도 상당한 영향을 미칠 수 있습니다. 대부분의 경우 프로그램은 심각한 메모리 조각화를 일으키지 않지만, 힙의 일부 영역에 조각화 문제가 있는 경우 hugepages가 상황을 더욱 악화시킬 수 있다는 점을 기억해야 합니다.

hugepages의 선택적 사용

이 기사를 읽은 후, hugepages를 사용하면 프로그램의 어느 부분이 이점을 얻을 수 있고 어느 부분은 이점을 얻을 수 없는지 판단할 수 있습니다. 그렇다면 hugepages를 활성화해야 할까요?

다행히 사용할 수 있습니다 madvise()유용한 메모리 영역에 대해서만 거대한 페이징을 활성화합니다.

먼저 다음을 사용하여 hugepages가 madvise() 모드에서 실행되고 있는지 확인하세요. 명령 기사의 시작 부분에.

그런 다음 사용 madvise()hugepages를 사용할 위치를 커널에 정확히 알려줍니다.

#include <sys/mman.h>
// Аллоцируйте большое количество памяти, которую будете использовать
size_t size = 256*1024*1024;
char* mymemory = malloc(size);
// Просто включите hugepages…
madvise(mymemory, size, MADV_HUGEPAGE);
// … и задайте следующее
madvise(mymemory, size, MADV_HUGEPAGE | MADV_SEQUENTIAL)

이 방법은 단순히 메모리 관리 방법에 대한 커널에 대한 조언일 뿐입니다. 이는 커널이 특정 메모리에 대해 자동으로 hugepages를 사용한다는 의미는 아닙니다.

문서를 참조하세요 (맨페이지)madvise메모리 관리에 대해 더 자세히 알아보고 madvise(), 이 주제는 엄청나게 가파른 학습 곡선을 가지고 있습니다. 따라서 정말 능숙해지고 싶다면 긍정적인 결과를 기대하기 전에 몇 주 동안 읽고 테스트할 준비를 하십시오.

무엇을 읽을까요?

질문이있다? 댓글에 적어주세요!

출처 : habr.com

HugePages의 장점과 단점