Serveur lent : mesurer avant d’augmenter la puissance

Quand un serveur ralentit, augmenter sa puissance semble être la réponse la plus rapide. Cela peut fonctionner, mais aussi masquer une requête mal conçue, un stockage saturé ou un service externe lent. Avant de payer davantage chaque mois, il faut relier le symptôme utilisateur à la ressource réellement en difficulté.

Décrire le ralentissement côté métier

Précisez quel parcours est lent, à quelle heure et pour combien de personnes. Une page d’accueil, un export volumineux et l’enregistrement d’une commande ne sollicitent pas les mêmes composants. Le ressenti doit devenir une mesure suffisamment précise pour comparer avant et après.

Dans un exemple fictif, le CRM ralentit chaque matin pendant un import. Les pages publiques restent rapides. Cette différence oriente l’enquête vers le traitement et ses dépendances, plutôt que vers un manque général de puissance. Notez également les changements récents et les tâches planifiées.

Observer plusieurs ressources ensemble

Le processeur ne raconte pas toute l’histoire. Regardez la mémoire, les attentes disque, le réseau et les files de travail sur la même période. Un processeur peu occupé peut attendre un stockage lent ; davantage de cœurs ne supprimera pas cette attente.

La documentation du noyau Linux sur les informations de pression des ressources décrit des mesures liées aux périodes d’attente sur certaines ressources. Elles complètent les indicateurs classiques, mais demandent une interprétation dans le contexte de l’application et de la charge observée.

Suivre le trajet de la demande

Une opération peut traverser le serveur web, une base de données et un service distant. Mesurez les étapes pour localiser le délai. Ne concluez pas à une panne du serveur parce que le dernier écran visible appartient à votre application.

Vérifiez les requêtes répétées, les traitements exécutés inutilement et les appels externes sans délai maîtrisé. Une optimisation ciblée peut suffire. Évitez toutefois les modifications hasardeuses en production : conservez une mesure de référence et testez la correction sur un périmètre contrôlé.

Choisir entre corriger et dimensionner

Si une tâche peut être déplacée hors d’une période chargée ou mise en file, comparez cette option à un renforcement permanent. Si la charge utile dépasse réellement la capacité, dimensionnez avec une marge. Le but n’est pas de refuser une machine plus puissante, mais d’en comprendre l’effet attendu.

Le guide pour surveiller les outils métier aide à relier les signaux techniques aux usages importants. Mesurez ensuite le parcours initial : une baisse d’utilisation du processeur n’a pas de valeur si le client attend toujours autant pour terminer sa commande.

Garder des repères après la correction

Conservez les mesures, la cause retenue et la modification réalisée. Surveillez une période représentative, y compris les pics. Une amélioration observée sur une seule requête à vide ne permet pas de conclure à une résolution durable du problème.

Dans une infrastructure Linux maîtrisée, le diagnostic protège autant la qualité que le budget. Vous pouvez investir lorsqu’une capacité supplémentaire est nécessaire, et éviter de financer durablement un défaut de fonctionnement. La bonne décision repose sur un goulot identifié et un résultat utilisateur effectivement amélioré.