« Le site rame, il faut plus de RAM » : cette phrase, entendue sur presque tous les projets qui traînent un ralentissement depuis des mois, part d’une intuition compréhensible mais rarement vérifiée. La mémoire vive manque effectivement dans certains cas précis, notamment lorsque le serveur swap activement sur disque faute d’espace. Dans une majorité des situations profilées, pourtant, le goulot d’étranglement se trouve ailleurs : une requête SQL non indexée, un disque saturé en opérations d’entrée-sortie, ou un pool PHP-FPM mal dimensionné en nombre de processus plutôt qu’en mémoire allouée à chacun.
Ce constat ne s’appuie pas sur une conviction personnelle, mais sur plusieurs cas profilés où l’ajout de mémoire, réalisé en premier réflexe, n’a produit aucun gain mesurable sur le temps de réponse du site, avant qu’un profilage plus poussé ne révèle la cause réelle.
Premier cas profilé : une requête sans index, invisible à l’usage du serveur
Un site d’agence signalait un ralentissement croissant sur sa page d’archive des articles, malgré un serveur affichant une utilisation mémoire pourtant confortable. Le doublement de la RAM, tenté en premier lieu, n’a produit aucune amélioration perceptible du temps de chargement. Un examen des requêtes lentes MySQL, activé via la configuration suivante, a révélé la cause réelle :
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;La requête responsable, une jointure sur la table wp_postmeta filtrée par une clé de métadonnée non indexée, s’exécutait en plus de neuf cents millisecondes à chaque chargement de la page. L’ajout d’un index composite ciblé a ramené ce temps à moins de quarante millisecondes, un gain que l’ajout de mémoire n’avait jamais approché.
Deuxième cas : un disque saturé en opérations, pas en espace libre
Un second projet affichait des temps de réponse erratiques malgré un espace disque disponible confortable et une mémoire vive largement suffisante. L’outil iostat, lancé directement sur le serveur, a révélé le véritable goulot :
iostat -x 2La colonne %util affichait des valeurs proches de cent pour cent sur le disque hébergeant la base de données, signe d’une saturation en opérations d’entrée-sortie plutôt qu’en espace. La cause : un disque mécanique classique, mal adapté au volume d’écritures générées par un cache d’objets mal configuré qui réécrivait en base à chaque requête. Le remplacement du disque par un support SSD a résolu la situation, sans qu’aucun ajout de mémoire n’ait été nécessaire.
Troisième cas : un pool PHP-FPM mal dimensionné en nombre de processus
Un troisième projet souffrait de temps d’attente visibles côté visiteurs pendant les pics de trafic, malgré une mémoire disponible non saturée. Le pool PHP-FPM, configuré avec un nombre de processus enfants trop faible pour le volume de requêtes simultanées, mettait les nouvelles requêtes en file d’attente plutôt que de les traiter immédiatement :
pm = dynamic
pm.max_children = 8
pm.start_servers = 4Le calcul du nombre optimal de processus dépend de la mémoire réellement consommée par chaque processus PHP-FPM, et non l’inverse : ajouter de la RAM sans revoir pm.max_children en conséquence ne change rien au nombre de requêtes traitées simultanément.
Tableau récapitulatif des trois cas profilés
| Symptôme initial | Cause réelle identifiée | Effet de l’ajout de RAM seul |
|---|---|---|
| Archive d’articles lente | Requête SQL non indexée | Aucun |
| Temps de réponse erratiques | Disque saturé en I/O | Aucun |
| Files d’attente en pic de trafic | Pool PHP-FPM sous-dimensionné en processus | Aucun sans ajustement de pm.max_children |
Quand la mémoire est effectivement le facteur limitant
La mémoire vive reste un facteur limitant réel dans certaines situations précises : un serveur qui swap activement, visible via la commande vmstat et une valeur non nulle persistante dans la colonne si/so, ou un pool PHP-FPM correctement dimensionné en nombre de processus mais dont chaque processus consomme davantage de mémoire que ce que le serveur peut allouer simultanément. Dans ces cas, précisément identifiés par le profilage, l’ajout de mémoire produit un gain immédiat et mesurable.
Ajouter de la mémoire sans profiler revient à changer une pièce au hasard sur un moteur qui cale : parfois ça marche, le plus souvent ça ne fait que retarder le vrai diagnostic.
Ce que ce constat ne dit pas
Ce retour d’expérience ne recommande aucun outil de profilage en particulier : la méthode compte davantage que l’outil choisi, qu’il s’agisse du journal des requêtes lentes de MySQL, de iostat ou d’un simple top lancé au bon moment.
En résumé
Sur les trois cas profilés ici, l’ajout de mémoire n’a produit aucun gain mesurable, alors qu’une indexation ciblée a fait chuter une requête de neuf cents à quarante millisecondes. Avant tout ajout de ressource, un profilage même sommaire, requêtes lentes, I/O disque et dimensionnement du pool PHP-FPM, révèle presque toujours où se situe réellement le ralentissement, et évite une dépense qui ne change rien au symptôme observé.
