실제로 투명한 대형 페이지를 사용하고 혜택을 보는 사람이 있습니까?

11

나는 투명한 거대한 페이지 성능 문제로 고생하고 있으며 많은 데이터베이스 시스템이 그것을 끄는 것이 좋습니다. Oracle, Postgresql, MySQL, Cassandra, NuoDB, Redis, Hadoop 등을 이야기하고 있습니다.

예를 들어:

피터 자이체프 (2014-07-23). TokuDB가 투명한 HugePages를 싫어하는 이유 . 퍼 코나.
미셸 케이시 (2013-09-17). 투명한 거대한 페이지의 성능 문제 . 신탁.
Adam Abrevaya와 Oleg Levin (2014-05-15). Linux Transparent Huge Pages, JEMalloc 및 NuoDB . NuoDB DevCentre.

궁금한 점이 있습니다.이 기능으로 어떤 종류의 워크로드가 도움이됩니까?

— 제임스 H
소스

2

나도 궁금하다. 커널 문서에 따르면 kvm 성능이 크게 향상되었지만 자세한 내용은 다루지 않았습니다. KVM 커널 튜닝 안내서 에도 언급되어 있습니다.

— Bratchley

4

HugePages의 주요 문제점은 NUMA와 관련된 것으로 보입니다. 실제로 모든 새 반짝이는 다중 프로세서 서버에는 이제 NUMA가 활성화되어 있습니다. NUMA 경계를 넘는 거대한 페이지가 있으면 메모리 하위 시스템의 펑키 한 것들이 발생합니다. 다음을 살펴보십시오 : engineering.linkedin.com/performance/…

— Lmwangi

2

거대한 페이지는 같은 블록에 많은 양의 정보를 기록해야하는 상황에서 유용합니다. 디스크 쓰기 전략과 관련이 있으며 캐싱에 중요 할 수 있습니다. 모든 구성 옵션과 마찬가지로 사용 사례가 맞지 않으면 의미가 없습니다.

따라서 실제로 동일한 블록에 엄청난 양의 데이터가 필요한 워크로드는 큰 페이지의 이점을 얻을 수 있습니다. 데이터가 너무 크면 맞지 않을 수는 있지만 수많은 페이지 파일로 나뉘어 야 할 것이며, 그 이유는 처리하기에 너무 많거나 어떤 이유로 인해 나빠질 수 있습니다. 파일이 바람직합니다-거대한 페이지 파일의 경우가 있습니다.

실질적인 관점에서, 나는 그것을 필요로 한 적이 없었지만 캐시를 관리한다는 것을 알고 있습니다. 그것은 실제적인 것이며 누군가는 어딘가에서 거대한 페이지로부터 이익을 얻을 수 있습니다.

— 바치 가르
소스

2

그렇습니다. 명시 적 거대한 페이지는 그러한 작업에 적합합니다 (PostgreSQL에서 사용 가능한 경우 해당 페이지를 사용한다고 생각합니다). 그러나 질문자는 투명한 거대한 페이지 에 대해 물었습니다 .

— Toby Speight

0

cassandra에게 누가 대량 페이지의 이점을 얻지 못할 것이라고 말했는지 모르십시오. 어쩌면 / sys / kernel / mm / transparent_hugepage에서 조각 모음 옵션의 방향에 약간의 대화가 필요합니다.

개인적으로 방금 거대한 페이지 유무에 관계없이 cassandra 클러스터를 테스트했으며 300b에서 4k까지 다양한 패리티 션 크기의 다양한 테스트 후 다시 활성화 할 것이라고 말할 수 있습니다.

— 미스터 블랙
소스