Serveur d'utilisation de swap : Optimiser les performances de l'hébergement

Je montre comment contrôler de manière ciblée les serveurs d'utilisation de swap afin que les charges de travail d'hébergement ne s'arrêtent pas en cas de charge et qu'il n'y ait pas d'interruption de service. performance déclencher des issues. Pour cela, j'explique les causes, les chiffres clés, les réglages de swappiness, les recommandations de taille et les étapes pratiques de tuning pour mémoire swapping hosting.

Points centraux

• Swappiness abaisser : éviter une externalisation agressive
• Taille vérifier les données : Aligner le swap sur la RAM et la charge de travail
• IO économiser les ressources : SSD-Placement, utilisation consciente de Zswap/ZRAM
• Suivi établir des règles : Page-faults, kswapd, latence
• Charges de travail ajuster les données : Équilibrer les tampons de la mémoire cache et de la BD

Ce que le swap apporte vraiment - et quand il freine

Swap étend la RAM physique en déplaçant les pages rarement utilisées vers le SSD ou le HDD, et protège les processus contre le tueur d'OOM, ce qui me permet, en cas d'urgence, d'économiser de l'espace disque. Tampon est en hausse. Linux externalise de manière opportuniste pour donner plus d'espace aux pages actives et pour garder le cache des pages, mais trop d'activité augmente la IO-charge de la mémoire. Dès que le système oscille plus souvent entre la RAM et le swap, il y a un risque de thrashing et donc de latence sensible. En cas d'hébergement web intensif avec PHP, base de données et Node.js, le cache, l'espace de travail PHP et le tampon de la base de données se disputent la mémoire. Je garde donc le swap à disposition comme filet de sécurité, mais je minimise son utilisation en fonctionnement normal.

Reconnaître avec certitude les symptômes d'une utilisation élevée du swap

Je vérifie d'abord free -h et vmstat, En effet, des taux de swap-in/swap-out élevés marquent les goulots d'étranglement. Si les taux restent bas et que de la RAM est disponible, le système fonctionne généralement normalement et n'utilise le swap que de manière opportuniste. En revanche, si les taux de défaut de page et la file d'attente IO grimpent, la latence de l'application augmente et les requêtes deviennent plus difficiles. Je vois dans les logs des indications sur les travailleurs occupés et les requêtes lentes qui apparaissent en même temps que les pics de swap. Pour plus de détails sur la mémoire virtuelle, je vous renvoie à cette introduction compacte à mémoire virtuelle, qui m'aide à faire le tri.

Avantages et risques de l'hébergement par échange de mémoire

J'utilise la permutation pour absorber les pics de RAM et permettre aux services critiques de continuer à fonctionner, ce qui, à court terme, est une bonne chose. Panne évite les problèmes. Ainsi, les petites instances VPS se contentent de moins de RAM, ce qui peut réduire les coûts en euros tant que la charge IO reste dans les limites. Mais si l'externalisation est trop importante, le SSD/NVMe est clairement en retrait par rapport à la RAM et les demandes sont bloquées. De plus, la compression (ZRAM) coûte du temps de CPU, que les applications préfèrent utiliser pour le travail réel. Le swap n'est donc pas un substitut pour moi, mais un filet de sécurité que je contrôle activement.

Swappiness : la vis de réglage la plus importante

La variable kernel vm.swappiness (0-100, généralement 60 par défaut) contrôle la vitesse à laquelle le système déplace les pages, et je la réduis à 10 pour les charges de travail d'hébergement. Je teste temporairement avec sysctl vm.swappiness=10, j'écris de façon permanente vm.swappiness=10 dans /etc/sysctl.conf. Sur les hôtes SSD, cela permet d'avoir moins de pagination et plus d'air pour le cache de page. J'observe ensuite les IO, les latences et les Working Sets pour confirmer l'effet. Si les indicateurs restent calmes, je maintiens le réglage et je documente le changement pour les audits ultérieurs.

Taille optimale du swap pour les serveurs courants

Je détermine la taille de l'espace de pagination en fonction de la RAM, de la charge de travail et de l'éventuelle mise en veille prolongée, car les fichiers trop volumineux ne me conviennent pas. Mémoire et les fichiers trop petits réduisent la mémoire tampon. Pour les serveurs d'hébergement typiques sans mise en veille prolongée, je prévois des valeurs modérées et je donne la priorité à plus de RAM plutôt qu'à d'énormes volumes de swap. Pour les instances VPS serrées, 1,5-2x RAM peuvent être utiles jusqu'à ce qu'une véritable mise à niveau soit possible. Ceux qui ont beaucoup de mémoire profitent souvent de zones de swap plus petites mais existantes pour éviter les crashs. J'utilise le tableau suivant comme point de départ et l'adapte en fonction des valeurs mesurées :

Taille de la RAM	Swap sans mise en veille prolongée	Swap avec mise en veille prolongée
≤ 2 GO	2x RAM	3x RAM
2-8 GO	= RAM	2x RAM
8-64 GO	4 à 8 Go	1,5x RAM
> 64 GO	4 GO	Non recommandé

Swap-placement et techniques avancées

Je préfère les fichiers d'échange aux partitions, car je peux ajuster les tailles de manière dynamique et faire des changements plus rapidement. en direct de l'espace de stockage. Si la zone de swap se trouve sur un stockage SSD séparé, elle est moins en concurrence avec le système d'exploitation pour l'IO. Pour les très petites VM, j'utilise Zswap ou ZRAM à titre d'essai pour réduire l'IO, mais je surveille de près l'utilisation du CPU. Je limite proprement l'overcommitment et fixe des limites pour les services afin qu'aucun processus ne pousse la machine au thrashing. Au final, ce qui compte, ce sont les effets mesurables : moins de latence, des IO plus calmes et des temps de réponse réguliers.

Monitoring : quels sont les indicateurs qui comptent vraiment

Je mesure l'occupation de la RAM, le cache de page, l'entrée/sortie de swap, l'activité de kswapd ainsi que les files d'attente IO, car ces valeurs m'envoient des signaux précoces. Si le mouvement d'échange augmente, je le corrèle avec la latence de l'application et les temps de requête. Je vérifie également les erreurs de page mineures/majeures afin de détecter les accès mémoire coûteux. Pour comprendre les stratégies de buffering, je m'appuie sur ce guide de l'utilisation de la mémoire tampon. Utilisation du buffer et du cache. Je n'interviens et ne modifie les paramètres que lorsque les métriques et les logs indiquent une pression concordante.

Comment le noyau sélectionne les pages : regard approfondi sur Reclaim

Pour faire des réglages ciblés, je comprends les listes internes : Linux fait la différence entre les pages anonymes (heaps/stacks) et les pages basées sur des fichiers (page cache). Les deux dépendent de listes LRU (active/inactive). Si la mémoire est sous pression, le noyau essaie tout d'abord de rejeter les pages inactives, basées sur les fichiers (rapidement, car elles peuvent être rechargées à partir du disque). Si trop de pages anonymes sont actives, il doit les pousser dans le swap - ce qui est plus coûteux. Une grande vm.vfs_cache_pressure accélère le rejet des dentries/inodes, ce qui libère de l'espace, mais peut entraîner une augmentation des accès aux fichiers sur les serveurs web. Je les maintiens généralement autour de 50-100 et j'observe l'évolution du débit de la mémoire cache et de la latence.

J'influence les chemins d'écriture via vm.dirty_background_bytes/vm.dirty_bytes (ou les variantes Ratio). Des limites de saleté trop élevées ne font que repousser le problème et génèrent plus tard de gros writebacks qui ralentissent la récupération de swap. Je préfère les limites basées sur les octets, car elles sont plus précises sur les grands systèmes de RAM. Une autre solution de secours est vm.min_free_kbytesSi la valeur est trop basse, le reclaim se lance dans des cycles frénétiques ; si elle est trop haute, il gaspille de la RAM. Je laisse généralement cette valeur par défaut de la distribution, à moins que je ne voie constamment „low free watermarks“ dans dmesg.

PSI et kswapd : bien interpréter les indicateurs avancés

Outre les métriques classiques, j'utilise Informations sur le décrochage par perte de pression à l'adresse suivante : /proc/pressure/memory. Haute some ou full Des valeurs supérieures à plusieurs secondes m'indiquent que des tâches attendent de la mémoire. C'est souvent le premier signe avant que les utilisateurs ne ressentent une latence. En même temps, je regarde le temps CPU de kswapdSi elle dépasse durablement quelques pour cent, Reclaim s'emballe. Avec vmstat 1 je fais attention à si/donc (swap in/out) et r/b (file d'attente d'exécution/de bloc). Haute cohérence donc-ainsi qu'une augmentation des b-Si la file d'attente indique un thrashing, j'interviens systématiquement.

Cgroups v2 et systemd : limiter délibérément le swap

Dans les environnements multi-locataires ou de conteneurs, j'évite qu'un seul service ne dévore toutes les réserves. Avec cgroups v2, je place memory.max (limite dure), memory.high (étranglement souple) et memory.swap.max (limite de swap). Sous systemd, j'utilise par service MemoryMax=, MemoryHigh= et MemorySwapMax= dans les Unit-Overrides. Ainsi, PHP-FPM ne peut pas pousser l'ensemble du système en swap, alors que les bases de données restent réactives. Pour les rafales, il suffit souvent d'un memory.high plus modéré MemorySwapMax=, plutôt que de risquer des OOM sévères. Je documente ces limites par service et les tiens à jour dans le processus de révision.

Créer, agrandir et prioriser proprement les fichiers de swap

Dans la pratique, j'ai besoin d'étapes rapides et reproductibles :

• Créer un fichier d'échange : fallocate -l 8G /swapfile && chmod 600 /swapfile && mkswap /swapfile
• Activer : swapon /swapfile; permanent via /etc/fstab avec /swapfile none swap sw,pri=5 0 0
• Ajuster la taille : swapoff /swapfile, fallocate -l 12G /swapfile, mkswap /swapfile, swapon /swapfile
• Plusieurs swaps : NVMe plus rapide avec plus de pri prioriser ; avec swapon --show --output=NOM,PRIO,SIZE,USED contrôler

Sur les systèmes très faibles en IO, je préfère réduire la taille de la swap ou placer la swap sur des disques plus rapides plutôt que de permettre au système de „swapper à mort“ lentement.

Zswap et ZRAM : quand la compression est vraiment utile

Zswap comprime les pages à extraire dans le pool de RAM backed et réduit ainsi l'IO physique. Cela ménage les SSD, mais coûte du temps de CPU. Pour les VM avec peu de cœurs, je teste d'abord lz4 (rapide, compression plus faible) et j'observe si les pics de CPU augmentent. Je remplace ponctuellement la ZRAM par un swap classique sur de très petites instances afin de rester pratiquement sans IO - je prévois pour cela plus de CPU. Je maintiens volontairement la compression à un niveau faible (par ex. 25-50% RAM pour ZRAM) afin de ne pas créer de nouveaux goulots d'étranglement. Dès que les charges de travail liées à l'unité centrale commencent à trébucher, je révise cette optimisation.

THP et fragmentation : des freins cachés à la latence

Les Transparent Huge Pages (THP) peuvent être utiles pour les JVM ou les bases de données, mais dans les environnements mixtes d'hébergement, elles peuvent aussi peser sur le reclaim et le swap. Je mets des THP sur madvise, Je ne veux pas que les charges de travail qui en bénéficient soient celles qui l'utilisent explicitement. En cas de fragmentation de la mémoire, je planifie le redémarrage des services gourmands en mémoire afin de nettoyer les tas endommagés. Pour MySQL/MariaDB, je vérifie également si le buffer pool d'InnoDB est suffisamment grand par rapport à la mémoire totale pour que le cache de page Linux ne meure pas de faim - les caches en double coûtent de la RAM et augmentent inutilement le swap.

Hôtes NUMA et multi-socles

Sur les grands hôtes bare metal, le NUMA joue un rôle. Un accès mémoire déséquilibré augmente les latences et accélère le recouvrement. Je répartis les charges de travail sur numactl --interleave=all ou j'épingle des services ciblés par nœud. Je garde les services critiques qui déclenchent beaucoup d'accès au cache de pages (par ex. Nginx) près des chemins de données ; j'encapsule les tâches par lots gourmandes en mémoire et je leur donne au besoin des limites de cgroup plus étroites pour que les débordements de NUMA ne poussent pas tout le système dans le swap.

Diagnostic du processus : qui swap vraiment ?

Lorsque les métriques du système sonnent l'alarme, j'identifie les responsables au niveau des processus : smem -knr m'indique PSS/USS (parts de mémoire réalistes), pmap -x la répartition des segments. En /proc//status je contrôle VmRSS, VmSwap et oom_score_adj. Haute VmSwap-Les valeurs de la LRU pour les modèles peu favorables (beaucoup de pages anonymes et peu utilisées) sont un candidat pour les limites ou l'optimisation du code. En complément, j'utilise pidstat -r 1, Pour voir les taux de pourrissement par processus, et les comparer aux temps de latence de l'application.

Runbooks, SLO et niveaux d'escalade

Je définis des limites claires par classe d'hôtes, par exemple : kswapd-CPU < 5% en moyenne sur 5 minutes, Major Faults < 50/s/core en fonctionnement normal, PSI memory some < 10% sur 60s. Si deux métriques sont rompues en même temps, j'interviens dans cet ordre : vérifier la swappiness, réduire brièvement le worker/buffer, adapter le swap-placement et les priorités, (dé)activer la compression, augmenter la RAM si nécessaire. Ces runbooks font partie de ma réponse aux incidents, afin que les équipes agissent de manière reproductible et Latence reste sous contrôle.

Dépannage : causes typiques et solutions rapides

Si les taux de pagination augmentent, je vérifie d'abord les services gourmands en mémoire et je les limite avec cgroups ou des paramètres de service. Ensuite, je contrôle si un trop grand nombre d'ouvriers PHP, des tampons de BD trop grands ou un cache de page trop petit sont en concurrence. Je diminue la swappiness, nettoie les caches temporaires et déplace les rotations de logs des périodes de pointe. Si la file d'attente IO reste élevée en permanence, je déplace le swap ou je le réduis afin de diminuer la concurrence IO. Si cela ne suffit pas, j'augmente la RAM et je mesure à nouveau jusqu'à ce que la latence reste stable et faible.

Tuning pour PHP, bases de données et Node.js

En PHP, je maximise les occurrences de page complète ou d'OPcache afin de réduire la quantité de RAM utilisée pour les compilations répétées, ce qui permet de Temps de réponse diminue. Dans MySQL/MariaDB, j'équilibre le Buffer Pool et le Query Cache par rapport au Page Cache afin d'éviter une double mise en cache. Pour Node.js, je fixe des limites pour le tas et je surveille le garbage collection pour que Boucle d'événements ne se bloque pas. J'évite également la fragmentation de la mémoire grâce à des roll-outs qui redémarrent régulièrement les services et détectent les fuites. Un bref approfondissement sur la Fragmentation de la mémoire aide à saisir plus rapidement de tels problèmes insidieux.

Conteneurs et piles d'hébergement : exemples pratiques

Dans les environnements de conteneurs, je limite sévèrement la mémoire par pod ou service et n'autorise qu'une part modérée de swap. Pour PHP-FPM, je calcule la mémoire par worker (RSS) plus le headroom pour le cache de page. Exemple : 512 Mo de RAM, consommation réelle de 30 Mo/travailleur - alors 8-10 travailleurs sont réalistes, pas 20. Pour Node.js, je définis --max-old-space-size délibérément en dessous de la limite physique, afin que GC ne soit pas sous pression et que le noyau ne swap pas agressivement la mémoire anonyme. Pour les bases de données, je prévois des budgets fixes, je les sépare si possible du niveau web et je laisse suffisamment de place au système d'exploitation pour les caches de fichiers.

Coûts, matériel et quand mettre à niveau la RAM

Je calcule les contre-valeurs en euros : Si l'impression de swap génère une latence permanente, la RAM supplémentaire justifie rapidement le prix et crée de véritables Performance. NVMe réduit certes la latence IO, mais ne remplace pas la mémoire volatile. Avant d'étendre le matériel, j'optimise le swappiness, les buffers et le nombre de worker pour augmenter l'efficacité. Si la charge de travail reste élevée, je planifie un saut de RAM par étapes judicieuses au lieu d'augmenter uniquement le swap. Cet ordre permet d'éviter les mauvais investissements et me donne des points de mesure clairs pour des comparaisons ultérieures.

Check : Swap Usage Server en 15 minutes

Je commence avec free -h, vmstat 1 en vérifiant Swap-mouvement, les défauts de page et les files d'attente IO. Ensuite, je mets vm.swappiness=10, charge sysctl et j'observe les indicateurs pendant cinq minutes. Si cela correspond, j'enregistre le réglage et je documente l'état actuel. L'étape suivante consiste à corriger les comptes de travail et les mémoires tampon de la base de données qui remplacent le cache de la page. Enfin, je crée des alertes qui me préviennent en cas de dérives avant que les utilisateurs ne les ressentent.

En bref

J'utilise le swap comme ceinture de sécurité, mais je maintiens son utilisation à un niveau bas pour que Latence n'explose pas et qu'il n'y a pas de problèmes de performance. Le plus grand levier reste un swappiness raisonnable, combiné à une taille de swap adaptée à la RAM et à la charge de travail. J'observe kswapd, les paresses de page et la file d'attente IO, je compare les valeurs avec les logs d'application et j'agis rapidement. Pour les petits VPS, le memory swapping hosting réduit la pression à court terme, tandis que la vraie détente apporte d'abord plus de RAM. En respectant cet ordre, on maintient la réactivité des serveurs, on réduit les pannes et on protège les budgets.