Passer au contenu 
Je contrôle la gestion des serveurs de mémoire virtuelle de manière ciblée, afin que les charges de travail d'hébergement puissent être planifiées et qu'il n'y ait pas de goulots d'étranglement. Pour ce faire, je combine serveur de mémoire virtuelle-Les techniques d'optimisation de la mémoire permettent aux applications de réagir de manière constante, même lorsque la charge de pointe dépasse brièvement la RAM physique.
Points centraux
Je résume les principaux leviers pour un hébergement en mémoire virtuelle efficace et fixe des priorités claires pour la planification, l'exploitation et le réglage. Ces points fournissent une orientation rapide et m'aident à éviter les risques de pics de latence. Je les utilise comme liste de contrôle pour les nouveaux serveurs, les projets de migration et les tests de charge. Chaque point aborde un levier pratique dont l'effet est mesurable et qui peut être vérifié en quelques minutes. Voici comment j'assure une cohérent Performance sous des charges de travail réelles.
- MMU & paginationTraduire proprement les adresses virtuelles, charger et décharger efficacement les pages.
- Swap sur SSD: Placer le fichier de pagination séparément, réduire la concurrence IO.
- Swappiness faire des réglages fins : Évaluer le cache par rapport à l'externalisation, tenir compte de la charge de travail.
- Overcommitment équilibrer les choses : Augmenter la densité, éviter le thrashing.
- Suivi établir des priorités : Corréler la RAM, le cache de page, l'entrée/sortie de swap et la latence.
Je complète cette liste en fonction du cas d'utilisation, par exemple avec des limites de conteneurs ou des tampons de base de données. Des métriques claires évitent les points aveugles et me montrent les tendances à temps. De petites adaptations suffisent souvent lorsque les valeurs mesurées conviennent. Je me concentre d'abord sur les principaux freins, puis j'affine les détails. C'est ainsi que je maintiens les Temps de réaction prévisible.
Comment la mémoire virtuelle agit dans l'hébergement
La mémoire virtuelle étend logiquement la RAM physique en déplaçant les pages de données inactives vers la mémoire de masse et en conservant les pages actives dans la RAM. J'utilise ce principe pour absorber les pics de demande tout en conservant en cours répondre rapidement aux demandes. La part de pages actives reste décisive, car c'est elle qui détermine la fréquence à laquelle le système doit effectivement transférer des données. Des taux de réussite élevés dans la RAM réduisent les sauts de latence, tandis que des Page Faults répétés augmentent les temps d'attente. J'évalue donc toujours le taux de travail réel de mes applications et le maintiens autant que possible dans la plage de vitesse rapide. Mémoire principale.
MMU, pagination et segmentation en bref
L'unité de gestion de la mémoire traduit les adresses virtuelles en adresses physiques et pose ainsi les bases d'une pagination efficace. Les systèmes modernes misent principalement sur des tailles de page fixes, car cela permet de réduire les coûts de gestion et de planifier. J'utilise la segmentation avec des blocs variables de manière ciblée, lorsque la séparation logique simplifie la sécurité ou le débogage. Pour les charges de travail d'hébergement, la pagination cohérente donne les résultats les plus fiables, car les charges de travail sont fortement mixtes. Je garde la séparation des termes claire afin de faciliter la prise de décision. adresser et les tableaux de pages, notamment pour le débogage de rares aberrations. Je trouve ainsi rapidement les Causes derrière les pointes IO.
Utiliser correctement l'hébergement d'utilisation de swap
Le swap agit comme un tampon pour les pages inactives, mais ne remplace pas la RAM et ne doit pas dominer l'IO. J'accepte un mouvement de swap modéré tant que les temps de réponse restent constants et que les taux de page par défaut sont faibles. La situation devient critique lorsque le jeu de travail actif et le cache de pages se chevauchent et que l'externalisation IO de l'ordinateur. Je fixe alors des limites, j'augmente la mémoire de travail ou j'ajuste les valeurs de réglage. Je définis des seuils mesurables et je considère le swap comme un filet de sécurité permettant d'absorber les sauts de charge momentanés, et non comme un Solution permanente.
Tuning sur les hôtes Linux : Swappiness, Cache et IO
Je règle vm.swappiness de manière à ce que le noyau protège le cache des pages sans pousser les pages utiles sur le disque trop tôt. Pour les charges de travail web intensives en lecture, j'ai tendance à définir des valeurs plus basses afin que les données réutilisables restent dans le cache. Je vérifie en outre l'influence du cache du système de fichiers à l'aide de la connaissance du Cache de page Linux, pour mieux interpréter les occurrences de cache. En parallèle, j'examine les files d'attente IO et la latence par source afin d'éviter qu'un seul volume ne devienne un frein. Ainsi, je minimise Thrashing et assure une stabilité Durée de validité sous charge mixte.
Bases de données et InnoDB : sauvegarder l'enregistrement de travail
Avec MySQL, je donne la priorité à innodb_buffer_pool_size près du jeu de travail actif, afin que les pages fréquentes y restent. Je fais attention au nombre d'instances de buffer pool afin de réduire la concurrence de latch et d'augmenter le parallélisme. Je règle la taille des redo logs de manière à ce que les checkpoints se produisent régulièrement, mais pas trop souvent. Si le jeu de données actif dépasse nettement la mémoire tampon, les lectures aléatoires et donc les latences augmentent brusquement. C'est pourquoi je mesure les temps de requête, les taux d'utilisation du cache et la répartition des entrées/sorties afin d'ajuster la mémoire tampon de manière ciblée. élargir ou des requêtes sur optimiser.
Emplacement du SSD et disposition du stockage
Si possible, je place le fichier de page sur un SSD rapide et je le sépare du disque système afin de réduire la concurrence due aux accès aux journaux et au système d'exploitation. Plusieurs volumes m'offrent une marge de manœuvre pour répartir les chemins de lecture et d'écriture. Je n'accepte la permutation sur les disques durs que si les pics de charge sont rares et que la surveillance est étroite. Je fais également attention aux accès aux métadonnées, car ils s'additionnent sensiblement sous la pression. Une mise en page propre réduit les temps de latence sans modification du code et augmente la vitesse de transfert. Planification de la plate-forme sur de nombreux Mois.
VMs, conteneurs et overcommitment
Je mets sciemment la densité à l'échelle, mais je limite l'overcommitment pour qu'il ne se transforme pas en pagination excessive. Je fixe les limites des conteneurs avec réserve, car des limites trop étroites déclenchent le tueur d'OOM, même si l'hôte a encore de la capacité. Pour obtenir des résultats répétables, j'utilise le Réglage du noyau et je vérifie les métriques cgroup séparément. Je corrèle les statistiques de l'hyperviseur et les métriques de l'invité afin de voir simultanément la pression du ballon et l'échange dans l'invité. Ainsi, je garde Répartition de la charge transparent et réagir rapidement avant que des goulots d'étranglement ne se forment s'intensifier.
Suivi, métriques et seuils
Je n'évalue pas l'état de la mémoire de manière isolée, mais toujours dans le contexte des temps de réponse, des files d'attente et des taux d'erreur. Seule la corrélation me permet de savoir si une augmentation du swap est pertinente ou si l'application reste suffisamment en cache. Des valeurs directrices claires accélèrent les décisions et raccourcissent les diagnostics en cas d'incident. Le tableau suivant me fournit des valeurs indicatives éprouvées dans la pratique pour des configurations d'hébergement typiques. Je les adapte en fonction de la charge de travail et je vérifie les modifications à l'aide d'indicateurs répétables. Séries de mesures.
| Paramètres | Effet | Zone de recommandation | Mesure pertinente |
|---|---|---|---|
| vm.swappiness | Balance cache RAM vs. swap | 10-40 pour le web, 40-60 pour le mixte | Entrée/sortie de commutation, latence P95 |
| vfs_cache_pressure | Impression sur Inodes/Dentries | 50-100 selon les résultats de la cache | Taux d'utilisation de la mémoire cache, lectures IO |
| innodb_buffer_pool_size | Enregistrement de travail DB en RAM | 60-75% RAM ou Working Set proche | Hits du buffer pool, Query-P95 |
| Placement de swap | Séparation des chemins IO | SSD, séparé de l'OS | File d'attente IO, latence de disque |
| Taille de l'échange | Tampon pour les pics | jusqu'à environ 2× RAM si nécessaire | utilisation max. de l'échange, thrashing |
Je considère ces valeurs guides comme des points de départ et non comme des règles rigides. J'introduis les changements progressivement et je mesure après chaque adaptation sur plusieurs fenêtres de charge. Si les délais P95/P99 restent calmes, j'accepte le changement. S'ils augmentent, je reviens en arrière et je fais des ajustements plus conservateurs. constant Transparence évite les erreurs d'interprétation et protège Disponibilité.
Comprendre le NUMA et la proximité du CPU
Sur les hôtes avec plusieurs nœuds NUMA, je m'assure que les threads et leur mémoire restent aussi locaux que possible. Je vérifie numa_hit/numa_miss, les accès locaux vs. distants et, si nécessaire, j'établis des politiques d'entrelacement ou de préférence. Je laisse généralement désactivé zone_reclaim_mode afin d'éviter une récupération agressive sur le nœud local. Pour les charges de travail fortement réparties, j'utilise de manière ciblée l'épinglage CPU et le placement de la mémoire afin que les chemins chauds ne passent pas par QPI/UPI. De cette manière, les hits du cache L3 et la latence de la mémoire restent dans des limites prévisibles.
Contrôler de manière ciblée les Transparent Huge Pages et HugePages
THP peut améliorer les hits TLB, mais il y a des pics de latence dus à la compensation en arrière-plan. Pour les bases de données sensibles à la latence, j'active souvent THP sur madvise ou je le désactive et je n'utilise les HugePages statiques que lorsqu'elles apportent des avantages mesurables. J'observe le CPU khugepaged, les défaillances majeures/mineures et les événements de recouvrement. Si le système présente des pics de compaction, je préfère des pages plus petites afin de conserver des temps de réponse prévisibles. Inversement, j'active THP de manière sélective pour les tâches analytiques avec de grands balayages séquentiels.
Zswap/ZRAM : la compression comme amortisseur de chocs
J'utilise Zswap lorsqu'il y a une pression à court terme sur la RAM et qu'il y a suffisamment de réserves de CPU. Les pages compressées dans la RAM réduisent l'IO de swap et lissent les latences P95 lors des pics de charge. Pour les très petites VM avec des disques limités, j'utilise la ZRAM comme swap compressé en mémoire, mais je note que la pression permanente consomme du temps CPU. Je choisis l'algorithme et la taille de manière pragmatique (souvent LZ4, ratio modéré par rapport à la RAM), et je vérifie que la compression soulage vraiment l'IO au lieu de simplement brûler du temps de calcul.
Régler consciemment le dirty writeback et le scheduler IO
Je contrôle vm.dirty_background_ratio et vm.dirty_ratio pour lisser les pics d'écriture et ne pas risquer un flush en retard. Je maintiens dirty_expire_centisecs de manière à ce que les anciennes dirty pages soient écrites à temps, sans créer de charge de fond qui provoquerait des pics de latence. Sur NVMe, j'utilise de préférence des ordonnanceurs modernes multi-queues et des files d'attente courtes ; sur SATA, un profil deadline fonctionne souvent de manière plus stable que l'équité pure. Ces leviers permettent de limiter les cascades de writeback et d'éviter que les threads de reclaim et de flusher ne s'entrechoquent.
Cgroups v2 : memory.min, memory.high, memory.max
Dans les conteneurs, j'assure des budgets minimums avec memory.min, je fixe des plafonds souples via memory.high et des limites strictes avec memory.max. J'évite ainsi qu'un voisin bruyant ne déplace tout le cache de la page. swap.max, je le limite délibérément pour éviter que les conteneurs ne „continuent à respirer“ en silence alors que la latence s'effondre. Lors d'événements OOM, j'utilise des décisions de mise à mort conscientes de cgroup et OOMScoreAdjust pour mettre fin aux bons candidats. Cela préserve l'hôte et maintient les chemins critiques en vie de manière fiable.
Évaluer les signatures PSI et Reclaim
Je lis /proc/pressure/memory et je corrèle les temps de congestion avec les latences dans l'application. Des valeurs Memory-PSI croissantes sans swap visible indiquent souvent un reclaim actif qui freine le débit. J'observe en outre les taux de refault du workingset : si les pages reviennent rapidement dans le cache, le reclaim a été trop agressif. Les défauts majeurs, les événements vmscan et les latences IO donnent une image globale. J'utilise ces signatures pour les alarmes qui ne tirent pas à chaque kilooctet de fluctuation, mais qui indiquent de véritables clusters à risque.
JVM, PHP-FPM et Redis : des astuces spécifiques à la charge de travail
Pour les services de la JVM, j'adapte la taille du tas à la charge de travail réelle et j'évite que la VM n'occupe tout le système d'exploitation. J'utilise des profils GC conscients des conteneurs et je garde de la marge de manœuvre pour le code, les threads et la mémoire native. Pour PHP-FPM, je veille à ce que le mode gestionnaire ne parque pas inutilement les processus à vide dans la RAM. J'utilise Redis strictement en RAM avec une politique claire de maxmemory ; le swap ne ferait ici que ruiner la latence. De telles subtilités permettent de garder le cache de page libre et le garbage collector éloigné de tout temps de chemin critique.
Planification des capacités et tests de charge avec des quantités de travail
Je détermine le Working Set avec des schémas répétables : Phases d'échauffement, tests de rampe, tests de pointe et soak runs. Je ne mesure pas seulement les valeurs moyennes, mais aussi les P95/P99, les taux d'erreur et le rapport entre la quantité de mémoire active et la quantité de mémoire inactive. Avant les versions, je mets en place des hôtes Canary avec des limites identiques, je compare les taux de PSI et d'erreurs et je décide du déploiement ou du retrait en fonction des données. Cela permet à la plateforme de croître de manière contrôlée, sans que le cache de page ne s'effiloche ou que le SSD ne soit soumis à une charge de writeback permanente.
Incident playbook et protection OOM
Dans le cas d'un incident, je commence par freiner des quatre fers : ralentir les tâches bruyantes, activer temporairement memory.high, vider les caches des requêtes, parquer brièvement le travail par lots si nécessaire. J'évite les interventions paniques comme le vidage de tout le cache de pages. Au lieu de cela, je sécurise les artefacts : vmstat, ps avec RSS/swap, iostat, dmesg, les traces OOM et les indicateurs per-container. Ensuite, j'adapte les limites et le swappiness de manière conservatrice. Je garde les règles OOM killer compréhensibles afin que, dans le pire des cas, la bonne classe de processus se termine, et non le chemin critique frontdoor.
Pratique : charges de travail et profils typiques
Les sites web basés sur PHP ont souvent besoin de beaucoup de cache de page pour les actifs récurrents et d'une mémoire tampon DB modérée. Les services Node.js bénéficient de latences de boucle d'événement stables et d'une faible pression de swap, afin que la collecte de garbage ne ralentisse pas. La livraison de contenu statique vit du cache du système de fichiers et de chemins de lecture propres. Je vérifie en outre Fragmentation de la mémoire, lorsque les processus allouent et libèrent beaucoup. La reconnaissance de forme propre évite les fausses alertes et maintient les SLA en cas de pics de charge, sans ressources de gaspiller.
Ajustement fin sans risque : procéder par étapes
Je ne modifie qu'un seul levier à la fois et je fais des mesures reproductibles afin que la cause et l'effet restent clairs. Avant cela, je m'assure des bases que je pourrai comparer plus tard. Ensuite, j'adapte au minimum le swappiness, la taille des tampons ou les limites et j'observe les pics, pas seulement les moyennes. Je prépare des rollbacks en cas de saut de P95/P99 ou d'augmentation des compteurs d'erreurs. Cette procédure réduit Temps d'arrêt et préserve les Prévisibilité lors de mises à niveau ou de migrations.
En bref
J'utilise la mémoire virtuelle de manière ciblée pour conserver des jeux de travail dans la RAM et pour utiliser la délocalisation comme filet de sécurité. Le swappiness, le comportement du cache et l'agencement du stockage contrôlent la latence sous pression, tandis que des limites et une observation propres empêchent les pannes. Un placement de swap basé sur le SSD, des limites d'overcommit claires et des tailles de tampon proches de la base de données constituent des leviers pratiques pour une réaction rapide. Les valeurs mesurées plutôt que l'intuition guident mes décisions, et les petites étapes assurent un contrôle permanent. Voici comment j'utilise mémoire virtuelle comme un amplificateur de cohérence et maintient les environnements d'hébergement en permanence performant.
