Quelqu'un utilise-t-il et profite-t-il réellement d'énormes pages transparentes?

11

Je me suis récemment battu avec des problèmes de performances de pages énormes transparentes et j'ai remarqué que de nombreux systèmes de base de données recommandent de le désactiver. Je parle d'Oracle, Postgresql, MySQL, Cassandra, NuoDB, Redis, Hadoop et plus encore.

Pour des exemples:

Peter Zaitsev (2014-07-23). Pourquoi TokuDB déteste les HugePages transparentes . Percona.
Michele Casey (2013-09-17). Problèmes de performances avec les pages énormes transparentes . Oracle.
Adam Abrevaya et Oleg Levin (2014-05-15). Pages immenses transparentes Linux, JEMalloc et NuoDB . NuoDB DevCentre.

Je me demande donc: quels types de charge de travail bénéficient de cette fonctionnalité?

— James H
source

2

Je suis aussi curieux. Selon les documents du noyau, ils ont vu un grand saut dans les performances kvm mais ils n'entrent pas dans les détails. Il est également mentionné dans le guide de réglage du noyau pour KVM .

— Bratchley

4

Le principal problème avec le scénario HugePages est lié à NUMA. Pratiquement chaque nouveau serveur multiprocesseur brillant est désormais compatible NUMA. Des choses géniales dans le sous-système de mémoire s'ensuivent une fois que vous avez d'énormes pages qui franchissent les limites de NUMA. Jetez un œil à: engineering.linkedin.com/performance/…

— Lmwangi

2

D'énormes pages seraient utiles dans une situation où vous aviez besoin d'une énorme quantité d'informations à écrire dans le même bloc. Il peut être lié à la stratégie d'écriture sur disque et peut être important pour la mise en cache. Comme toutes les options de configuration, cela n'a aucun sens si votre cas d'utilisation ne convient pas.

Donc, la réponse est que la charge de travail qui a réellement besoin d'une énorme tonne de données dans le même bloc bénéficierait de pages énormes. Si les données sont si volumineuses qu'elles ne pourraient pas tenir, mais devraient être divisées en de nombreux fichiers de page, et le nombre de ceux-ci serait trop nombreux à gérer ou mauvais pour une raison quelconque, et le nombre inférieur de plus grands fichiers est préférable - il y a votre cas pour les fichiers de page énorme.

En termes pratiques, je n'en ai jamais rencontré de besoin, mais je sais que la gestion des caches - c'est une chose réelle et quelqu'un, quelque part, pourrait bénéficier de pages énormes.

— Baazigar
source

2

Oui, les pages énormes explicites sont parfaites pour de telles charges de travail (je crois que PostgreSQL les utilise si elles sont disponibles). L'interrogateur a posé des questions sur les pages énormes transparentes .

— Toby Speight

0

Je ne sais pas qui vous a dit que cassandra ne bénéficiera pas d'énormes pages. Peut-être que vous voulez être un peu bavard dans le sens de l'option de défragmentation de / sys / kernel / mm / transparent_hugepage.

Personnellement, je viens de tester un cluster cassandra avec et sans énorme page et après divers tests avec des tailles de partition différentes, allant de 300 b à 4 k, je peux dire que je vais les réactiver.

— Mr Noir
source