{"id":15863,"date":"2025-12-07T11:51:26","date_gmt":"2025-12-07T10:51:26","guid":{"rendered":"https:\/\/webhosting.de\/memory-fragmentation-webhosting-php-mysql-optimierung-bytefluss\/"},"modified":"2025-12-07T11:51:26","modified_gmt":"2025-12-07T10:51:26","slug":"fragmentation-de-la-memoire-hebergement-web-php-mysql-optimisation-flux-doctets","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/memory-fragmentation-webhosting-php-mysql-optimierung-bytefluss\/","title":{"rendered":"Fragmentation de la m\u00e9moire dans l'h\u00e9bergement web : pi\u00e8ge pour les performances de PHP et MySQL"},"content":{"rendered":"<p><strong>Fragmentation de la m\u00e9moire<\/strong> Dans l'h\u00e9bergement Web, PHP-FPM et MySQL ralentissent, m\u00eame si la m\u00e9moire RAM semble suffisante, car la m\u00e9moire est fragment\u00e9e en nombreux petits blocs et les allocations plus importantes \u00e9chouent. Je montre de mani\u00e8re pratique comment la fragmentation augmente le co\u00fbt des requ\u00eates, d\u00e9clenche le swap et pourquoi un r\u00e9glage cibl\u00e9 de PHP et MySQL am\u00e9liore visiblement les temps de chargement, la fiabilit\u00e9 et la scalabilit\u00e9.<\/p>\n\n<h2>Points centraux<\/h2>\n<ul>\n  <li><strong>PHP-FPM<\/strong> Recycler : red\u00e9marrer r\u00e9guli\u00e8rement les processus via pm.max_requests<\/li>\n  <li><strong>Tampon<\/strong> dosage : maintenir le tampon MySQL par connexion \u00e0 un niveau prudent<\/li>\n  <li><strong>Swap<\/strong> \u00c0 \u00e9viter : r\u00e9duire la swappiness, tenir compte du NUMA<\/li>\n  <li><strong>tableaux<\/strong> Entretenir : v\u00e9rifier Data_free, optimiser de mani\u00e8re cibl\u00e9e<\/li>\n  <li><strong>Suivi<\/strong> : anticiper les tendances et agir rapidement<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/php-mysql-fragmentierung-7243.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Que signifie la fragmentation de la m\u00e9moire dans le quotidien de l'h\u00e9bergement ?<\/h2>\n\n<p>Dans l'h\u00e9bergement, rencontre <strong>Fragmentation<\/strong> sur les processus de longue dur\u00e9e qui demandent et lib\u00e8rent constamment de la m\u00e9moire, ce qui cr\u00e9e des lacunes dans l'espace d'adressage. Bien que la somme de la RAM libre semble importante, il manque des blocs contigus pour les allocations plus importantes, ce qui ralentit les tentatives d'allocation. Je constate ce ph\u00e9nom\u00e8ne dans les workers PHP\u2011FPM et dans mysqld, qui semblent de plus en plus \u201e gonfl\u00e9s \u201c au fil des heures. Cet effet rend chaque requ\u00eate l\u00e9g\u00e8rement plus co\u00fbteuse et augmente sensiblement les temps de r\u00e9ponse sous charge. Cela ralentit consid\u00e9rablement les pics d'activit\u00e9 tels que les promotions commerciales ou les sauvegardes, m\u00eame si le CPU et le r\u00e9seau restent discrets.<\/p>\n\n<h2>Pourquoi PHP-FPM g\u00e9n\u00e8re-t-il de la fragmentation ?<\/h2>\n\n<p>Chaque worker PHP\u2011FPM charge le code, les plugins et les donn\u00e9es dans son propre <strong>Espace d'adressage<\/strong>, traite diverses requ\u00eates et laisse des espaces dispers\u00e9s lors de la lib\u00e9ration. Au fil du temps, les processus se d\u00e9veloppent et lib\u00e8rent de la m\u00e9moire en interne, mais pas n\u00e9cessairement au niveau du syst\u00e8me d'exploitation, ce qui augmente la fragmentation. Diff\u00e9rents scripts, t\u00e2ches d'importation et traitements d'images renforcent ce m\u00e9lange et entra\u00eenent des mod\u00e8les d'allocation variables. J'observe cela comme une augmentation insidieuse de la RAM, m\u00eame si la charge et le trafic semblent constants. Sans recyclage, cette fragmentation interne ralentit l'allocation et rend difficile la planification en cas de forte fr\u00e9quentation.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/memoryfragmentierung_meeting_7421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cons\u00e9quences notables sur les temps de chargement et la fiabilit\u00e9<\/h2>\n\n<p>Les processus fragment\u00e9s g\u00e9n\u00e8rent davantage <strong>Overhead<\/strong> dans la gestion de la m\u00e9moire, ce qui se traduit par des backends d'administration plus lents et des paiements plus h\u00e9sitants. Les boutiques WordPress ou les grandes instances CMS, en particulier, r\u00e9agissent lentement lorsque de nombreuses requ\u00eates simultan\u00e9es rencontrent des workers fragment\u00e9s. Il en r\u00e9sulte des d\u00e9lais d'attente, des erreurs 502\/504 et des tentatives r\u00e9p\u00e9t\u00e9es du c\u00f4t\u00e9 NGINX ou Apache. Je lis ces situations dans des m\u00e9triques telles que les pics de temps de r\u00e9ponse, l'augmentation de la ligne de base de la RAM et l'augmentation soudaine de l'utilisation du swap. Ignorer cela revient \u00e0 sacrifier les performances, \u00e0 d\u00e9t\u00e9riorer l'exp\u00e9rience utilisateur et \u00e0 augmenter le taux d'abandon dans les entonnoirs critiques.<\/p>\n\n<h2>Configurer correctement PHP-FPM : limites, pools, recyclage<\/h2>\n\n<p>Je mise sur des <strong>Limites<\/strong>, des pools s\u00e9par\u00e9s et un recyclage syst\u00e9matique pour limiter la fragmentation. Je termine pm.max_requests de mani\u00e8re \u00e0 ce que les workers red\u00e9marrent r\u00e9guli\u00e8rement sans perturber les visiteurs actuels. Pour les profils de trafic avec des pics de charge, pm = dynamic est souvent plus adapt\u00e9, tandis que pm = ondemand permet d'\u00e9conomiser de la RAM sur les sites peu fr\u00e9quent\u00e9s. Je maintiens d\u00e9lib\u00e9r\u00e9ment la limite de m\u00e9moire par site \u00e0 un niveau mod\u00e9r\u00e9 et l'ajuste en fonction des scripts r\u00e9els ; le sujet fournit une introduction \u00e0 ce sujet. <a href=\"https:\/\/webhosting.de\/fr\/php-augmenter-la-limite-de-memoire-eviter-les-erreurs-performant\/\">Limite de m\u00e9moire PHP<\/a>. De plus, je s\u00e9pare les projets tr\u00e8s sollicit\u00e9s dans des pools distincts afin qu'un \u00e9l\u00e9ment gourmand en m\u00e9moire n'affecte pas tous les sites.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/memory-fragmentierung-php-mysql-7348.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>OPcache, pr\u00e9chargement et allocateur PHP en bref<\/h2>\n\n<p>Afin de limiter la fragmentation dans le processus PHP, je mise sur un dimensionnement propre. <strong>OPcache<\/strong>. Une valeur opcache.memory_consumption g\u00e9n\u00e9reuse mais pas excessive et suffisamment de cha\u00eenes internes r\u00e9duisent les allocations r\u00e9p\u00e9t\u00e9es par requ\u00eate. Je surveille le taux de r\u00e9ussite, le gaspillage et la capacit\u00e9 restante ; si le gaspillage augmente avec le temps, il vaut mieux planifier un rechargement plut\u00f4t que de laisser les travailleurs se multiplier de mani\u00e8re incontr\u00f4l\u00e9e. Le pr\u00e9chargement peut maintenir le code chaud stable en m\u00e9moire et ainsi lisser les mod\u00e8les d'allocation, \u00e0 condition que la base de code soit pr\u00e9par\u00e9e en cons\u00e9quence. De plus, je fais attention \u00e0 la <strong>Choix de l'allocateur<\/strong>: selon la distribution, PHP\u2011FPM et les extensions fonctionnent avec diff\u00e9rentes impl\u00e9mentations Malloc. Dans certaines configurations, des allocateurs alternatifs tels que jemalloc r\u00e9duisent sensiblement la fragmentation. Cependant, je ne d\u00e9ploie ces modifications qu'apr\u00e8s les avoir test\u00e9es, car le d\u00e9bogage, le profilage DTrace\/eBPF et les vidages de m\u00e9moire r\u00e9agissent diff\u00e9remment selon l'allocateur.<\/p>\n\n<p>Pour les t\u00e2ches gourmandes en m\u00e9moire telles que le traitement d'images ou les exportations, je pr\u00e9f\u00e8re utiliser des pools s\u00e9par\u00e9s avec des limites plus strictes. Ainsi, le pool principal ne grossit pas de mani\u00e8re incontr\u00f4l\u00e9e et la fragmentation reste isol\u00e9e. De plus, je limite les extensions gourmandes en m\u00e9moire (par exemple via des variables d'environnement) et j'utilise la contre-pression : les requ\u00eates qui n\u00e9cessitent de grands tampons sont ralenties ou transf\u00e9r\u00e9es vers des files d'attente asynchrones, au lieu de surcharger tous les travailleurs en m\u00eame temps.<\/p>\n\n<h2>Comprendre la m\u00e9moire MySQL : tampons, connexions, tables<\/h2>\n\n<p>Dans MySQL, je fais la distinction entre les variables globales <strong>Tampon<\/strong> comme le pool de tampons InnoDB, les tampons par connexion et les structures temporaires, qui peuvent augmenter \u00e0 chaque op\u00e9ration. Des valeurs trop \u00e9lev\u00e9es entra\u00eenent une explosion des besoins en RAM et une fragmentation accrue au niveau du syst\u00e8me d'exploitation en cas de charge de connexion \u00e9lev\u00e9e. De plus, les tables se fragmentent \u00e0 cause des mises \u00e0 jour\/suppressions et laissent des parties Data_free qui nuisent \u00e0 l'utilisation du pool de tampons. Je v\u00e9rifie donc r\u00e9guli\u00e8rement la taille, les taux de r\u00e9ussite et le nombre de tables temporaires sur disque. L'aper\u00e7u suivant m'aide \u00e0 identifier avec pr\u00e9cision les sympt\u00f4mes typiques et \u00e0 \u00e9valuer les mesures \u00e0 prendre.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Sympt\u00f4me<\/th>\n      <th>Cause probable<\/th>\n      <th>Mesure<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>La RAM augmente r\u00e9guli\u00e8rement, le swap commence<\/td>\n      <td>Tampon trop grand ou trop nombreux tampons par connexion<\/td>\n      <td>Limiter la taille de la file d'attente, r\u00e9duire via le tampon de connexion<\/td>\n    <\/tr>\n    <tr>\n      <td>Beaucoup de sorts\/joints lents<\/td>\n      <td>Index manquants, tampons sort\/join excessifs<\/td>\n      <td>V\u00e9rifier les index, conserver sort\/join conservateur<\/td>\n    <\/tr>\n    <tr>\n      <td>Grande quantit\u00e9 de donn\u00e9es libres dans les tables<\/td>\n      <td>Mises \u00e0 jour\/suppressions importantes, pages fragment\u00e9es<\/td>\n      <td>OPTIMISEZ de mani\u00e8re cibl\u00e9e, archivez, rationalisez les sch\u00e9mas<\/td>\n    <\/tr>\n    <tr>\n      <td>Pics dans les tables de disques temporaires<\/td>\n      <td>tmp_table_size trop petit ou requ\u00eates inappropri\u00e9es<\/td>\n      <td>Augmenter mod\u00e9r\u00e9ment les valeurs, restructurer les requ\u00eates<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Optimisation de la m\u00e9moire MySQL : choisir les tailles plut\u00f4t que les d\u00e9passer<\/h2>\n\n<p>Je choisis le pool de tampons InnoDB de mani\u00e8re \u00e0 ce que le <strong>Syst\u00e8me d'exploitation<\/strong> conserve suffisamment de m\u00e9moire pour le cache du syst\u00e8me de fichiers et les services, en particulier sur les serveurs combin\u00e9s avec Web et DB. Je redimensionne de mani\u00e8re conservatrice les tampons par connexion tels que sort_buffer_size, join_buffer_size et read_buffer afin que de nombreuses connexions simultan\u00e9es n'entra\u00eenent pas de surcharge de la m\u00e9moire vive. Je d\u00e9finis tmp_table_size et max_heap_table_size de mani\u00e8re \u00e0 ce que les op\u00e9rations sans importance ne n\u00e9cessitent pas d'\u00e9normes tables en m\u00e9moire. Pour d'autres param\u00e8tres, je trouve sous <a href=\"https:\/\/webhosting.de\/fr\/mysql-optimiser-les-performances-problemes-astuces-mise-a-lechelle-du-materiel-vitesse-du-cache\/\">Performances MySQL<\/a> Des pistes de r\u00e9flexion utiles. Le point d\u00e9cisif reste le suivant : je pr\u00e9f\u00e8re r\u00e9gler un peu plus juste et mesurer, plut\u00f4t que d'augmenter \u00e0 l'aveuglette et risquer la fragmentation et le swap.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/memoryfragmentation_office_4217.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>InnoDB en d\u00e9tail : strat\u00e9gies de reconstruction et instances de pool<\/h2>\n\n<p>Afin de maintenir MySQL \u201e compact \u201c en interne, je pr\u00e9vois de proc\u00e9der r\u00e9guli\u00e8rement \u00e0 des <strong>Reconstructions<\/strong> pour les tables comportant une forte proportion d'\u00e9critures. Une commande OPTIMIZE TABLE cibl\u00e9e (ou une reconstruction en ligne via ALTER) regroupe les donn\u00e9es et les index et r\u00e9duit <em>Data_free<\/em>. Je choisis des plages horaires o\u00f9 la charge est faible, car les reconstructions sont gourmandes en E\/S. L'option <em>innodb_file_per_table<\/em> Je le garde actif, car il permet des reconstructions contr\u00f4l\u00e9es par table et r\u00e9duit le risque que certains \u201e \u00e9l\u00e9ments probl\u00e9matiques \u201c fragmentent l'ensemble du fichier d'espace de table.<\/p>\n\n<p>J'utilise plusieurs <strong>Instances de pool tampon<\/strong> (innodb_buffer_pool_instances) par rapport \u00e0 la taille du pool et aux c\u0153urs CPU afin de soulager les verrous internes et de r\u00e9partir les acc\u00e8s. Cela am\u00e9liore non seulement le parall\u00e9lisme, mais lisse \u00e9galement les mod\u00e8les d'allocation dans le pool. Je v\u00e9rifie \u00e9galement la taille des journaux de reprise et l'activit\u00e9 des threads de purge, car l'historique accumul\u00e9 peut occuper de la m\u00e9moire et des E\/S, ce qui augmente la fragmentation au niveau du syst\u00e8me d'exploitation. Il est important de modifier les param\u00e8tres progressivement, de les mesurer et de ne les conserver que si les latences et les taux d'erreur diminuent r\u00e9ellement.<\/p>\n\n<h2>\u00c9viter les swaps : param\u00e8tres du noyau et NUMA<\/h2>\n\n<p>D\u00e8s que Linux active le swap, les temps de r\u00e9ponse augmentent <strong>ordres de grandeur<\/strong>, car les acc\u00e8s \u00e0 la RAM deviennent trop lents en E\/S. Je r\u00e9duis consid\u00e9rablement vm.swappiness afin que le noyau utilise plus longtemps la RAM physique. Sur les h\u00f4tes multi-CPU, je v\u00e9rifie la topologie NUMA et active si n\u00e9cessaire l'entrelacement afin de r\u00e9duire l'utilisation in\u00e9gale de la m\u00e9moire. Pour les informations de fond et l'influence du mat\u00e9riel, la perspective m'aide \u00e0 <a href=\"https:\/\/webhosting.de\/fr\/blog-numa-architecture-serveur-performance-hebergement-materiel-optimisation-infrastructure\/\">Architecture NUMA<\/a>. De plus, je pr\u00e9vois des r\u00e9serves de s\u00e9curit\u00e9 pour le cache de page, car un cache affam\u00e9 acc\u00e9l\u00e8re la fragmentation de l'ensemble de la machine.<\/p>\n\n<h2>Pages transparentes volumineuses, surengagement et choix de l'allocateur<\/h2>\n\n<p><strong>Pages transparentes volumineuses<\/strong> (THP) peuvent entra\u00eener des pics de latence dans les bases de donn\u00e9es, car la fusion\/division de grandes pages se produit \u00e0 des moments inopportuns. Je r\u00e8gle THP sur \u201e madvise \u201c ou le d\u00e9sactive lorsque MySQL r\u00e9agit trop lentement sous la charge. Dans le m\u00eame temps, je veille \u00e0 ce que <strong>Overcommit<\/strong>: Une configuration vm.overcommit_memory trop g\u00e9n\u00e9reuse expose au risque d'OOM kills, notamment lorsque la fragmentation rend les blocs coh\u00e9rents volumineux rares. Je privil\u00e9gie les param\u00e8tres d'overcommit conservateurs et v\u00e9rifie r\u00e9guli\u00e8rement les journaux du noyau \u00e0 la recherche de signes de pression m\u00e9moire.<\/p>\n\n<p>De m\u00eame, les <strong>Choix de l'allocateur<\/strong> Au niveau du syst\u00e8me, cela vaut la peine d'y jeter un \u0153il. glibc\u2011malloc, jemalloc ou tcmalloc se comportent diff\u00e9remment en termes de fragmentation. Je teste toujours les alternatives de mani\u00e8re isol\u00e9e, je mesure l'historique RSS et les latences, et je ne d\u00e9ploie les modifications que si les m\u00e9triques restent stables sous le trafic r\u00e9el. Les avantages varient consid\u00e9rablement en fonction de la charge de travail, de la combinaison d'extensions et de la version du syst\u00e8me d'exploitation.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/memoryfragmentationdev3452.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Identifier la fragmentation : indicateurs et conseils<\/h2>\n\n<p>Je fais attention \u00e0 augmenter lentement <strong>lignes de base<\/strong> pour la RAM, davantage de r\u00e9ponses 5xx sous charge et des retards dans les actions administratives. Un coup d'\u0153il aux statistiques PM de PHP-FPM permet de voir si les enfants atteignent leurs limites ou vivent trop longtemps. Dans MySQL, je v\u00e9rifie les taux de r\u00e9ussite, les tables temporaires sur le disque et Data_free par table. En parall\u00e8le, les m\u00e9triques du syst\u00e8me d'exploitation telles que les erreurs de page, les indicateurs swap-in\/out et de fragmentation de la m\u00e9moire aident en fonction de la version du noyau. En combinant ces signaux, on peut identifier rapidement les sch\u00e9mas et prendre des mesures planifi\u00e9es.<\/p>\n\n<h2>Approfondir le suivi : comment je rassemble les signaux<\/h2>\n\n<p>Je corr\u00e8le <strong>M\u00e9triques d'application<\/strong> (latences p95\/p99, taux d'erreur) avec <strong>m\u00e9triques de processus<\/strong> (RSS par FPM Worker, m\u00e9moire mysqld) et <strong>Valeurs OS<\/strong> (Pagecache, Slab, Major Faults). Dans PHP\u2011FPM, j'utilise l'interface d'\u00e9tat pour les longueurs de file d'attente, les enfants actifs\/spawned et la dur\u00e9e de vie des travailleurs. Dans MySQL, j'observe Created_tmp_disk_tables, Handler_write\/Handler_tmp_write, ainsi que les Buffer\u2011Pool\u2011Misses. En compl\u00e9ment, je consulte les cartes de processus (pmap\/smaps) afin de d\u00e9terminer si de nombreuses petites ar\u00e8nes ont \u00e9t\u00e9 cr\u00e9\u00e9es. Ce qui est important pour moi, c'est la <strong>orientation des tendances<\/strong>: ce n'est pas le pic individuel, mais le d\u00e9placement progressif sur plusieurs heures\/jours qui d\u00e9termine si la fragmentation devient un r\u00e9el danger.<\/p>\n\n<h2>Routine pratique : maintenance et gestion des donn\u00e9es<\/h2>\n\n<p>Je range r\u00e9guli\u00e8rement <strong>Donn\u00e9es<\/strong> sur : les sessions expir\u00e9es, les anciens journaux, les r\u00e9visions inutiles et les caches orphelins. Pour les tables tr\u00e8s variables, je planifie des fen\u00eatres OPTIMIZE cibl\u00e9es afin de fusionner les pages fragment\u00e9es. Je r\u00e9partis dans le temps les t\u00e2ches d'importation volumineuses ou les vagues Cron afin que tous les processus ne sollicitent pas simultan\u00e9ment le tampon maximal. Dans le cas de projets en pleine croissance, je s\u00e9pare tr\u00e8s t\u00f4t le Web et la base de donn\u00e9es afin d'isoler les mod\u00e8les gourmands en m\u00e9moire. Cette discipline permet de maintenir la coh\u00e9rence de la m\u00e9moire vive et de r\u00e9duire le risque de latences de pointe.<\/p>\n\n<h2>Calculer correctement les tailles : dimensionner les limites et les pools<\/h2>\n\n<p>Je d\u00e9termine pm.max_children en fonction de la m\u00e9moire RAM r\u00e9ellement disponible pour PHP. Pour cela, je mesure le <strong>RSS moyen<\/strong> d'un worker sous charge r\u00e9elle (extensions et OPcache inclus) et j'ajoute des marges de s\u00e9curit\u00e9 pour les pics. Exemple : sur un h\u00f4te de 16 Go, je r\u00e9serve 4 \u00e0 6 Go pour le syst\u00e8me d'exploitation, le cache de page et MySQL. Il reste 10 Go pour PHP ; avec 150 Mo par worker, cela donne th\u00e9oriquement 66 enfants. Dans la pratique, je r\u00e8gle pm.max_children sur ~80-90% de cette valeur afin de laisser une marge pour les pics, soit environ 52-58. <strong>pm.max_requests<\/strong> Je choisis de recycler les workers avant qu'ils ne soient trop fragment\u00e9s (souvent entre 500 et 2 000, selon la combinaison de codes). <\/p>\n\n<p>Pour MySQL, je calcule le <strong>Pool de m\u00e9moire tampon<\/strong> \u00e0 partir de la taille des donn\u00e9es actives, et non de la taille totale de la base de donn\u00e9es. Les tables et index importants doivent pouvoir y tenir, mais le cache du syst\u00e8me d'exploitation a besoin d'espace pour les journaux binaires, les sockets et les ressources statiques. Pour le tampon par connexion, je calcule avec le parall\u00e9lisme maximal r\u00e9aliste. Si 200 connexions sont possibles, je ne dimensionne pas de mani\u00e8re \u00e0 ce que plusieurs gigaoctets par connexion explosent au total, mais je fixe des limites strictes qui ne pr\u00e9sentent pas de risque de swap, m\u00eame en p\u00e9riode de pointe.<\/p>\n\n<h2>Dissocier les files d'attente, le traitement d'images et les t\u00e2ches secondaires<\/h2>\n\n<p>De nombreux probl\u00e8mes de fragmentation surviennent lorsque <strong>emplois \u00e0 temps partiel<\/strong> les m\u00eames pools que les requ\u00eates frontales. Pour les exportations, les crawls, les conversions d'images ou les mises \u00e0 jour d'index de recherche, j'utilise des pools FPM s\u00e9par\u00e9s ou des t\u00e2ches CLI avec des <em>ulimit<\/em>Je limite \u00e9galement les op\u00e9rations sur les images avec GD\/Imagick en fixant des limites de ressources appropri\u00e9es, afin que les conversions individuelles volumineuses ne \u201e saturent \u201c pas tout l'espace d'adressage. Je planifie les t\u00e2ches de mani\u00e8re d\u00e9cal\u00e9e dans le temps et leur attribue des limites de concurrence sp\u00e9cifiques afin qu'elles ne saturent pas le chemin d'acc\u00e8s frontal.<\/p>\n\n<h2>Conteneurs et virtualisation : cgroups, OOM et effets ballon<\/h2>\n\n<p>Dans les conteneurs, j'observe <strong>Limites de m\u00e9moire<\/strong> et le OOM Killer en particulier. La fragmentation fait que les processus atteignent plus rapidement les limites du cgroup, m\u00eame si l'h\u00f4te dispose encore de RAM libre. J'aligne strictement pm.max_children sur la limite du conteneur et je garde suffisamment de r\u00e9serve pour amortir les pics. J'\u00e9vite le swapping \u00e0 l'int\u00e9rieur des conteneurs (ou sur l'h\u00f4te), car l'indirection suppl\u00e9mentaire amplifie les pics de latence. Dans les VM, je v\u00e9rifie le balloning et le KSM\/UKSM ; une d\u00e9duplication agressive permet certes d'\u00e9conomiser de la RAM, mais peut entra\u00eener une latence suppl\u00e9mentaire et fausser l'image de la fragmentation. <\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/hosting-speicherproblem-7392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Br\u00e8ve liste de contr\u00f4le sans puces<\/h2>\n\n<p>Je commence par fixer un objectif r\u00e9aliste. <strong>memory_limit<\/strong> par site et observe le comportement de l'utilisation maximale au fil des jours. Ensuite, je r\u00e8gle PHP-FPM avec des valeurs pm appropri\u00e9es et un pm.max_requests raisonnable afin que les workers fragment\u00e9s fonctionnent comme pr\u00e9vu. Pour MySQL, je me concentre sur une taille de pool de tampons appropri\u00e9e et des tampons par connexion conservateurs plut\u00f4t que sur des augmentations forfaitaires. C\u00f4t\u00e9 noyau, je r\u00e9duis la swappiness, v\u00e9rifie les param\u00e8tres NUMA et garde des r\u00e9serves pour le cache de page. Enfin, j'\u00e9value les tables pr\u00e9sentant des anomalies Data_free et planifie des optimisations en dehors des activit\u00e9s quotidiennes.<\/p>\n\n<h2>En bref : ce qui compte dans l'entreprise<\/h2>\n\n<p>Je parviens \u00e0 lutter efficacement contre la fragmentation de la m\u00e9moire en appliquant syst\u00e9matiquement <strong>recyclage<\/strong> le PHP\u2011FPM\u2011Worker, des limites raisonnables et des pools propres. MySQL b\u00e9n\u00e9ficie de tailles raisonnables pour le buffer pool et le buffer par connexion, ainsi que de tables bien rang\u00e9es. J'\u00e9vite de mani\u00e8re proactive le swap en tenant compte du swappiness et du NUMA et en r\u00e9servant de la RAM libre pour le cache de fichiers. La surveillance permet de d\u00e9tecter les tendances insidieuses avant que les utilisateurs ne s'en aper\u00e7oivent et permet des interventions planifi\u00e9es en toute tranquillit\u00e9. En utilisant ces leviers de mani\u00e8re disciplin\u00e9e, vous pouvez maintenir PHP et MySQL plus rapides, plus fiables et plus rentables sans avoir \u00e0 proc\u00e9der \u00e0 des mises \u00e0 niveau mat\u00e9rielles imm\u00e9diates.<\/p>","protected":false},"excerpt":{"rendered":"<p>D\u00e9couvrez comment la fragmentation de la m\u00e9moire ralentit PHP &amp; MySQL dans l'h\u00e9bergement web et comment un r\u00e9glage cibl\u00e9 de la m\u00e9moire mysql am\u00e9liore durablement vos performances. Focus : fragmentation de la m\u00e9moire.<\/p>","protected":false},"author":1,"featured_media":15856,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-15863","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"1726","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":null,"_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Memory Fragmentation","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"15856","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/15863","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=15863"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/15863\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/15856"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=15863"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=15863"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=15863"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}