나는 최근 투명한 hugepages 성능 문제로 어려움을 겪고 있으며 많은 데이터베이스 시스템이 이를 끄도록 권장하는 것을 발견했습니다. 저는 Oracle, Postgresql, MySQL, Cassandra, NuoDB, Redis, Hadoop 등에 대해 이야기하고 있습니다.
몇 가지 예:
- 피터 자이체프(2014-07-23).TokuDB가 투명한 거대 페이지를 싫어하는 이유. 페르 코나.
- 미셸 케이시(2013-09-17).투명한 대용량 페이지의 성능 문제. 신탁.
- 아담 아브레바야(Adam Abrevaya)와 올렉 레빈(2014-05-15). Linux 투명 거대 페이지, JEMalloc 및 NuoDB. NuoDB 개발 센터.
그렇다면 어떤 유형의 워크로드가 이 기능의 이점을 누릴 수 있는지 궁금합니다.
답변1
Hugepages는 동일한 블록에 많은 양의 정보를 써야 할 때 유용합니다. 이는 디스크 쓰기 전략과 관련될 수 있으며 캐싱에 매우 중요합니다. 모든 구성 옵션과 마찬가지로 사용 사례에 맞지 않으면 의미가 없습니다.
따라서 동일한 블록에 실제로 많은 양의 데이터가 필요한 작업 부하에는 큰 페이지가 도움이 될 것입니다. 데이터가 너무 크면 맞지 않고 여러 페이지 파일로 분할해야 하며, 해당 페이지 파일의 수가 너무 많아서 어떤 이유로든 처리하기 어렵거나 좋지 않을 수 있으며 더 많은 수의 작은 파일이 더 바람직합니다. - 귀하의 케이스에는 대용량 페이지 파일이 필요합니다.
실제로 필요한 상황을 본 적이 없지만 캐시 관리를 통해 알고 있습니다. 이는 현실이며 어딘가에 있는 누군가가 거대한 페이지의 이점을 누릴 수 있다는 것입니다.
답변2
Cassandra가 큰 페이지에서는 이점을 얻지 못한다고 누가 말했는지 모르겠습니다. 어쩌면 /sys/kernel/mm/transparent_hugepage의 조각 모음 옵션에 대해 더 이야기하고 싶을 수도 있습니다.
개인적으로 거대한 페이지가 있거나 없는 Cassandra 클러스터를 테스트했으며, 다양한 파티션 크기(300b에서 4k까지)를 사용하여 다양한 테스트를 마친 후 이를 다시 활성화할 것이라고 알 수 있습니다.