Comment examiner les goulots d’étranglement

Cette rubrique décrit un processus recommandé pour examiner les goulots d’étranglement.

Quelle est la source du problème ?

La source du problème peut être liée au matériel ou au logiciel. Lorsque les ressources sont sous-utilisées, il s’agit généralement d’une indication d’un goulot d’étranglement quelque part dans le système. Les goulots d’étranglement peuvent être causés soit par des limitations matérielles, soit par des configurations logicielles inefficaces, ou par les deux.

L’identification des goulots d’étranglement est un processus incrémentiel dans lequel la réduction d’un goulot d’étranglement peut entraîner la découverte de la suivante. La science de l’identification et de la réduction de ces goulots d’étranglement est l’objectif de ce sujet. Il est possible qu’un système effectue des pics pendant de courtes périodes. Toutefois, pour un débit durable, un système ne peut traiter que aussi rapidement que son composant le plus lent.

Utilisation d’une approche série

Les goulots d’étranglement peuvent se produire au niveau des points de terminaison (entrée/sortie) du système ou quelque part au milieu (orchestration/base de données). Une fois que l’emplacement du goulot d’étranglement a été isolé, une approche structurée peut être entreprise pour identifier la source. Une fois les goulots d’étranglement atténués, il est essentiel de mesurer à nouveau les performances pour s’assurer qu’un nouveau goulot d’étranglement n’a pas été introduit ailleurs dans le système plus bas dans la ligne.

Le processus d’identification et de résolution des goulots d’étranglement doit être effectué de manière série, par lequel un seul paramètre à la fois doit être varié, puis les performances mesurées pour vérifier l’impact de cette modification unique. La variation de plusieurs paramètres à la fois peut masquer l’effet de la modification.

Par exemple, la modification du paramètre 1 peut améliorer les performances, mais la modification du paramètre 2 conjointement avec le changement du paramètre 1 peut avoir un effet néfaste qui ne fait que nuire aux avantages de la modification du paramètre 1, ce qui entraîne un effet zéro net. Toutefois, cela entraîne un faux négatif sur l’effet de la variation du paramètre 1 et d’un faux positif sur l’effet du paramètre 2 variable.

Tester la cohérence

La mesure des caractéristiques de performances après modification des paramètres est impérative pour valider l’effet de la modification.

• Matériel : il est important d’utiliser du matériel cohérent, car le matériel peut afficher un comportement incohérent produisant des résultats trompeurs, par exemple, n’utilisez pas d’ordinateur portable.

• Durée de la série de tests : il est également important de mesurer les performances d’une période minimale fixe pour s’assurer que les résultats sont effectivement durables et pas simplement des pics. Une autre raison pour exécuter des tests sur des périodes plus longues est de s'assurer que le système a passé la phase initiale de préchauffage, où tous les caches sont remplis, que les tables de base de données ont atteint les nombres attendus, et que la régulation du débit a eu suffisamment de temps pour s'activer et fonctionner correctement une fois que les seuils prédéfinis sont atteints. Cette approche aidera à découvrir un débit durable optimal.

• Paramètres de test : il est également impératif de ne pas varier les paramètres de test de l’exécution de test à l’exécution de test. Par exemple, différentes tailles de carte et/ou de document peuvent produire des résultats de débit et de latence différents.

• État propre : une fois qu’un test est terminé, il est important de nettoyer tout l’état avant d’exécuter la prochaine exécution du test. Par exemple, les données historiques peuvent être générées dans la base de données ayant un impact sur le débit du runtime. Le recyclage des instances de service permet de libérer des ressources mises en cache telles que la mémoire, les connexions de base de données et les threads.

Attentes : Débit et latence

Il est raisonnable d’attendre une certaine quantité de débit et/ou de latence du système déployé. Essayer d'obtenir à la fois un débit élevé et une faible latence, c'est comme tirer dans deux directions opposées. Toutefois, il est réaliste d’attendre un débit optimal avec une latence raisonnable. À mesure que le débit s'améliore, un stress accru (consommation plus élevée de CPU, contention d’E/S disque plus forte, pression sur la mémoire, plus grande contention de verrouillage) est exercé sur le système, ce qui peut avoir un impact négatif sur la latence. Pour découvrir une capacité optimale d’un système, il est impératif d’identifier et d’atténuer tous les goulots d’étranglement.

Les goulots d’étranglement peuvent être causés par des données héritées (instances terminées) résidant dans la base de données sans être nettoyées. Dans ce cas, les performances peuvent se dégrader. Donner au système suffisamment de temps pour vider peut aider à atténuer le problème. Toutefois, la découverte de la cause de l’accumulation du backlog et l’atténuation du problème est importante.

Pour découvrir la cause du backlog, il est important d’analyser les données historiques, d’analyser les compteurs de l’Analyseur de performances (pour découvrir les modèles d’utilisation et diagnostiquer la source du backlog). Il s’agit d’une situation courante dans laquelle de grandes quantités de données sont traitées de manière par lots de manière nocturne. La découverte de la capacité du système et de son aptitude à se remettre d'un retard peut être utile pour estimer la configuration matérielle nécessaire à la gestion des scénarios de surcharge et la quantité d'espace tampon à prendre en compte dans un système pour faire face aux pics imprévus de débit.

L’optimisation du système pour un débit durable optimal nécessite une compréhension approfondie de l’application déployée, des forces et des faiblesses du système et des modèles d’utilisation du scénario spécifique. La seule façon de détecter les goulots d’étranglement et de prédire un débit durable optimal avec certitude consiste à effectuer des tests approfondis sur une topologie qui correspond étroitement à ce qui sera utilisé en production.

D’autres rubriques de cette section vous guident tout au long du processus de définition de cette topologie et fournissent des conseils sur la façon d’atténuer les goulots d’étranglement et nous espérons aider à éviter les goulots d’étranglement en premier lieu.

Croissance

Les goulots d’étranglement peuvent se produire à différentes étapes de la topologie déployée. Certains goulots d’étranglement peuvent être résolus en mettant à niveau le matériel. Le matériel peut être mis à niveau en effectuant un scale-up (plus de processeurs, de mémoire ou de cache) ou en effectuant un scale-out (serveurs supplémentaires). La décision d’effectuer un scale-up/out dépend du type de goulot d’étranglement rencontré et de l’application configurée. Les instructions suivantes vous aideront à modifier les topologies de déploiement matériel en fonction des goulots d’étranglement rencontrés. Une application doit être créée à partir de zéro pour pouvoir tirer parti de la mise à l'échelle verticale/horizontale. Par exemple:

• Le scale-up d’un serveur avec un processeur et/ou une mémoire supplémentaires peut ne pas aider à résoudre le problème si l’application est sérialisée et dépendante d’un seul thread d’exécution.

• Le scale-out d’un système avec des serveurs supplémentaires peut ne pas aider si les serveurs supplémentaires ajoutent simplement une contention sur une ressource commune qui ne peut pas être mise à l’échelle. Toutefois, le scale-out offre des avantages supplémentaires. Le déploiement de deux serveurs double proc au lieu d’un serveur à quad-proc permet de fournir un serveur redondant qui sert le double objectif de la mise à l’échelle pour gérer un débit supplémentaire et fournit une topologie hautement disponible.