Les HugePages Linux dans l'hébergement : un coup de pouce pour MariaDB, Redis et PHP-FPM

Je montre concrètement comment les « hugepages » sous Linux optimisent les performances de MariaDB, Redis et PHP-FPM dans la pile d'hébergement, où elles constituent un frein et comment je les configure de manière ciblée. C'est ainsi que je réduis Latence, réduit les échecs de TLB et maintient la Gestion de la mémoire prévisible.

Points centraux

Les points clés suivants résument les principales manipulations et les effets correspondants.

• Mode THP Choisissez judicieusement : „ madvise “ pour les charges de travail courantes, „ never “ pour les services sensibles tels que Redis.
• HugePages statiques Prévoir des pools de mémoire tampon MariaDB de grande taille afin de réduire la latence et les échecs de TLB.
• Redis Se prémunir contre les pics de latence : désactiver THP et limiter les coûts liés aux forks.
• PHP-FPM en bénéficie indirectement grâce à une surcharge du noyau réduite et à des backends plus rapides.
• analyse comparative et effectuer un suivi avant la mise en service, rendre les effets mesurables.

HugePages et THP : une brève explication

J'utilise HugePages, afin d'activer des pages de mémoire plus grandes et de réduire ainsi le nombre de pages à gérer. Les pages classiques ont une taille de 4 Ko, tandis que les grandes pages ont généralement 2 MO sont volumineuses. Cela permet de réduire considérablement les échecs TLB, le processeur consacre moins de temps à la gestion de la mémoire et les services qui accèdent fréquemment à la RAM réagissent plus rapidement. Les « Transparent Huge Pages » (THP) tente de le faire automatiquement et peut fonctionner sans modification de l'application. Des rapports pratiques montrent souvent des opérations 20 à 40 % plus rapides lorsque les charges de travail et les paramètres sont adaptés.

Choisir et tester correctement les modes THP

Je fais une distinction claire entre les modes „always“, „ madvise “ et „ never “, car ils ont des impacts différents sur les charges de travail. „ always “ peut mobiliser une quantité étonnamment importante de RAM et générer des opérations de copie lorsque les services se dupliquent. „ madvise “ permet un contrôle : seules les zones de mémoire explicitement marquées par l’application utilisent des pages de grande taille. „ never “ offre une prévisibilité maximale, en particulier pour les services générant de nombreux forks, comme Redis. Si vous souhaitez approfondir le sujet, vous trouverez ici des informations détaillées sur les opportunités et les pièges : THP : un atout ou un problème ?. Je teste chaque mode avec une charge réelle, je mesure la latence, le temps CPU et le RSS, puis je prends une décision en m'appuyant sur ces données.

Configuration pratique sur l'hôte

Avant de migrer des services, je m'assure que les paramètres par défaut des hôtes sont reproductibles et qu'un plan de secours fiable est en place.

Utiliser THP de manière ciblée (paramètres de démarrage ou systemd)

• Au démarrage du noyau : ajouter „ transparent_hugepage=madvise “ ou „ transparent_hugepage=never “ dans GRUB, puis redémarrer.
• En continu via sysfs – idéal pour les tests ou dans une unité systemd :

Vérifier l'état de #
cat /sys/kernel/mm/transparent_hugepage/enabled
cat /sys/kernel/mm/transparent_hugepage/defrag

# Passage à madvise (exemple)
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo never   > /sys/kernel/mm/transparent_hugepage/defrag

Je consigne ces commandes dans une petite unité systemd afin que les redémarrages ne suppriment pas ces paramètres.

Réserver des HugePages statiques

En ce qui concerne la réservation côté HugeTLB, je prévois de manière prudente et en prévoyant une marge (voir la liste de contrôle ci-dessous) :

# Vérifier la taille et le nombre
grep -i huge /proc/meminfo

# Réserver 32 Go (pages de 2 Mo -> 16384)
sysctl -w vm.nr_hugepages=16384
echo "vm.nr_hugepages=16384" > /etc/sysctl.d/90-hugepages.conf

# Facultatif : point de montage pour hugetlbfs (utile pour le diagnostic)
mkdir -p /dev/hugepages
echo "hugetlbfs /dev/hugepages hugetlbfs defaults,pagesize=2M 0 0" >> /etc/fstab
mount -a

Lorsque des services utilisent HugeTLB, ils ont généralement besoin des droits MEMLOCK. Pour cela, je définis des limites et des capacités dans l'unité systemd correspondante :

[Service]
LimitMEMLOCK=infinity
CapabilityBoundingSet=CAP_IPC_LOCK
AmbientCapabilities=CAP_IPC_LOCK

Vérification : les processus utilisent-ils des pages volumineuses ?

Je vérifie l'utilisation réelle pour chaque processus :

# Totaux par processus pour les AnonHugePages
grep -i 'AnonHugePages' /proc/$PID/smaps | awk '{s+=$2} END {print s " kB"}'

# Indicateurs à l'échelle du système
grep -i huge /proc/meminfo

MariaDB : gains grâce aux HugePages statiques

MariaDB repose sur InnoDB-Pool de mémoire tampon et d'une utilisation prévisible de la mémoire vive. Je configure généralement THP sur „ » pour les bases de données de production :„never“ ou je le règle sur „ madvise “ si je réalise des tests ciblés. Raison : lors des opérations de fork et en cas de charges d'écriture, les pages de 2 Mo génèrent des coûts élevés liés à la copie à l'écriture (copy-on-write), ce qui ralentit les requêtes et pèse sur les performances de MariaDB. Les HugePages statiques pour un pool de tampons volumineux, plutôt orienté lecture, rendent la latence plus régulière et réduisent la surcharge administrative. En complément, j’ajuste vm.swappiness et le planificateur d’E/S afin que le noyau ne remplace pas inutilement le tampon.

Configuration dans MariaDB, NUMA et E/S

• Un pool de mémoire tampon adapté à la charge : innodb_buffer_pool_size comme levier principal, innodb_buffer_pool_instances pour la mise en parallèle.
• Activer les grandes pages (si la version le permet) : innodb_use_large_pages=ON ou, plus précisément, „ FORCE “ uniquement après test.
• Lissage du chemin d'E/S : innodb_flush_method=O_DIRECT, une stratégie « Write-Amp » rigoureuse, des points de contrôle bien maîtrisés.
• Éviter les pièges NUMA : mysqld via numactl --interleave=all se déclencher en cas de risque de déséquilibre des nœuds.
• Limites du système : MEMLOCK comme indiqué ci-dessus ; réserver suffisamment de HugePages à l'avance pour éviter tout échec au démarrage.

Dans la pratique, j'augmente progressivement la taille du pool de tampons par paliers raisonnables (par exemple 8 → 16 → 32 Go), j'observe les taux de Page Fault et je compare la latence 99p. Ce sont les charges de travail axées sur la lecture qui en bénéficient le plus ; en cas de charge d'écriture élevée, j'évalue avec une attention particulière les coûts liés au CoW et les cycles fsync.

Redis : éviter les pics de latence

Redis est très sensible aux comportements de mémoire et aux coûts de fork lors de Instantanés et les réécritures AOF. Lorsque THP est activé, le système doit déplacer non pas 4 Ko, mais 2 Mo lors de la copie – soit une unité 512 fois plus grande, ce qui provoque des pics de latence. Je règle donc généralement THP sur „never“, ce qui rend la mémoire Redis plus prévisible. Pour les grands ensembles clé-valeur, principalement en lecture, je peux tester „ madvise “, mais uniquement avec des benchmarks rigoureux. De plus, je configure vm.overcommit_memory=1 et j'ajuste la défragmentation Redis afin de maintenir la fragmentation sous contrôle.

Modules de configuration permettant de réduire les coûts liés aux fourches

• THP : définir „ never “ à l'échelle de l'hôte, lisser la charge des forks.
• AOF/Instantané : no-appendfsync-on-rewrite yes, aof-rewrite-incremental-fsync yes, choisir des horaires correspondant aux heures creuses.
• Défragmentation : activedefrag oui, régler avec précision les seuils (seuil-de-défragmentation-actif-inférieur, commande de cycle).
• Overcommit : vm.overcommit_memory=1, afin d'éviter que les fourches ne bloquent le système.
• Allocateur : utiliser Redis avec jemalloc pour limiter la fragmentation.

Je mesure les effets à l'aide de l'outil intégré de surveillance de la latence Redis et je mets en corrélation les pics avec les événements BGSAVE ou AOF. Si la latence au 99,9e centile diminue de manière stable, je déploie ces paramètres en production.

PHP-FPM : un coup de pouce indirect dans la pile web

PHP-FPM ne consomme généralement pas d'énormes quantités de RAM, mais fonctionne mieux avec moins Surcoût du noyau et des backends plus rapides. Lorsque MariaDB et Redis répondent plus rapidement, le TTFB et le temps de réponse par requête diminuent. J’ajuste le nombre de workers FPM, le paramètre `max_children` et le gestionnaire de processus (dynamique ou statique) en fonction de la courbe de charge. Je profite ainsi des avantages des HugePages dans l'ensemble du système, sans prendre de risques inconsidérés. Je propose ici une introduction pratique à ce sujet : Bien utiliser les HugePages sur les serveurs.

Pratique : paramètres de processus, Opcache et dimensionnement

• Je calcule la valeur de pm.max_children comme suit : (mémoire RAM allouée à PHP) / (RSS moyen par worker), en prévoyant une réserve de 10 à 20 %.
• Maintenir la stabilité du cache d'opcodes : suffisante opcache.memory_consumption et opcache.interned_strings_buffer, afin d'éviter les recompilations.
• Cohérence des allocateurs : l'utilisation de la même famille d'allocateurs C (glibc/jemalloc) pour tous les composants permet d'éviter une fragmentation inattendue.
• Le THP „ madvise “ sur l'hôte facilite modérément la gestion des bibliothèques partagées, sans faire grimper les coûts liés aux forks.

Configuration : étape par étape et tableau récapitulatif

Je commence chaque migration par une État des lieux: RAM, débits d'écriture et de lecture, comportement en cas de fork, pic de charge. Je définis ensuite des objectifs, tels qu'une latence constante pour N requêtes par seconde ou une réduction du temps CPU dans le noyau. Je configure THP en fonction du service et effectue des tests en conditions réelles. Je consigne ensuite les résultats et déploie les modifications de manière contrôlée. Le tableau suivant résume les points de départ éprouvés dans la pratique, que j'affine par la suite :

Service	Mode THP	HugePages statiques	Remarque
MariaDB	madvise ou jamais	Oui, adapté au pool de tampons	Les grands ensembles de données axés sur la lecture en tirent profit ; tester minutieusement la charge d'écriture.
Redis	never	Plutôt non	Éviter les coûts liés aux branches, maintenir la défragmentation active.
PHP-FPM	madvise	Rarement nécessaire	Les avantages découlent principalement, de manière indirecte, de l'accélération des backends.

Environnement d'hébergement : le choix détermine les performances

Je n'y parviens que de manière durable constante Les cas où le fournisseur configure correctement le noyau et les paramètres par défaut. Cela inclut des noyaux à jour, des préréglages THP raisonnables, des réserves de RAM suffisantes et un service d'assistance disposant d'une expérience en matière d'optimisation. Lorsque je compare des offres d’hébergement, je recherche des informations claires sur l’optimisation de MariaDB, Redis et PHP-FPM. Si vous souhaitez comprendre les différences entre HugeTLB et THP, cette introduction concise vous sera utile : Comparaison entre HugeTLB et THP. Lors de tests, webhoster.de s'est révélé être un candidat de choix pour les projets nécessitant un volume important de données, grâce à une configuration fiable.

Conteneurs, Cgroups et Kubernetes

Dans les environnements de conteneurs, je procède un peu différemment, car de nombreux paramètres s'appliquent à l'ensemble de l'hôte et ne peuvent pas être modifiés au niveau de chaque pod ou conteneur Docker :

• THP est une décision au niveau de l'hôte. Je l'installe sur le nœud, et non dans le conteneur.
• HugeTLB nécessite des pages réservées sur l'hôte. Dans les orchestrations, j'attribue explicitement les ressources (types 2 Mi/1 Gi par nœud) et j'y planifie les pods.
• Cgroups : je fais attention à memory.max/Limites de swap, afin d'éviter que des arrêts imprévus dus à un manque de mémoire (OOM) ne détruisent les séries de mesures.
• Cohérence de l'image : versions identiques de l'allocateur dans tous les conteneurs concernés, afin d'éviter toute dérive aléatoire de la fragmentation.

Je réalise des tests au niveau des nœuds avec des paramètres de noyau identiques et je procède à une rotation progressive des déploiements afin d'éviter les creux de charge et les caches froids.

Analyse comparative, suivi et planification des capacités

Je ne me fie pas à mon intuition, je mesure dur. Avant et après chaque modification, j'utilise des profils de charge identiques et je mesure la latence, le débit, le temps CPU dans l'espace utilisateur et l'espace noyau, ainsi que le RSS. Je vérifie également les pics, et pas seulement les moyennes, afin de détecter rapidement les valeurs aberrantes. Pour la planification, j’utilise des marges afin que la croissance ne se heurte pas immédiatement à des limites. Je maintiens ainsi les performances constantes pendant plusieurs semaines et je répartis les réserves de manière judicieuse.

Grandeurs mesurées et commandes de test rapides

• État THP : cat /sys/kernel/mm/transparent_hugepage/enabled, .../défragmentation.
• HugeTLB : grep -i huge /proc/meminfo, cat /proc/sys/vm/nr_hugepages.
• Du côté des processus : /proc/$PID/smaps selon AnonHugePages parcourir.
• Erreurs majeures/mineures et indicateurs TLB : perf stat -p $PID -e cycles,task-clock,minor-faults,major-faults,dTLB-load-misses,iTLB-load-misses.
• Latences Redis : outils de mesure de latence intégrés, corrélation avec BGSAVE/AOF.
• MariaDB : AFFICHER L'ÉTAT GLOBAL et schéma de performances pour les taux de réussite dans la mémoire tampon, comportement des points de contrôle InnoDB.

Ce qui importe, c'est la cohérence de la campagne de mesure : mêmes ensembles de données, mêmes plages horaires de test, même charge de fond. Sinon, ce serait comme comparer des pommes et des poires.

Images d'erreurs et remèdes rapides

Si les temps de réponse augmentent après l'installation d'un commutateur THP, je vérifie immédiatement Fourche- Événements et comportement „ copy-on-write “. Si les „ requêtes lentes “ se multiplient dans MariaDB, je réduis l'amplitude des écritures, je règle le THP de manière plus prudente et j'évalue le chemin d'E/S. Si Redis signale des pics de latence sporadiques, je règle THP sur « never » et je vérifie les moments de création des instantanés. Si la charge CPU augmente brusquement, je surveille indirectement les échecs TLB via les indicateurs Perf et je réduis le nombre de HugePages statiques. Je documente chaque correction afin de pouvoir réagir plus rapidement en cas de récidive.

Stratégie de retour en arrière

• Rétablir le réglage THP au mode précédent, redémarrer uniquement si nécessaire.
• Réduire progressivement les HugePages statiques (vm.nr_hugepages), ne pas éteindre brusquement.
• Annuler les indicateurs spécifiques au service (innodb_use_large_pages, paramètres de défragmentation), puis refaites la mesure.
• Enregistrez les valeurs « avant » et « après » afin d'accélérer la prochaine itération.

Liste de contrôle et calcul des dimensions

Pour le calcul des éléments statiques HugePages Je me base sur un calcul simple : nombre = taille cible en octets divisée par la taille d'une page (2 Mo). Si je prévois par exemple un pool de mémoire tampon InnoDB de 32 Go, j'ai besoin d'environ 16 384 pages de 2 Mo chacune. J'ajoute une réserve de 5 à 10 % afin d'éviter que de légères fluctuations ne provoquent des goulots d'étranglement. Ensuite, au démarrage, je vérifie si l'instance accède effectivement à des pages de grande taille. Si les mesures correspondent aux attentes, j'étends ce paramètre à d'autres nœuds.

Remarque concernant les HugePages de 1 Go

Dans le cas de pools de tampons très volumineux et stables, les pages de 1 Go (HugeTLB, en fonction du processeur et du noyau) permet de réduire la pression sur le TLB. Je ne les utilise que si les besoins en mémoire restent constants à long terme et si des réserves contiguës suffisamment importantes sont disponibles. La configuration suit le même schéma que pour 2 Mo, mais nécessite une planification et des tests plus rigoureux, car la fragmentation et le comportement au démarrage sont plus sensibles.

En bref

Je mets linux J'utilise les „ hugepages “ de manière ciblée : THP utilise généralement „ madvise “ pour les piles Web, « never » pour Redis, et des pages statiques pour les grands pools MariaDB axés sur la lecture. Cela me permet de réduire les échecs de TLB, de maintenir des latences constantes et d'éviter les surprises liées à la mémoire. PHP-FPM en bénéficie indirectement, car la base de données et le cache répondent plus rapidement. Grâce à des tests de performance et à une surveillance rigoureux, je vérifie les effets et valide les modifications. En collaboration avec un fournisseur proposant des paramètres par défaut modernes pour le noyau et une assistance adaptée, la pile reste fiable et rapide même sous charge.