Générez des rapports et des graphiques avec des compteurs de performances avec l’outil Analyse des performances des journaux (PAL) pour BizTalk Server
L’outil PAL (Analyse des performances des journaux) lit dans un journal de compteur d’analyseur de performances (tout format connu) et l’analyse à l’aide de seuils complexes, mais connus (fournis). L’outil génère un rapport HTML qui graphiquement des compteurs de performances importants et génère des alertes lorsque les seuils sont dépassés. Les seuils sont initialement basés sur des seuils définis par les équipes de produits Microsoft, y compris les BizTalk Server et les membres du support Microsoft. Cet outil ne remplace pas l’analyse des performances traditionnelle, mais il automatise suffisamment l’analyse des journaux des compteurs de performances pour vous faire gagner du temps. L’outil PAL :
Analyse les journaux des compteurs de performances pour les seuils
Est utile pour les journaux Perfmon volumineux
Identifie les goulots d’étranglement BizTalk Server et de performances du système d’exploitation en analysant les seuils
Est extensible pour effectuer une analyse sur tous les compteurs de performances
Peut être utilisé pour vous aider à écrire votre propre compteur
PAL est disponible en téléchargement gratuit sur GitHub. Il nécessite Microsoft Log Parser. L’analyseur de journaux est un outil puissant et polyvalent qui fournit un accès universel aux requêtes aux données textuelles telles que les fichiers journaux, les fichiers XML et les fichiers CSV, ainsi qu’aux sources de données clés sur le système d’exploitation Windows, telles que le journal des événements, le registre, le système de fichiers et le service d’annuaire Active Directory®. Vous pouvez utiliser cet outil pour interroger une quantité importante d’informations de journalisation. Vous pouvez télécharger l’outil Log Parser.
Utilisation de PAL avec les journaux des compteurs de performances dans différents langages
L’outil PAL analyse les journaux des compteurs de performances uniquement en anglais. Pour utiliser l’outil PAL avec les journaux des compteurs de performances dans d’autres langues, vous devez d’abord traduire les journaux en anglais. Vous pouvez utiliser Perfmon Log Translator pour traduire les fichiers journaux du compteur de performances d’origine en anglais.
Présentation du rapport de l’outil PAL pour Microsoft BizTalk Server 2010
L’outil PAL fournit une analyse des journaux Perfmon des seuils pour le système d’exploitation Windows, Microsoft SQL Server et BizTalk Server. Cette section décrit la plupart des analyses du rapport BizTalk Server seuil dans l’outil PAL.
Notes
Cette rubrique est longue afin que des informations complètes sur l’outil PAL puissent être contenues dans un seul endroit pour une référence facile.
L’analyse et les seuils suivants sont signalés par l’outil PAL.
| Type et nom d’analyse | Description de l’analyse |
|---|---|
| Disque : espace libre sur le disque pour un vidage du noyau | Cette analyse vérifie qu’il y a suffisamment d’espace disque disponible pour que le système d’exploitation vide toute la mémoire sur le disque. Si l’espace disque disponible est insuffisant, le système d’exploitation ne parvient pas à créer un fichier memory.dmp, qui est nécessaire pour analyser la cause racine d’un vidage du noyau. |
| Disque : Analyse de l’interface de disque logique/physique | Cette analyse examine le temps d’inactivité de chacun des disques physiques. Plus le disque est inactif, moins il est utilisé. Ce compteur est mieux utilisé lorsqu’un disque est utilisé dans le disque logique. « % de temps d’inactivité » indique le pourcentage de temps pendant l’intervalle d’inactivité du disque pendant l’exemple. Référence : Exclure les problèmes Disk-Bound |
| Disque : Analyse de la latence en lecture/écriture de disque logique/physique | Le moyen le plus fiable pour Windows de détecter un goulot d’étranglement des performances de disque consiste à mesurer ses temps de réponse. Si les temps de réponse sont supérieurs à 0,025 (25 millisecondes), ce qui est un seuil conservateur, des ralentissements notables et des problèmes de performances affectant les utilisateurs peuvent se produire. Pour plus d’informations, consultez Analyse de la latence en lecture/écriture sur disque logique/physique dans cette rubrique. |
| Disque : Transferts de disques logiques/s | « Transferts de disque/s » est le taux d’opérations de lecture et d’écriture sur le disque. Les seuils de cette analyse case activée de voir si l’un des disques logiques affiche des temps de réponse médiocres (plus de 25 ms pour les opérations d’E/S). Si cela est vrai, les transferts de disque par seconde doivent être supérieurs ou égal à 80. Si ce n’est pas le cas, l’architecture du disque doit être examinée. La cause la plus courante d’E/S de disque médiocres est la surcharge des LUN sur le SAN. Pour plus d’informations, consultez Transfert de disque logique/s dans cette rubrique. |
| Disque : LogicalDisk % d’espace libre | « % d’espace libre » est le pourcentage d’espace total utilisable qui était libre sur le lecteur de disque logique sélectionné. Les performances ne doivent pas être affectées tant que l’espace disque disponible n’est pas inférieur à 30 %. Lorsque 70 % du lecteur de disque est utilisé, l’espace libre restant est situé plus près de la broche du disque au centre du lecteur de disque, qui fonctionne à un niveau de performances inférieur. Le manque d’espace disque libre peut entraîner des performances de disque sévères. |
| Disque : Traiter les opérations de données d’E/S/s et Traiter les autres opérations/s analyse | Ces compteurs comptent toutes les activités d’E/S générées par le processus pour inclure les E/S des fichiers, du réseau et des appareils. Ces analyses case activée lorsque les processus effectuent plus de 1 000 E/S par seconde et le signalent comme un avertissement. Ces analyses sont mieux utilisées en corrélation avec d’autres analyses telles que l’analyse de disque pour déterminer quels processus peuvent être impliqués dans l’activité d’E/S. |
| Mémoire : Mémoire disponible | Cette analyse vérifie si la mémoire totale disponible est faible : Avertissement à 10 % disponible et Critique à 5 % disponible. Un avertissement est également averti lorsqu’une tendance décroissante de 10 Mo par heure est détectée, ce qui peut indiquer une condition de mémoire potentielle à venir. Une mémoire physique insuffisante peut entraîner une augmentation des retards du processeur et du système en mode privilégié. Pour plus d’informations, reportez-vous à Available MemoryAnalysis dans cette rubrique. |
| Mémoire : Entrées de table de pages système libres | Les entrées de table de pages système (PTE) gratuites correspondent au nombre d’entrées de table de pages qui ne sont pas actuellement utilisées par le système. Cette analyse détermine si le système est à court de PTE en vérifiant s’il y a moins de 5 000 PTE gratuits avec un Avertissement s’il y a moins de 10 000 PTE libres. L’absence de suffisamment de PTE peut entraîner des blocages à l’échelle du système. Notez également que le commutateur /3 Go réduit considérablement la quantité de PTE libre. Pour plus d’informations, consultez Analyse des entrées de table de pages système gratuites dans cette rubrique. |
| Mémoire : Détection des fuites de mémoire | Cette analyse détermine si l’un des processus consomme une grande quantité de mémoire du système et si le processus augmente au fil du temps. Un processus qui consomme de grandes portions de mémoire est parfait tant que le processus retourne la mémoire au système. Recherchez les tendances croissantes dans le graphique. Une tendance à la hausse sur une longue période peut indiquer une fuite de mémoire. « Octets privés » est la taille actuelle, en octets, de la mémoire allouée par ce processus et qui ne peut pas être partagée avec d’autres processus. Cette analyse vérifie les tendances d’augmentation de 10 Mo par heure et de 5 Mo par heure. Utilisez cette analyse en corrélation avec l’analyse mémoire disponible dans PAL. Pour plus d’informations, consultez Analyse de la détection des fuites de mémoire dans cette rubrique. |
| Mémoire : Gérer la détection des fuites | Cette analyse vérifie tous les processus pour déterminer le nombre de handles ouverts et pour déterminer si une fuite de handle est suspectée. Un processus avec un grand nombre de handles et/ou une tendance à la hausse agressive peut indiquer une fuite de handle, ce qui entraîne généralement une fuite de mémoire. Le nombre total de handles actuellement ouverts par ce processus est égal à la somme des handles actuellement ouverts par chaque thread dans ce processus. Référence : Outil de diagnostic de débogage |
| Mémoire : Entrée des pages mémoire/s | « Entrée de pages/s » est la vitesse à laquelle les pages sont lues à partir du disque pour résoudre les erreurs de page matérielle. Un défaut de page matérielle se produit lorsqu'un processus fait référence à une page en mémoire virtuelle qui ne se trouve ni dans son jeu de travail, ni ailleurs en mémoire physique, et qui doit être récupérée à partir du disque. Cette analyse vérifie s’il y a plus de 10 lectures de fichiers de pages par seconde. |
| Mémoire : Pages mémoire/s | Cette analyse vérifie si la valeur « Pages/s » est élevée (au-dessus de 1 000). S’il est élevé, le système manque probablement de mémoire en essayant de pager la mémoire sur le disque. « Pages/s » est la vitesse à laquelle les pages sont lues ou écrites sur le disque pour résoudre les erreurs de page matérielle. Ce compteur est un indicateur principal des types d’erreurs qui provoquent des retards à l’échelle du système. Utilisez cette analyse en corrélation avec l’analyse mémoire disponible et l’analyse de détection des fuites de mémoire dans PAL. Si toutes ces analyses génèrent des alertes en même temps, cela peut indiquer que le système manque de mémoire et les processus suspects impliqués et suivre les étapes d’analyse mentionnées dans l’analyse de détection des fuites de mémoire dans PAL. Pour plus d’informations, consultez Analyse des pages mémoire/s dans cette rubrique. |
| Mémoire : Octets résidents du cache du système de mémoire | « Octets résidents du cache système » est la taille, en octets, du code du système d’exploitation paginable dans le cache du système de fichiers. Cette valeur inclut uniquement les pages physiques actuelles et n'inclut pas les pages de mémoire virtuelle qui ne sont pas actuellement résidantes. Cette valeur est un composant de « Memory\\System Code Resident Bytes » qui représente tout le code de système d’exploitation paginable qui se trouve actuellement dans la mémoire physique. Ce compteur correspond à la dernière valeur observée seulement et non à une moyenne sur un intervalle de temps. Cette analyse recherche une tendance à l’augmentation de 10 Mo par heure. En cas de charge, un serveur peut utiliser le cache système pour mettre en cache l’activité d’E/S telle que le disque. Utilisez en corrélation avec les analyses des opérations de données d’E/S de processus/s et d’autres opérations/secondes d’E/S de processus dans PAL. Référence : Performances et paramétrage du cache de fichiers |
| Mémoire : pool d’octets non paginés | « Octets non paginés du pool » est la taille, en octets, du pool non paginé, une zone de mémoire système pour les objets qui ne peuvent pas être écrits sur le disque, mais qui doivent rester en mémoire physique tant qu’ils sont alloués. Cette analyse vérifie si le système se rapproche de la taille maximale de mémoire non paginée du pool. Pour ce faire, il estime les tailles de pool en prenant en compte /3 Go, la taille de la mémoire physique et 32 bits/64 bits, puis détermine si la valeur est supérieure à 60 % de la taille estimée du pool. Si le système se rapproche de la taille maximale, le système peut rencontrer des blocages à l’échelle du système. L’option de commutateur /3 Go dans le fichier boot.ini réduit considérablement la taille de ce pool de mémoire. Pour plus d’informations, consultez Analyse des octets non paginés du pool dans cette rubrique. |
| Mémoire : octets paginés du pool | Cette analyse vérifie si le système approche de la taille maximale de mémoire paginée du pool. Pour ce faire, il estime les tailles de pool en prenant en compte /3 Go, la taille de la mémoire physique et 32 bits/64 bits, puis détermine si la valeur est supérieure à 60 % de la taille estimée du pool. Si le système se rapproche de la taille maximale, le système peut rencontrer des blocages à l’échelle du système. L’option de commutateur /3 Go dans le fichier boot.ini réduit considérablement la taille de ce pool de mémoire. Pour plus d’informations, consultez Analyse des octets paginés du pool dans cette rubrique. |
| Mémoire : nombre de threads de processus | Cette analyse vérifie tous les processus pour déterminer si un processus comporte plus de 500 threads et si le nombre de threads augmente de 50 threads par heure. Un processus avec un grand nombre de threads et/ou une tendance à la hausse agressive peut indiquer une fuite de thread qui se traduit généralement par une fuite de mémoire ou un basculement de contexte élevé. Un basculement de contexte élevé entraîne un processeur en mode à privilèges élevés. |
| Mémoire : Jeu de travail de traitement | « Working Set » est la taille actuelle, en octets, du jeu de travail de ce processus. L’ensemble de travail est l’ensemble de pages mémoire touchées récemment par les threads dans le processus. Si la mémoire disponible sur l’ordinateur est supérieure à un seuil, les pages sont laissées dans le jeu de travail d’un processus même si elles ne sont pas en cours d’utilisation. Lorsque la mémoire libre tombe en dessous d’un seuil, les pages sont supprimées des jeux de travail. S’ils sont nécessaires, ils seront ensuite remis en panne réversible dans le jeu de travail avant de quitter main mémoire. Cette analyse recherche une tendance croissante de 10 Mo ou plus dans chacun des processus. Utilisez en corrélation avec l’analyse de la mémoire disponible dans PAL. Référence : Recherche et élimination des goulots d’étranglement |
| Réseau : Analyse de la longueur de la file d’attente de sortie réseau | Cette analyse vérifie le nombre de threads en attente sur la carte réseau. Si un grand nombre de threads attendent sur la carte réseau, le système sature probablement les E/S réseau en raison de la latence réseau ou de la bande passante réseau. « Longueur de la file d’attente de sortie » est la longueur de la file d’attente de paquets de sortie (en paquets). Les retards sont indiqués si c’est plus de deux, et le goulot d’étranglement doit être trouvé et éliminé, si possible. Les causes typiques de la mise en file d’attente de sortie réseau incluent un nombre élevé de petites requêtes réseau et la latence du réseau. |
| Réseau : Analyse de l’utilisation du réseau | « Nombre total d’octets/s » est la vitesse à laquelle les octets sont envoyés et reçus sur chaque carte réseau, y compris les caractères d’encadrement. « Network Interface\Bytes Received/sec » est une somme de « Network Interface\Bytes Received/sec » et « Network Interface\Bytes Sent/sec ». Ce compteur vous permet de savoir si le trafic au niveau de votre carte réseau est saturé et si vous devez ajouter une autre carte réseau. La rapidité avec laquelle vous pouvez identifier un problème dépend du type de réseau dont vous disposez et du partage de bande passante avec d’autres applications. Cette analyse convertit « Nombre total d’octets/s » en bits et la compare à la bande passante actuelle de la carte réseau pour calculer l’utilisation du réseau. Ensuite, il recherche une utilisation supérieure à 50 %. Référence : Mesurer les performances à l’aide d’EventCounters dans .NET Core |
| Fichier de pagination : pourcentage d’utilisation du fichier de pagination et % d’utilisation maximale | La quantité du fichier de page instance en pourcentage. Voir aussi « Processus\\Octets de fichier de page ». Cette analyse vérifie si le pourcentage d’utilisation est supérieur à 70 %. |
| Processeur : analyse de l’utilisation du processeur et utilisation excessive du processeur par les processus | Ce compteur est le principal indicateur de l’activité du processeur et affiche le pourcentage moyen de temps de travail observé pendant l’intervalle d’échantillonnage. Elle est calculée en surveillant la durée d’inactivité du service et en soustrayant cette valeur de 100 %. Cette analyse vérifie l’utilisation de plus de 60 % sur chaque processeur. Si c’est le cas, déterminez s’il s’agit d’un mode processeur utilisateur élevé ou d’un mode à privilèges élevés. Si l’UC en mode à privilèges élevés est suspectée, consultez l’analyse du processeur en mode privilégié dans PAL. Si un goulot d’étranglement du processeur en mode utilisateur est suspecté, envisagez d’utiliser un profileur de processus pour analyser les fonctions à l’origine de la consommation élevée du processeur. |
| Processeur : Longueur de la file d’attente du processeur | Cette analyse détermine si la longueur moyenne de la file d’attente des processeurs dépasse le nombre de processeurs. Dans ce cas, cela peut indiquer un goulot d’étranglement du processeur. Utilisez cette analyse en corrélation avec l’analyse du processeur en mode privilégié et l’utilisation excessive du processeur par analyse de processus dans PAL. Pour plus d’informations, consultez Analyse de la longueur de file d’attente du processeur dans cette rubrique. |
| Processeur : Analyse du processeur en mode privilégié | Ce compteur indique le pourcentage de temps d’exécution d’un thread en mode privilégié. Lorsque votre application appelle des fonctions de système d’exploitation (par exemple pour effectuer des E/S de fichier ou réseau ou pour allouer de la mémoire), ces fonctions de système d’exploitation sont exécutées en mode privilégié. Cette analyse vérifie si le processeur en mode privilégié consomme plus de 30 % du processeur total. Si tel est le cas, la consommation du processeur est probablement due à un autre goulot d’étranglement que le processeur, tel que le réseau, la mémoire ou les E/S de disque. Utilisation en corrélation avec les analyses Processeur : % temps d’interruption et Processeur : basculement de contexte élevé dans PAL. Pour plus d’informations, consultez Analyse du processeur en mode privilégié dans cette rubrique. |
| Processeur : Temps d’interruption | « % de temps d’interruption » est le temps que le processeur passe à recevoir et à traiter les interruptions matérielles pendant les intervalles d’échantillonnage. Cette valeur est un indicateur indirect de l'activité des périphériques qui génèrent des interruptions tels que les horloges système, la souris, les pilotes de disques, les lignes de communication de données, les cartes d'interface réseau et d'autres périphériques. Ces périphériques interrompent généralement le processeur lorsqu'une tâche est terminée ou nécessite une attention. L'exécution normale des threads est suspendue durant les interruptions. La plupart des horloges système interrompent le processeur toutes les 10 millisecondes, ce qui crée un arrière-plan d'activité d'interruption. Une augmentation spectaculaire de ce compteur indique des problèmes matériels potentiels. Cette analyse vérifie que « % de temps d’interruption » est supérieur à 30 pour cent. Si cela se produit, envisagez de mettre à jour les pilotes d’appareils pour le matériel en corrélation avec cette alerte. Référence : Mesurer les performances à l’aide d’EventCounters dans .NET Core |
| Processeur : basculement de contexte élevé | Un changement de contexte se produit lorsqu’un thread de priorité plus élevée préempte un thread de priorité inférieure en cours d’exécution ou lorsqu’un thread de priorité élevée se bloque. Des niveaux élevés de basculement de contexte peuvent se produire lorsque de nombreux threads partagent le même niveau de priorité. Cela indique souvent qu’un trop grand nombre de threads sont en concurrence pour les processeurs sur le système. En règle générale, les taux de basculement de contexte inférieurs à 5 000 par seconde par processeur ne sont pas la peine de s’inquiéter. Si les taux de basculement de contexte dépassent 15 000 par seconde par processeur, il existe une contrainte. Pour plus d’informations, consultez Analyse de la commutation de contexte élevé dans cette rubrique. |
| Microsof BizTalk Server : Orchestrations de déshydratage BizTalk | Lorsque de nombreux processus métier de longue durée s’exécutent en même temps, des problèmes de mémoire et de performances sont possibles. Le moteur d'orchestration résout ces problèmes en « mettant en attente » et en « réalimentant » les instances d'orchestration. La mise en attente est le processus qui consiste à sérialiser l'état d'une orchestration dans une base de données SQL Server. La réactivation est l’inverse de ce processus : désérialisation du dernier état d’exécution d’une orchestration à partir de la base de données. La mise en attente est utilisée pour réduire au maximum l'utilisation de ressources système en réduisant le nombre d'orchestrations qui doivent être instanciées simultanément. Par conséquent, les déshyrations permettent d’économiser la consommation de mémoire, mais sont des opérations relativement coûteuses à effectuer. Cette analyse vérifie les déshydratations de 10 ou plus. Si c’est le cas, BizTalk Server manque peut-être de mémoire (virtuelle ou physique), un grand nombre d’orchestrations sont en attente de messages ou les paramètres de déshydratation ne sont pas correctement définis. Référence : Déshydratation et réactivation de l’orchestration |
| Microsoft BizTalk Server : Sessions de base de données élevée BizTalk | Ce compteur a deux valeurs possibles : normale (0) ou dépassée (1). Cette analyse vérifie la valeur 1. Dans ce cas, BizTalk a dépassé le seuil du nombre de sessions de base de données autorisées. Cette valeur est contrôlée par la valeur « Connexion de base de données par processeur » dans les paramètres de limitation de l’hôte BizTalk. « Connexion de base de données par processeur » correspond au nombre maximal de sessions de base de données simultanées (par processeur) autorisées avant le début de la limitation. Vous pouvez contrôler le nombre de connexions actives à la base de données en utilisant le compteur de performances Session de base de données sous la catégorie d'objet de performance BizTalk:agent des messages. Ce paramètre a une incidence uniquement sur la limitation basée sur la fréquence des messages sortants. Pour plus d’informations, consultez Analyse des sessions de base de données élevée BizTalk dans cette rubrique. |
| Microsoft BizTalk Server : Taille élevée de la base de données BizTalk | Ce compteur est défini sur la valeur 1 si l’une des conditions répertoriées pour le nombre de messages dans le seuil de base de données se produit. Par défaut, le nombre de messages hôtes dans le seuil de limitation de base de données est défini sur une valeur de 50 000, ce qui déclenche une condition de limitation dans les circonstances suivantes : - Le nombre total de messages publiés par l’hôte instance aux files d’attente de travail, d’état et suspendus des hôtes abonnés dépasse 50 000. - Le nombre de messages dans la table spool ou la table de suivi dépasse 500 000 messages. Si cela se produit, envisagez une ligne de conduite qui réduira le nombre de messages dans la base de données. Par exemple, assurez-vous que les travaux SQL Server dans BizTalk Server s’exécutent sans erreur et utilisez la page Hub de groupe de la console Administration BizTalk Server pour déterminer si la génération de messages est due à un grand nombre de messages suspendus. Pour plus d’informations, reportez-vous à BizTalk High Database Size Analysis dans cette rubrique. |
| Microsoft BizTalk Server : Nombre de messages bizTalk à haut In-Process | Cette analyse vérifie le compteur Nombre de messages In-Process élevé pour déterminer si ce type de limitation se produit. Si c’est le cas, envisagez d’ajuster le paramètre « Messages en cours de traitement par processeur ». Ce paramètre a une incidence uniquement sur la limitation basée sur la fréquence des messages sortants. Entrez la valeur 0 dans le paramètre « Messages en cours de traitement par processeur » pour désactiver la limitation en fonction du nombre de messages en cours de traitement par processeur. La valeur par défaut pour le paramètre « Messages en cours de traitement par processeur » est 1 000. Notez que la modification de cette valeur peut également avoir un impact sur la faible latence des messages et/ou sur l’efficacité des ressources BizTalk. Pour plus d’informations, reportez-vous à BizTalk High In-Process Message Count Analysis dans cette rubrique. |
| Microsoft BizTalk Server : Taux de remise élevé de messages BizTalk | Cette analyse vérifie la valeur 1 dans le compteur Taux de remise de messages élevé. Les taux de remise élevés des messages peuvent être causés par une complexité de traitement élevée, des cartes sortantes lentes ou une pénurie momentanée de ressources système. Pour plus d’informations, consultez Analyse du taux de remise de messages élevé bizTalk dans cette rubrique. |
| Microsoft BizTalk Server : Taux élevé de publication de messages BizTalk | La limitation de l'hôte au niveau des entrées, également appelée limitation de la publication des messages, dans BizTalk Server, est appliquée aux instances de l'hôte qui contiennent des adaptateurs de réception ou des orchestrations qui publient des messages dans la base de données MessageBox. Cette analyse vérifie la valeur 1 dans le compteur Taux de publication de messages élevé. Si cela se produit, la base de données ne peut pas suivre le rythme de publication des messages dans la base de données BizTalk MessageBox. Références : - Compteurs de performances de limitation de l’hôte - Comment BizTalk Server implémente la limitation de l’hôte - Modifier les paramètres de limitation basés sur le débit - Qu’est-ce que la limitation de l’hôte ? |
| Microsoft BizTalk Server : Mémoire de processus élevée BizTalk | Le paramètre de seuil de limitation de l’utilisation de la mémoire du processus BizTalk correspond au pourcentage de mémoire utilisé par rapport à la somme de la taille de l’ensemble de travail et de la mémoire virtuelle totale disponible pour le processus si une valeur comprise entre 1 et 100 est entrée. Lorsqu' une valeur de pourcentage est spécifiée, le seuil de mémoire de processus est recalculé à intervalles réguliers. Cette analyse vérifie la valeur 1 dans le compteur mémoire de processus élevé. Pour plus d’informations, consultez Analyse de la mémoire de processus élevés BizTalk dans cette rubrique. |
| Microsoft BizTalk Server : Mémoire système élevée BizTalk | Le paramètre de seuil de limitation de l’utilisation de la mémoire physique BizTalk est le pourcentage de consommation de mémoire par rapport à la quantité totale de mémoire physique disponible si une valeur comprise entre 1 et 100 est entrée. Ce paramètre peut également correspondre à la quantité totale de mémoire physique disponible en mégaoctets si une valeur supérieure à 100 est entrée. Entrez la valeur 0 pour désactiver la limitation basée sur l'utilisation de la mémoire physique. La valeur par défaut est 0. Pour plus d’informations, reportez-vous à Analyse de la mémoire haute système BizTalk dans cette rubrique. |
| Microsoft BizTalk Server : Nombre élevé de threads BizTalk | « Threads par processeur » correspond au nombre total de threads dans le processus hôte, y compris les threads utilisés par les adaptateurs. Si ce seuil est dépassé, BizTalk Server tente de réduire la taille du pool de threads EPM et du pool de threads d’agent de messages. La limitation basée sur les threads doit être activée dans les scénarios dans lesquels des charges élevées peuvent conduire à la création d'un grand nombre de threads. Ce paramètre a une incidence sur la limitation au niveau des entrées et des sorties. La limitation basée sur les threads est désactivée par défaut. Pour plus d’informations, consultez Analyse du nombre élevé de threads BizTalk dans cette rubrique. |
| Microsoft BizTalk Server : Longueur de la file d’attente de l’hôte BizTalk | La longueur de la file d’attente de l’hôte BizTalk suit le nombre total de messages dans la file d’attente hôte particulière. Vous pouvez utiliser la taille de longueur, par exemple BizTalk:MessageBox:HostCounters:Host Queue – Length, pour donner une vue plus détaillée du nombre de messages mis en file d’attente en interne en affichant la profondeur de la file d’attente d’un hôte individuel. Ce compteur peut être utile pour déterminer si un hôte spécifique est goulot d’étranglement. En supposant que des hôtes uniques soient utilisés pour chaque transport, cela peut être utile pour déterminer les goulots d’étranglement potentiels du transport. Cette analyse vérifie les longueurs moyennes de file d’attente supérieures à 1. La longueur de la file d’attente de l’hôte est une longueur de file d’attente pondérée en agrégeant le nombre d’enregistrements de toutes les files d’attente (Q de travail, Q d’état, Q suspendu) de l’hôte cible. Référence : BizTalk Server 2010 : méthodologie de test des performances BizTalk Server |
| Microsoft BizTalk Server : Longueur de la file d’attente des messages suspendus de l’hôte BizTalk | Ce compteur effectue le suivi du nombre total de messages suspendus pour l’hôte particulier. Un message suspendu est un instance d’un message ou d’une orchestration que BizTalk Server a cessé de traiter en raison d’une erreur dans le système ou le message. Les instances dont l'exécution a été interrompue suite à des erreurs système peuvent généralement reprendre une fois le problème résolu. En revanche, les instances dont l'exécution a été suspendue en raison d'un problème de message ne peuvent généralement pas reprendre et le message doit être réparé avant d'être renvoyé au système BizTalk Server. La file d’attente de messages suspendue est une file d’attente qui contient des éléments de travail pour lesquels une erreur ou une défaillance a été rencontrée pendant le traitement. La file d'attente de messages interrompus stocke les messages jusqu'à ce qu'ils soient corrigés et de nouveau traités, ou bien supprimés. Cette analyse vérifie toute occurrence de messages suspendus. Une tendance croissante pourrait indiquer de graves erreurs de traitement. Références : - Surveillance de l’intégrité et des performances BizTalk Server - Résolution des problèmes liés à Microsoft BizTalk Server |
| BizTalk Server : Orchestrations inactives BizTalk | Nombre d'instances d'orchestration inactives actuellement hébergées par l'instance de l'hôte. Ce compteur fait référence aux orchestrations qui ne progressent pas, mais qui ne sont pas déshydratables. Cette situation peut se produire lorsque l’orchestration est bloquée, en attente d’une réception, d’une écoute ou d’un retard dans une transaction atomique. Si un grand nombre d’orchestrations non déshydratables s’accumulent, BizTalk peut manquer de mémoire. La mise en attente est le processus qui consiste à sérialiser l'état d'une orchestration dans une base de données SQL Server. La réhydratation est l’inverse de ce processus : désérialisation du dernier état d’exécution d’une orchestration à partir de la base de données. La mise en attente est utilisée pour réduire au maximum l'utilisation de ressources système en réduisant le nombre d'orchestrations qui doivent être instanciées simultanément. Le moteur met l'instance en attente en enregistrant l'état et libère la mémoire requise par l'instance. En déshydratant les instances d’orchestration dormantes, le moteur permet à un grand nombre de processus métier de longue durée de s’exécuter simultanément sur le même ordinateur. Cette analyse vérifie la tendance croissante d’une orchestration inactive par heure. Référence : Déshydratation et réhydratation de l’orchestration. |
| BizTalk Server : Latence entrante BizTalk | Latence moyenne en millisecondes entre le moment où le moteur de messagerie reçoit un document de l’adaptateur jusqu’à sa publication dans MessageBox. La réduction de la latence est importante pour certains utilisateurs de BizTalk. Par conséquent, il est important de suivre le temps passé par les documents dans l’adaptateur entrant. Pour plus d’informations, consultez Analyse de la latence entrante BizTalk dans cette rubrique. |
| BizTalk Server : Délai de remise des messages BizTalk | Il s’agit du délai actuel en millisecondes (ms) imposé à chaque lot de remise de messages (applicable si la remise du message est limitée). En ce qui concerne la limitation, un délai est appliqué dans la publication ou le traitement du message, selon que le message est entrant ou sortant. La période de retard est proportionnelle à la gravité de la condition de limitation. Les conditions de limitation de gravité plus élevée déclenchent une période de limitation plus longue que les conditions de limitation de gravité inférieures. La durée du délai est ajustée à la baisse ou à la hausse dans la limite de plages par le mécanisme de limitation au fur et à mesure que les conditions évoluent. La période de retard actuelle est exposée via le délai de remise des messages (ms) et les compteurs de performances de délai de publication des messages (ms) associés à la catégorie d’objets de performance BizTalk:Message Agent. Cette analyse recherche un délai de remise de message supérieur à 5 secondes. De longs retards de remise des messages peuvent indiquer une forte limitation en raison d’une charge élevée. Référence : Comment BizTalk Server implémente la limitation de l’hôte. |
| BizTalk Server : État de limitation de la remise de messages BizTalk | L’état de limitation de remise de messages BizTalk est l’un des principaux indicateurs de limitation. Il s’agit d’un indicateur indiquant si le système limite la remise des messages (affectant le traitement des messages XLANG et les transports sortants). La condition de limitation est indiquée par la valeur numérique du compteur. Pour plus d’informations, consultez Analyse de l’état de limitation de la remise de messages BizTalk dans cette rubrique. |
| BizTalk Server : Délai de publication de messages BizTalk | Délai injecté dans chaque lot éligible pour limiter la publication des messages. En ce qui concerne la limitation, un délai est appliqué dans la publication ou le traitement du message, selon que le message est entrant ou sortant. La période de retard est proportionnelle à la gravité de la condition de limitation. Les conditions de limitation de gravité plus élevée déclenchent une période de limitation plus longue que les conditions de limitation de gravité inférieures. La durée du délai est ajustée à la baisse ou à la hausse dans la limite de plages par le mécanisme de limitation au fur et à mesure que les conditions évoluent. La période de retard actuelle est exposée via le délai de remise des messages (ms) et les compteurs de performances de délai de publication des messages (ms) associés à la catégorie d’objets de performance BizTalk:Message Agent. Cette analyse recherche un délai de publication de message supérieur à 5 secondes. De longs retards de remise des messages peuvent indiquer une forte limitation en raison d’une charge élevée. Référence : Comment BizTalk Server implémente la limitation de l’hôte. |
| BizTalk Server : Échecs de connexion de base de données BizTalk MessageBox | Ce compteur de performances correspond au nombre de tentatives d’connexions aux bases de données qui ont échoué depuis que l’hôte instance démarré. Si le service SQL Server qui héberge les bases de données BizTalk devient indisponible pour une raison quelconque, le cluster de base de données transfère les ressources de l’ordinateur actif vers l’ordinateur passif. Lors de ce processus de basculement, les instances du service BizTalk Server rencontrent des problèmes de connexion aux bases de données et relancent automatiquement ces connexions. L'ordinateur contenant la base de données indemne (ordinateur jusqu'alors passif) commence à traiter les connexions de la base de données après avoir pris en charge les ressources durant le basculement. Pour plus d’informations, consultez Analyse des échecs de connexion de base de données BizTalk MessageBox dans cette rubrique. |
| BizTalk Server : Latence de la messagerie BizTalk : latence de réponse aux demandes | Latence moyenne, en millisecondes, entre le moment où le moteur de messagerie reçoit un document de requête de l'adaptateur et le moment où un document de réponse est renvoyé vers l'adaptateur. Reportez-vous au graphique montrant comment la latence est mesurée dans Analyse de la latence entrante BizTalk dans cette rubrique. En supposant un environnement à faible latence, cette analyse recherche une latence Request-Response supérieure à 5 secondes. Cela peut indiquer un délai de traitement entre l’adaptateur entrant et l’adaptateur sortant. Références : - Messagerie de demande/réponse - Mise à l’échelle de vos solutions |
| BizTalk Server : État de limitation de la publication de messagerie BizTalk | L’état de limitation de publication de messages BizTalk est l’un des principaux indicateurs de limitation. Il s’agit d’un indicateur indiquant si le système limite la publication des messages (ce qui affecte le traitement des messages XLANG et les transports entrants). Pour plus d’informations, consultez Analyse de l’état de limitation de la publication de la messagerie BizTalk dans cette rubrique. |
| BizTalk Server : Orchestration BizTalk suspendue/seconde | Un message suspendu est un instance d’un message ou d’une orchestration que BizTalk Server a cessé de traiter en raison d’une erreur dans le système ou le message. Les instances dont l'exécution a été interrompue suite à des erreurs système peuvent généralement reprendre une fois le problème résolu. En revanche, les instances dont l'exécution a été suspendue en raison d'un problème de message ne peuvent généralement pas reprendre et le message doit être réparé avant d'être renvoyé au système BizTalk Server. Cette analyse vérifie la présence de messages/orchestrations suspendus. Références : - Surveillance de l’intégrité et des performances BizTalk Server - Résolution des problèmes liés à Microsoft BizTalk Server |
| BizTalk Server : Orchestrations BizTalk terminées/seconde | Il s’agit du nombre d’orchestrations BizTalk effectuées par seconde. Il s’agit d’un bon indicateur de la quantité de débit que BizTalk traite. Cette analyse fournit uniquement des statistiques. Référence : Mise à l’échelle de vos solutions |
| BizTalk Server : Orchestrations BizTalk ignorées | Nombre d'instances d'orchestration supprimées de la mémoire depuis le démarrage de l'instance de l'hôte. Une orchestration peut être supprimée si le moteur ne parvient pas à conserver son état. Cette analyse vérifie tous les messages ignorés. Référence : WebLog du moteur BizTalk Core |
| BizTalk Server : Orchestrations BizTalk résident dans la mémoire | Nombre d'instances d'orchestration actuellement hébergées par l'instance de l'hôte. Cette analyse vérifie une tendance croissante des orchestrations résidant dans la mémoire et si plus de 50 % des orchestrations résidant dans la mémoire ne sont pas déshydratables. Pour plus d’informations, consultez Orchestrations BizTalk résident dans l’analyse de la mémoire. |
| BizTalk Server : Latence de l’adaptateur sortant BizTalk | Il s’agit de la latence moyenne en secondes entre le moment où l’adaptateur obtient un document à partir du moteur de messagerie jusqu’à l’heure à laquelle il est envoyé par l’adaptateur. Reportez-vous au graphique montrant comment la latence est mesurée dans Analyse de la latence entrante BizTalk dans cette rubrique. En supposant un environnement à faible latence, cette analyse vérifie la latence dans l’adaptateur sortant supérieur à 5 secondes en moyenne. Cela peut indiquer un retard de traitement dans le transport des messages via des adaptateurs sortants dans cette instance hôte. Si plusieurs cartes sortantes existent dans cette instance hôte, envisagez de les séparer en leurs propres hôtes pour déterminer quelle carte sortante a une latence élevée. Références : - Messagerie de demande/réponse. - BizTalk Server 2006 : Étude de cas de scalabilité à l’aide de l’adaptateur SOAP dans BizTalk Server 2006 - Identification des goulots d’étranglement dans le niveau BizTalk - Optimisations des scénarios à faible latence pour BizTalk Server |
| BizTalk Server : Messages en attente BizTalk | Nombre de messages reçus qui n’ont pas été reconnus comme étant reçus dans MessageBox. Les messages en attente sont des messages qui ont été extraits en mémoire et remis à l’orchestration XLANG, mais qui n’ont pas encore été traités. Cette circonstance n’a rien à voir avec la perte de données. La remise d’un message à une orchestration est un processus en plusieurs étapes et est simplement un instance du message résidant dans la table de spouleur de la base de données. Ces messages en attente sont comptabilisés comme des messages in-process ; par conséquent, le fait d’avoir un grand nombre d’entre eux en mémoire peut entraîner une limitation de la mémoire sur le système. L’ajustement du paramètre Taille de file d’attente de messages internes peut vous aider à contrôler le nombre de messages en attente. Le paramètre messages In-Process par processeur a un impact sur le moment où la limitation est appelée lorsqu’un nombre élevé de messages en attente se produit. Ces paramètres se trouvent dans les propriétés de l’hôte dans la console d’administration BizTalk. Cette analyse vérifie uniquement les statistiques pour ce compteur. Référence : Compteurs de performances du moteur d’orchestration. |
| BizTalk Server : Points de persistance BizTalk/seconde | Nombre moyen d'instances d'orchestration enregistrées par seconde. Le moteur d'orchestration enregistre l'état d'une instance d'orchestration en cours d'exécution en différents points. S’il doit réhydrater le instance d’orchestration, démarrer à partir d’un arrêt contrôlé ou récupérer après un arrêt inattendu, il exécute l’orchestration instance à partir du dernier point de persistance. Pour conserver une instance d’orchestration, toutes les instances d’objet auxquelles votre orchestration fait référence directement ou indirectement (comme par le biais d’autres objets) doivent être sérialisables. À mesure que la fréquence de persistance des messages (le nombre de fois où les données doivent être conservées) augmente, les performances globales diminuent. En effet, chaque point de persistance est un aller-retour vers la base de données. Par conséquent, réduisez chaque fois que possible la fréquence des points de persistance en évitant ou en consolidant les points de persistance. Pour plus d’informations sur le moment où des points de persistance se produisent, consultez les références ci-dessous. Cette analyse vérifie plus de 10 points de persistance par seconde en moyenne. Il s’agit d’un point de départ général. Références : - Persistance dans les orchestrations - Persistance et moteur d’orchestration |
| BizTalk Server : Octets privés BizTalk | Il s’agit des mégaoctets de mémoire privée allouée pour l’hôte instance et comparable au compteur de performances « \Process(*)\Private Bytes ». Cette analyse détermine si l’une des instances de l’hôte consomme une grande taille de la mémoire du système et si la instance hôte augmente au fil du temps. Pour plus d’informations, consultez Analyse des octets privés BizTalk dans cette rubrique. |
| BizTalk Server : Taille de table de pool BizTalk | La table de pool MessageBox contient un enregistrement pour chaque message dans le système (actif ou en attente d’être « garbage collected »). La surveillance du nombre de lignes dans cette table et du nombre de messages reçus par seconde tout en augmentant la charge système permet de trouver facilement le débit maximal durable. Augmentez simplement la charge d’entrée jusqu’à ce que 1) la table de spoulage commence à augmenter indéfiniment ou 2) le nombre de messages reçus par seconde plateaux, selon ce qui arrive en premier, et c’est votre débit maximal durable. En résumé, quels que soient les autres indicateurs, cette mesure vous permettra d’évaluer rapidement et facilement si votre système est surmené ou non. Lorsque la taille des tables de pool BizTalk est sur une tendance croissante, une limitation en raison d’un taux de remise de messages déséquilibré (le taux d’entrée dépasse le taux de sortie) ou d’une limitation en raison de la taille de la base de données peut se produire. Cette analyse recherche une tendance croissante dans la taille de table du pool BizTalk. Références : - Présentation du débit et de la capacité BizTalk Server 2004 SP1 - Test de charge durable - Recommandations lors du test des performances du moteur. |
| BizTalk Server : Taille des données de suivi BizTalk | À mesure que BizTalk Server traite de plus en plus de données sur votre système, la base de données de suivi BizTalk (BizTalkDTADb) continue de croître en taille. Cette croissance non contrôlée affecte la performance du système et peut générer des erreurs dans le service TDDS (Tracking Data Delivery Service). Outre les données de suivi générales, les messages suivis peuvent également s'accumuler dans la base de données MessageBox, affectant ainsi les performances du disque. Cette analyse recherche une tendance à l’augmentation de plus de 5 Mo par heure dans la taille des données de suivi. Référence : Archivage et purge de la base de données de suivi BizTalk |
| BizTalk Server : Étendues transactionnelles BizTalk abandonnées | Il s’agit du nombre d’étendues atomiques ou de longue durée qui ont été abandonnées depuis que l’hôte instance démarré. Un abandon d’étendue transactionnelle est un échec qui se produit dans une étendue de transaction au sein d’une orchestration. Il est important de comprendre que le gestionnaire de compensation d’une étendue est appelé uniquement si l’étendue s’est terminée correctement, mais qu’elle doit ensuite être annulée parce qu’une étendue environnante a décidé d’abandonner (en raison de défaillances susceptibles de se produire plus tard dans le processus). En outre, aucune restauration « automatique » de l’état ne se produit en cas d’abandon de transaction. Vous pouvez atteindre ce résultat par programme via les gestionnaires d’exceptions et de compensation. Les abandons d’étendue transactionnelle ne doivent normalement pas se produire dans un environnement de production ; Par conséquent, cette analyse vérifie l’occurrence de toutes les étendues transactionnelles abandonnées. Référence : Transactions |
| BizTalk Server : Étendues transactionnelles BizTalk compensées | La compensation peut être considérée comme une annulation logique du travail qui a été correctement engagé en réponse à une condition d’erreur. Il est important de comprendre que le gestionnaire de compensation d’une étendue est appelé uniquement si l’étendue s’est terminée correctement, mais qu’elle doit ensuite être annulée parce qu’une étendue environnante a décidé d’abandonner (en raison de défaillances susceptibles de se produire plus tard dans le processus). En outre, aucune restauration « automatique » de l’état ne se produit en cas d’abandon de transaction. Vous pouvez obtenir cette restauration par programme grâce aux gestionnaires d'exception et de compensation. Les compensations d’étendue transactionnelle ne doivent normalement pas se produire dans un environnement de production ; Par conséquent, cette analyse vérifie l’occurrence de toutes les étendues transactionnelles abandonnées. Référence : Transactions |
| BizTalk Server : Octets virtuels BizTalk | Il s’agit des mégaoctets réservés à la mémoire virtuelle pour le instance hôte. Cette analyse détermine si l’une des instances de l’hôte consomme une grande quantité de mémoire du système et si la consommation de mémoire de l’hôte instance augmente au fil du temps. Pour plus d’informations, consultez Analyse des octets virtuels BizTalk dans cette rubrique. |
| BizTalk Server : Limitation de session de base de données de l’Agent de message BizTalk | Il s’agit du nombre de connexions aux bases de données ouvertes à MessageBox par rapport à son paramètre de limitation BizTalk respectif. « Connexion de base de données par processeur » est le nombre maximal de sessions de base de données simultanées (par PROCESSEUR) autorisées avant le début de la limitation. Pour plus d’informations, consultez Analyse de la limitation de session de la base de données de l’Agent de message BizTalk dans cette rubrique. |
| BizTalk Server : Seuil de limitation de session de base de données de l’agent de message BizTalk | Il s’agit du seuil actuel pour le nombre de connexions aux bases de données ouvertes dans messageBox. « Connexion de base de données par processeur » est le nombre maximal de sessions de base de données simultanées (par PROCESSEUR) autorisées avant le début de la limitation. Pour plus d’informations, consultez Analyse du seuil de limitation de session de la base de données de l’Agent de message BizTalk dans cette rubrique. |
| BizTalk Server : Limitation du nombre de messages in-process de l’agent de message BizTalk | Il s’agit du nombre de messages simultanés que la classe de service traite. Le paramètre « Messages in-process par processeur » dans les paramètres de limitation de l’hôte correspond au nombre maximal de messages remis au gestionnaire de points de terminaison (EPM) ou XLANG qui n’ont pas été traités. Pour plus d’informations, consultez Analyse de la limitation du nombre de messages in-process de l’agent de message BizTalk dans cette rubrique. |
| BizTalk Server : Seuil de limitation du nombre de messages in-process de l’agent de message BizTalk | Il s’agit du seuil actuel du nombre de messages simultanés que la classe de service traite. Le paramètre « Messages in-process par processeur » dans les paramètres de limitation de l’hôte correspond au nombre maximal de messages remis au gestionnaire de points de terminaison (EPM) ou XLANG qui n’ont pas été traités. Pour plus d’informations, consultez Analyse du seuil de limitation du nombre de messages in-process de l’agent de message BizTalk dans cette rubrique. |
| BizTalk Server : Limitation de l’utilisation de la mémoire du processus de l’agent de message BizTalk (Mo) | Il s’agit de l’utilisation de la mémoire du processus actuel (Mo). Une limitation de la mémoire de processus BizTalk peut se produire si le lot à publier a des besoins en mémoire considérables ou si trop de threads traitent des messages. Pour plus d’informations, consultez Analyse de la limitation de la mémoire de l’agent de message BizTalk (Mo) dans cette rubrique. |
| BizTalk Server : Seuil de limitation de la mémoire de l’agent de message BizTalk (Mo) | Il s’agit du seuil actuel pour l’utilisation de la mémoire du processus actuel (Mo). Le seuil peut être ajusté dynamiquement en fonction de la quantité réelle de mémoire disponible pour ce processus et de son modèle de consommation de mémoire. Une limitation de la mémoire de processus BizTalk peut se produire si le lot à publier a des besoins en mémoire considérables ou si trop de threads traitent des messages. Pour plus d’informations, consultez Analyse du seuil de limitation de l’utilisation de la mémoire du processus de message BizTalk (Mo) dans cette rubrique. |
| BizTalk Server : Limitation du nombre de threads de l’agent de message BizTalk | Nombre total de threads dans le processus BizTalk. « Threads par processeur » est le nombre total de threads dans le processus hôte, y compris les threads utilisés par les adaptateurs. Si ce seuil est dépassé, BizTalk Server essaie de réduire la taille du pool de threads du Gestionnaire des points de terminaison et celle du pool de threads de l'agent des messages. La limitation basée sur les threads doit être activée dans les scénarios dans lesquels des charges élevées peuvent conduire à la création d'un grand nombre de threads. Ce paramètre a une incidence sur la limitation au niveau des entrées et des sorties. La limitation basée sur les threads est désactivée par défaut. Cette analyse vérifie si le nombre de threads BizTalk est supérieur à 80 % de la valeur du seuil de limitation, ce qui indique qu’une condition de limitation est probable. Références : - Compteurs de performances de limitation de l’hôte - Comment BizTalk Server implémente la limitation de l’hôte - Comment modifier les paramètres de limitation d’hôte par défaut - Paramètres de configuration qui affectent les performances de l’adaptateur - Threads, sessions de base de données et limitation |
| BizTalk Server : Seuil de limitation du nombre de threads de l’agent de message BizTalk | Il s’agit du seuil actuel pour le nombre total de threads dans le processus. « Threads par processeur » est le nombre total de threads dans le processus hôte, y compris les threads utilisés par les adaptateurs. Si ce seuil est dépassé, BizTalk Server essaie de réduire la taille du pool de threads du Gestionnaire des points de terminaison et celle du pool de threads de l'agent des messages. La limitation basée sur les threads doit être activée dans les scénarios où une charge élevée peut entraîner la création d’un grand nombre de threads. Ce paramètre a une incidence sur la limitation au niveau des entrées et des sorties. Cette analyse vérifie si ce paramètre de limitation est défini sur une valeur autre que celle par défaut. La limitation basée sur les threads est désactivée par défaut. Références : - Compteurs de performances de limitation de l’hôte - Comment BizTalk Server implémente la limitation de l’hôte - Comment modifier les paramètres de limitation d’hôte par défaut - Paramètres de configuration qui affectent les performances de l’adaptateur - Threads, sessions de base de données et limitation |
Analyse de la latence en lecture/écriture sur disque logique/physique
Le moyen le plus fiable pour Windows de détecter un goulot d’étranglement des performances de disque consiste à mesurer ses temps de réponse. Si les temps de réponse sont supérieurs à 0,025 (25 millisecondes), ce qui est un seuil conservateur, des ralentissements notables et des problèmes de performances affectant les utilisateurs peuvent se produire.
Les causes courantes d’une faible latence du disque sont la fragmentation du disque, le cache de performances, un RÉSEAU san saturé et une trop grande charge sur le disque. Utilisez l’outil SPA pour identifier les principaux fichiers et processus à l’aide du disque. Vous case activée également « Traiter les opérations de données d’E/S/s » et « Traiter les autres opérations d’E/S /s » pour voir quels processus consomment le plus d’E/S sur disque. Gardez à l’esprit que les compteurs de l’analyseur de performances ne peuvent pas spécifier quels fichiers sont impliqués.
Références
Transferts de disque logique/s
« Transferts de disque/s » est le taux d’opérations de lecture et d’écriture sur le disque. Bien que les transferts de disque ne soient pas une corrélation directe avec les E/S de disque, ils nous indiquent le nombre d’opérations sur disque qui se produisent. Si vous effectuez une moyenne d’E/S séquentielles et d’E/S aléatoires, vous vous retrouvez avec environ 80 E/S par seconde en règle générale. Par conséquent, nous devons nous attendre à ce qu’un lecteur SAN effectue plus de 80 E/S par seconde en cas de charge. Les seuils de cette analyse case activée de voir si l’un des disques logiques affiche des temps de réponse médiocres (plus de 25 ms pour les opérations d’E/S). Si cela est vrai, nous devons nous attendre à ce que les transferts de disque par seconde soient à 80 ou plus. Si ce n’est pas le cas, l’architecture de disque doit être examinée. La cause la plus courante d’une mauvaise E/S disque est la surcharge de numéro d’unité logique (LUN) sur le SAN, c’est-à-dire la condition dans laquelle plusieurs LUN utilisent la petite baie de disques physiques.
Analyse de la mémoire disponible
« Octets disponibles » est la quantité de mémoire physique disponible pour les processus en cours d’exécution sur l’ordinateur, en mégaoctets. Virtual Memory Manager ajuste continuellement l’espace utilisé dans la mémoire physique et sur le disque pour conserver un nombre minimal d’octets disponibles pour le système d’exploitation et les processus. Lorsque les octets disponibles sont nombreux, virtual Memory Manager permet aux ensembles de processus de travail de croître ou de les maintenir stables en supprimant une ancienne page pour chaque nouvelle page ajoutée. Lorsque les octets disponibles sont peu nombreux, Virtual Memory Manager doit réduire les ensembles de processus de travail pour conserver le minimum requis.
Cette analyse vérifie si la mémoire totale disponible est faible : avertissement à 10 % disponible et Critique à 5 % disponible. Un avertissement est également alerté lorsqu’une tendance décroissante de 10 Mo par heure est détectée, indiquant une condition de mémoire potentielle à venir. Une mémoire physique insuffisante peut entraîner des retards accrus du processeur et du système en mode privilégié.
Références
Analyse de la détection des fuites de mémoire
Cette analyse détermine si l’un des processus consomme une grande quantité de mémoire du système et si le processus augmente dans la consommation de mémoire au fil du temps. Un processus qui consomme de grandes parties de mémoire est acceptable tant que le processus retourne la mémoire au système. Recherchez les tendances croissantes dans le graphique. Une tendance croissante sur une longue période peut indiquer une fuite de mémoire. Les octets privés correspondent à la taille actuelle, en octets, de la mémoire allouée par ce processus et qui ne peut pas être partagée avec d’autres processus. Cette analyse vérifie les tendances croissantes de 10 Mo par heure et de 5 Mo par heure. Utilisez cette analyse en corrélation avec l’analyse mémoire disponible.
En outre, gardez à l’esprit que les processus nouvellement démarrés apparaissent initialement comme une fuite de mémoire lorsqu’il s’agit simplement d’un comportement de démarrage normal. Une fuite de mémoire se produit lorsqu’un processus continue de consommer de la mémoire et ne libère pas de mémoire sur une longue période de temps.
Si vous soupçonnez une condition de fuite de mémoire, installez et utilisez l’outil Debug Diag. Pour plus d’informations sur l’outil Debug Diag, consultez la section références.
Informations de référence
Outil de diagnostic de débogage
Analyse des pages de mémoire/s
Cette analyse vérifie si la valeur « Pages/s » est élevée. S’il est élevé, le système manque probablement de mémoire en essayant de pager la mémoire sur le disque. « Pages/s » correspond à la vitesse à laquelle les pages sont lues ou écrites sur le disque pour résoudre les erreurs de page matérielle. Ce compteur indique principalement les types de défauts qui causent des délais au niveau du système. Il s’agit de la somme de « Memory\Pages Input/s » et de « Memory\Pages Output/s ». Il est compté en nombre de pages, de sorte qu’il peut être comparé à d’autres nombres de pages, tels que « Mémoire\Erreurs de page/s ».
Ce compteur doit toujours être inférieur à 1 000. Cette analyse vérifie les valeurs supérieures à 1 000. Utilisez cette analyse en corrélation avec l’analyse de la mémoire disponible et l’analyse de détection des fuites de mémoire. Si toutes les analyses lèvent des alertes en même temps, cela peut indiquer que le système manque de mémoire. Suivez les étapes d’analyse mentionnées dans Informations supplémentaires concernant l’analyse de la détection des fuites de mémoire dans cette rubrique.
Informations de référence
Exclure les problèmes de Memory-Bound
Analyse des octets résidents du cache du système de mémoire
« Octets résidents du cache système » correspond à la taille, en octets, du code du système d’exploitation paginable dans le cache du système de fichiers. Cette valeur inclut uniquement les pages physiques actuelles et n'inclut pas les pages de mémoire virtuelle qui ne sont pas actuellement résidantes. Elle est égale à la valeur cache système indiquée dans le Gestionnaire des tâches. Par conséquent, cette valeur peut être inférieure à la quantité réelle de mémoire virtuelle utilisée par le cache du système de fichiers. Cette valeur est un composant de « Mémoire\\Octets résidents du code système », qui représente tout le code du système d’exploitation paginable actuellement en mémoire physique. Ce compteur correspond à la dernière valeur observée seulement et non à une moyenne sur un intervalle de temps.
Cette analyse vérifie une tendance croissante de 10 Mo par heure. En cours de chargement, un serveur peut utiliser le cache système pour mettre en cache l’activité d’E/S telle que le disque. Utilisez en corrélation avec les analyses Des opérations de données d’E/S de processus/s et d’autres opérations/s d’E/S de traitement.
Analyse de l’utilisation du processeur et utilisation excessive du processeur par les processus
« % de temps processeur » correspond au pourcentage de temps écoulé que le processeur consacre à l’exécution d’un thread non inactif. Il est calculé en mesurant la durée d’activité du thread inactif dans l’intervalle de l’exemple, puis en soustrayant cette heure de la durée de l’intervalle. (Chaque processeur a un thread inactif qui consomme des cycles lorsqu’aucun autre thread n’est prêt à s’exécuter.) Ce compteur est le principal indicateur de l’activité du processeur et affiche le pourcentage moyen de temps d’occupation observé pendant l’intervalle d’échantillonnage. Il est calculé en surveillant la durée d’inactivité du service et en soustrayant cette valeur de 100 %.
Cette analyse vérifie l’utilisation supérieure à 60 % sur chaque processeur individuel. Si c’est le cas, déterminez s’il s’agit d’un processeur en mode utilisateur élevé ou d’un mode à privilèges élevés. Si l’UC en mode à privilèges élevés est suspectée, consultez « Analyse du processeur en mode privilégié ». Si un goulot d’étranglement du processeur en mode utilisateur est suspecté, envisagez d’utiliser un profileur de processus pour analyser les fonctions à l’origine de la consommation élevée du processeur. Pour plus d’informations, consultez l’article « Guide pratique pour identifier les fonctions à l’origine d’un goulot d’étranglement élevé du processeur en mode utilisateur pour les applications serveur dans un environnement de production » dans la section références.
Analyse de la longueur de file d’attente du processeur
« Longueur de file d’attente du processeur » correspond au nombre de threads dans la file d’attente du processeur. À la différence des compteurs disque, ce compteur n'affiche que les threads prêts et non les threads en cours d'exécution. Il n'y a qu'une seule file pour le temps processeur, même sur les ordinateurs avec plusieurs processeurs. Par conséquent, si un compteur possède plusieurs processeurs, vous devez diviser cette valeur par le nombre de processeurs desservant la charge de travail. Une file d'attente de processeur maintenue à moins de 10 threads par processeur est normalement acceptable, en fonction de la charge de travail.
Cette analyse détermine si la longueur moyenne de la file d’attente du processeur dépasse le nombre de processeurs. Si c’est le cas, cela peut indiquer un goulot d’étranglement du processeur. Utilisez cette analyse en corrélation avec l’analyse du processeur en mode privilégié et l’utilisation excessive du processeur par processus. La file d’attente du processeur est la collection de threads qui sont prêts, mais qui ne peuvent pas être exécutés par le processeur, car un autre thread actif est en cours d’exécution. Une file d’attente soutenue ou périodique de plus de threads que de processeurs est une bonne indication d’un goulot d’étranglement du processeur.
Vous pouvez utiliser ce compteur conjointement avec le compteur « Processeur\% Temps processeur » pour déterminer si votre application peut tirer parti d’autres processeurs. Il existe une file d’attente unique pour le temps processeur, même sur les ordinateurs multiprocesseurs. Par conséquent, dans un ordinateur multiprocesseur, divisez la valeur « Longueur de file d’attente du processeur » (PQL) par le nombre de processeurs qui effectuent la maintenance de la charge de travail
Si le processeur est très occupé (90 % et une utilisation supérieure) et que la moyenne PQL est constamment supérieure au nombre de processeurs, il se peut que vous ayez un goulot d’étranglement du processeur qui pourrait tirer parti de processeurs supplémentaires. Vous pouvez également réduire le nombre de threads et de files d’attente au niveau de l’application. Cela entraîne moins de basculement de contexte, ce qui est bon pour réduire la charge du processeur. La raison courante d’un PQL élevé avec une faible utilisation du processeur est que les demandes de temps processeur arrivent de manière aléatoire et que les threads exigent des quantités de temps irrégulières du processeur. Cela signifie que le processeur n’est pas un goulot d’étranglement. Au lieu de cela, votre logique de threading doit être améliorée.
Si un goulot d’étranglement du processeur en mode utilisateur est suspecté, envisagez d’utiliser un profileur de processus pour analyser les fonctions à l’origine de la consommation élevée du processeur. Pour plus d’informations, consultez l’article « Guide pratique pour identifier les fonctions à l’origine d’un goulot d’étranglement élevé du processeur en mode utilisateur pour les applications serveur dans un environnement de production » dans la section Références.
Analyse du processeur en mode privilégié
Ce compteur indique le pourcentage de temps d’exécution d’un thread en mode privilégié. Lorsque votre application appelle des fonctions de système d’exploitation (par exemple pour effectuer des E/S de fichiers ou réseau ou pour allouer de la mémoire), ces fonctions de système d’exploitation sont exécutées en mode privilégié.
Le mode processeur à privilèges élevés indique que l’ordinateur passe trop de temps dans les E/S système par rapport au travail réel (mode utilisateur). « % de temps privilégié » est le pourcentage de temps écoulé que les threads de processus ont passé à exécuter du code en mode privilégié. Lorsqu’un service système Windows est appelé, le service s’exécute souvent en mode privilégié pour accéder aux données privées du système. Ces données sont protégées contre l’accès par des threads s’exécutant en mode utilisateur. Les appels système peuvent être explicites ou implicites tels que les défauts de page et les interruptions. Contrairement à certains premiers systèmes d’exploitation, Windows utilise des limites de processus pour la protection des sous-systèmes en plus de la protection traditionnelle des modes utilisateur et privilégiés. Certains travaux effectués par Windows pour le compte de l’application peuvent apparaître dans d’autres processus de sous-système en plus du temps privilégié dans le processus.
Cette analyse vérifie si le processeur en mode privilégié consomme plus de 30 % du processeur total. Si c’est le cas, la consommation du processeur est probablement due à un autre goulot d’étranglement que le processeur, comme le réseau, la mémoire ou les E/S de disque. Utilisez en corrélation avec les analyses % interruption et basculement de contexte élevé.
Analyse de basculement de contexte élevé
Un changement de contexte se produit lorsqu’un thread de priorité supérieure préempte un thread de priorité inférieure en cours d’exécution ou lorsqu’un thread de priorité élevée est bloqué. Des niveaux élevés de basculement de contexte peuvent se produire lorsque de nombreux threads partagent le même niveau de priorité. Cela indique souvent que trop de threads sont en concurrence pour les processeurs sur le système. Si vous ne voyez pas beaucoup d’utilisation du processeur et que vous voyez des niveaux très faibles de basculement de contexte, cela peut indiquer que les threads sont bloqués.
Le basculement de contexte élevé ne doit être examiné que lorsque le processeur en mode privilégié et le processeur global sont élevés. En règle générale, les taux de basculement de contexte inférieurs à 5 000 par seconde par processeur ne sont pas la peine de s’inquiéter. Si les taux de basculement de contexte dépassent 15 000 par seconde par processeur, il existe une contrainte.
Cette analyse vérifie les commutateurs de contexte système à processeur élevé, en mode à privilèges élevés et élevés (supérieurs à 5 000 par processeur) par seconde qui se produisent tous en même temps. En cas de basculement de contexte élevé, réduisez le nombre de threads et de processus en cours d’exécution sur le système.
Analyse des sessions de base de données élevée BizTalk
Ce compteur a deux valeurs possibles : normale (0) ou dépassée (1). Cette analyse vérifie la valeur 1. Dans ce cas, BizTalk a dépassé le seuil du nombre de sessions de base de données autorisées. Cette valeur est contrôlée par la valeur « Connexion de base de données par processeur » dans les paramètres de limitation de l’hôte BizTalk.
« Connexion de base de données par processeur » est le nombre maximal de sessions de base de données simultanées (par PROCESSEUR) autorisées avant le début de la limitation. Les sessions de base de données inactives dans le pool de sessions par hôte commun ne sont pas incluses dans ce nombre et cette vérification est effectuée strictement sur le nombre de sessions réellement utilisées par l'instance de l'hôte. Cette option est désactivée par défaut ; En règle générale, ce paramètre ne doit être activé que si le serveur de base de données est un goulot d’étranglement ou pour les serveurs de base de données bas de terminaison dans le système BizTalk Server. Vous pouvez surveiller le nombre de connexions aux bases de données actifs à l’aide du compteur de performances de session de base de données sous la catégorie d’objet de performance Agent BizTalk:Message. Ce paramètre a une incidence uniquement sur la limitation basée sur la fréquence des messages sortants. Entrez la valeur 0 pour désactiver la limitation basée sur le nombre de sessions de base de données. La valeur par défaut est 0.
Notes
La clé de Registre « MaxWorkerThreads » influence le nombre de threads disponibles pour BizTalk et peut être utile si la plupart des threads BizTalk sont occupés avec connexions aux bases de données.
Références
Paramètres de configuration qui affectent les performances des adaptateurs
Modification des paramètres de limitation par défaut de l'hôte
Analyse de la taille de base de données élevée BizTalk
Ce compteur fait référence au nombre de messages dans les files d’attente de base de données publiées par ce processus. Cette valeur est déterminée par le nombre d'éléments dans les tables de file d'attente pour tous les hôtes et le nombre d'éléments dans les tables du spouleur et de suivi. La file d’attente comprend la file d’attente de travail, la file d’attente d’état et la file d’attente suspendue. Si un processus publie vers plusieurs files d'attente, ce compteur représente la moyenne pondérée de toutes les files d'attente.
En cas de redémarrage de l'hôte, les statistiques stockées en mémoire sont perdues. Étant donné qu’une certaine surcharge est impliquée, BizTalk Server ne reprendront la collecte de statistiques que lorsqu’il y a au moins 100 publications, avec 5 % du total des publications dans le processus hôte redémarré.
Ce compteur est défini sur la valeur 1 si l’une des conditions répertoriées pour le nombre de messages dans le seuil de la base de données se produit. Ce seuil est documenté dans la rubrique Comment modifier les paramètres de limitation d’hôte par défaut référencés ci-dessous. Par défaut, le nombre de messages d’hôte dans le seuil de limitation de base de données est défini sur une valeur de 50 000, ce qui déclenche une condition de limitation dans les circonstances suivantes :
Le nombre total de messages publiés par l'instance de l'hôte dans les files d'attente de travail, de messages interrompus et d'état des hôtes d'abonnement est supérieur à 50 000.
Le nombre de messages de la table du spouleur ou de la table de suivi est supérieur à 500 000.
Étant donné que les messages suspendus sont inclus dans le nombre de messages dans le calcul de la base de données, une limitation de la publication des messages peut se produire même si le serveur BizTalk rencontre une charge faible ou inexistante.
Cette analyse vérifie la valeur 1. Si cela se produit, envisagez une ligne de conduite qui réduira le nombre de messages dans la base de données. Par exemple, vérifiez que les travaux bizTalk SQL Server s’exécutent sans erreur et utilisez le hub de groupe dans la console d’administration BizTalk pour déterminer si la génération de messages est due à un grand nombre de messages suspendus.
Références
Analyse du nombre de messages bizTalk high In-Process
Le paramètre « Messages in-process par processeur » dans les paramètres de limitation de l’hôte correspond au nombre maximal de messages remis au gestionnaire de points de terminaison (EPM) ou XLANG qui n’ont pas été traités. Ce nombre n’inclut pas les messages récupérés à partir de la base de données, mais en attente de remise dans la file d’attente en mémoire. Vous pouvez surveiller le nombre de messages in-process à l’aide du compteur de performances Nombre de messages in-process sous la catégorie d’objet de performance BizTalk:Message Agent. Ce paramètre fournit un conseil au mécanisme de limitation lors de la prise en compte des conditions de limitation. Le seuil réel fait l'objet d'un réglage automatique. Vous pouvez vérifier le seuil réel en surveillant le compteur de performances du nombre de messages in-process.
Ce paramètre peut être défini sur une valeur plus petite pour les scénarios de messages volumineux, où la taille moyenne des messages est élevée ou où le traitement des messages peut nécessiter un grand nombre de messages. Cela est évident si un scénario subit trop souvent une limitation basée sur la mémoire et si le seuil de mémoire est automatiquement ajusté à une valeur sensiblement faible. Un tel comportement indique que le transport sortant doit traiter moins de messages simultanément pour éviter l'utilisation excessive de la mémoire. De même, dans des scénarios dans lesquels l'adaptateur est plus efficace lorsque seulement quelques messages sont traités simultanément (par exemple, lors de la transmission à un serveur qui limite les connexions simultanées), ce paramètre peut avoir une valeur inférieure à celle par défaut.
Cette analyse vérifie le compteur Nombre élevé de messages In-Process pour déterminer si ce type de limitation se produit. Si c’est le cas, envisagez d’ajuster le paramètre « Messages in-process par processeur ». Ce paramètre a une incidence uniquement sur la limitation basée sur la fréquence des messages sortants. Entrez la valeur 0 dans le paramètre « Messages in-process par processeur » pour désactiver la limitation en fonction du nombre de messages in-process par processeur. La valeur par défaut du paramètre « Messages en cours de traitement par processeur » est 1 000. Notez que la modification de cette valeur peut également avoir un impact sur la faible latence des messages et/ou l’efficacité des ressources BizTalk.
Références
Analyse du taux de remise de messages élevé BizTalk
Pour les messages sortants (remis), BizTalk Server limite la remise des messages si le taux entrant de remise de messages pour l’hôte instance dépasse le taux de remise sortant de message * la valeur du facteur d’overdrive (pourcentage) de débit spécifié. Le paramètre facteur d’overdrive de débit (pourcentage) est configurable dans la boîte de dialogue Paramètres de limitation du traitement des messages. La limitation basée sur le débit pour les messages sortants s’effectue principalement en induisant un délai avant de supprimer les messages de la file d’attente en mémoire et de remettre les messages au gestionnaire de points de terminaison (EPM) ou au moteur d’orchestration pour traitement. Aucune autre action n’est effectuée pour accomplir la limitation basée sur le taux pour les messages sortants.
La limitation au niveau des sorties peut provoquer une retard de remise des messages et les messages peuvent s'accumuler dans la file d'attente en mémoire et engendrer le blocage des threads jusqu'à ce que la condition de limitation soit réduite. Lorsque les threads de dé-file d’attente sont bloqués, aucun message supplémentaire n’est extrait de MessageBox dans la file d’attente en mémoire pour la remise sortante.
Cette analyse recherche la valeur 1 dans le compteur Taux de remise de messages élevé. Des taux de remise de messages élevés peuvent être dus à une complexité de traitement élevée, à des adaptateurs sortants lents ou à une pénurie momentanée de ressources système.
Références
Implémentation de la limitation des hôtes par BizTalk Server
Modification des paramètres de limitation par défaut de l'hôte
Analyse de la mémoire de processus élevés BizTalk
Le paramètre de seuil de limitation de l’utilisation de la mémoire du processus BizTalk correspond au pourcentage de mémoire utilisée par rapport à la somme de la taille du jeu de travail et de la mémoire virtuelle totale disponible pour le processus si une valeur comprise entre 1 et 100 est entrée. Par défaut, le paramètre de limitation de l’utilisation de la mémoire du processus BizTalk est 25. Lorsqu' une valeur de pourcentage est spécifiée, le seuil de mémoire de processus est recalculé à intervalles réguliers. Si l’utilisateur spécifie une valeur de pourcentage, elle est calculée en fonction de la mémoire disponible à valider et de l’utilisation actuelle de la mémoire de processus.
Cette analyse vérifie la valeur 1 dans le compteur Mémoire de processus élevé. Si cela se produit, essayez de déterminer la cause de l’augmentation de la mémoire à l’aide de Debug Diag (consultez les références dans l’analyse de la détection des fuites de mémoire). Notez qu’il est normal que les processus consomment une grande partie de la mémoire au démarrage, ce qui peut apparaître initialement comme une fuite de mémoire, mais qu’une véritable fuite de mémoire se produit lorsqu’un processus ne parvient pas à libérer la mémoire dont il n’a plus besoin, réduisant ainsi la quantité de mémoire disponible au fil du temps. Consultez la référence « Capture d’un vidage de mémoire d’un processus qui fuit la mémoire » ci-dessous et/ou l’analyse « Détection des fuites de mémoire » dans PAL pour plus d’informations sur l’analyse générique des fuites de mémoire de processus dans BizTalk.
Une limitation élevée de la mémoire de processus peut se produire si le lot à publier a des besoins en mémoire élevés ou si trop de threads traitent des messages. Si le système semble trop limité, envisagez d’augmenter la valeur associée au seuil d’utilisation de la mémoire de processus pour l’hôte et vérifiez que l’instance hôte ne génère pas d’erreur « mémoire insuffisante ». Si une erreur « mémoire insuffisante » est générée en augmentant le seuil d’utilisation de la mémoire du processus, envisagez de réduire les valeurs de la taille de la file d’attente de messages interne et des messages in-process par seuils de processeur. Cette stratégie est particulièrement adaptée aux scénarios traitant de nombreux messages. En outre, cette valeur doit être définie sur une valeur faible pour les scénarios ayant des besoins de mémoire importants par message. La définition d’une valeur faible déclenchera la limitation précoce et empêchera une explosion de mémoire au sein du processus.
Si votre serveur BizTalk manque régulièrement de mémoire virtuelle, envisagez de BizTalk Server 64 bits. Chaque processus sur les serveurs 64 bits peut traiter jusqu’à 4 To de mémoire virtuelle par rapport aux 2 Go en 32 bits. En général, bizTalk 64 bits et SQL Server 64 bits sont fortement recommandés. Pour plus d’informations, consultez la référence « support BizTalk Server 64 bits ».
Références
Implémentation de la limitation des hôtes par BizTalk Server
Modification des paramètres de limitation par défaut de l'hôte
Capture de l'image mémoire d'un processus subissant des fuites de mémoire
Analyse de la mémoire haute système BizTalk
Le paramètre de seuil de limitation de l’utilisation de la mémoire physique BizTalk est le pourcentage de consommation de mémoire par rapport à la quantité totale de mémoire physique disponible si une valeur comprise entre 1 et 100 est entrée. Ce paramètre peut également correspondre à la quantité totale de mémoire physique disponible en mégaoctets si une valeur supérieure à 100 est entrée. Entrez la valeur 0 pour désactiver la limitation basée sur l'utilisation de la mémoire physique. La valeur par défaut est 0.
Cette analyse vérifie la valeur 1 dans le compteur mémoire système élevée. Étant donné que ceci mesure le volume total de mémoire système, une condition de limitation peut être déclenchée si des processus non BizTalk Server consomment un volume important de cette mémoire. Par conséquent, si cela se produit, la meilleure approche consiste à identifier les processus qui consomment le plus de mémoire physique et/ou à ajouter de la mémoire physique supplémentaire au serveur. Envisagez également de réduire la charge en réduisant la taille par défaut du pool de threads EPM et/ou la taille des lots d’adaptateurs. Pour plus d’informations, consultez Analyse de la détection des fuites de mémoire dans PAL.
Références
Modification des paramètres de limitation par défaut de l'hôte
Implémentation de la limitation des hôtes par BizTalk Server
Analyse du nombre élevé de threads BizTalk
« Threads par processeur » correspond au nombre total de threads dans le processus hôte, y compris les threads utilisés par les adaptateurs. Si ce seuil est dépassé, BizTalk Server tente de réduire la taille du pool de threads EPM et du pool de threads d’agent de messages. La limitation basée sur les threads doit être activée dans les scénarios dans lesquels des charges élevées peuvent conduire à la création d'un grand nombre de threads. Ce paramètre a une incidence sur la limitation au niveau des entrées et des sorties. La limitation basée sur les threads est désactivée par défaut.
Notes
La valeur spécifiée par l’utilisateur est utilisée comme guide, et l’hôte peut régler dynamiquement automatiquement cette valeur de seuil en fonction des modèles d’utilisation de la mémoire et des exigences de thread du processus.
Cette analyse vérifie la valeur 1 dans le compteur Nombre élevé de threads. Envisagez d'ajuster les différentes tailles de réserves de threads pour que le système ne puisse pas créer un grand nombre de threads. Cette analyse peut être corrélée avec les commutateurs de contexte par seconde pour déterminer si le système d’exploitation est saturé de threads trop nombreux, mais dans la plupart des cas, le nombre élevé de threads entraîne plus de conflits sur la base de données principale que sur le serveur BizTalk. Pour plus d’informations sur la modification des tailles du pool de threads, consultez Comment modifier les paramètres de limitation d’hôte par défaut dans les références.
Références
Implémentation de la limitation des hôtes par BizTalk Server
Modification des paramètres de limitation par défaut de l'hôte
Paramètres de configuration qui affectent les performances des adaptateurs
Threads, sessions de base de données et limitation
Analyse de la latence entrante BizTalk Latence en millisecondes à partir du moment où le moteur de messagerie reçoit un document de l’adaptateur jusqu’à sa publication dans la boîte de message. La réduction de la latence est importante pour certains utilisateurs de BizTalk. Par conséquent, il est important de suivre le temps passé par les documents dans l’adaptateur entrant.
Voici un graphique montrant comment la latence est mesurée.
| 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|
| L’adaptateur reçoit le message et l’envoie au moteur, travail effectué dans l’adaptateur avant que le message ne soit envoyé au moteur non capturé dans ces compteurs de perf | Le moteur reçoit le message de l’adaptateur, exécute le pipeline de réception, le mappage, l’évaluation de l’abonnement, le message persistant dans la base de données. | Le port d’orchestration ou de Solicit-Response s’exécute et génère un message de réponse. | Le message de réponse est mis en file d’attente dans le moteur de messagerie, exécutez le pipeline d’envoi, mapper. | Le moteur de messagerie fournit un message de réponse à l’adaptateur. | L’adaptateur informe que le message du moteur est terminé. |
| I | |||||
| RR | RR | RR | |||
| O | O | O | |||
| OA | OA |
I = Latence entrante
RR = Latence de la réponse aux demandes
O = Latence sortante
OA = Latence de l’adaptateur sortant
En supposant un environnement à faible latence, cette analyse vérifie si le document a passé plus de 5 secondes dans l’adaptateur entrant. Cela peut indiquer un retard de traitement dans le transport des messages via des adaptateurs entrants dans cette instance hôte. Si plusieurs cartes entrantes existent dans cette instance hôte, envisagez de les séparer en leurs propres hôtes pour déterminer quelle carte entrante a une latence élevée.
Références
Analyse de l’état de limitation de la remise de messages BizTalk
L’état de limitation de remise de messages BizTalk est l’un des principaux indicateurs de limitation. Il s’agit d’un indicateur indiquant si le système limite la remise des messages (affectant le traitement des messages XLANG et les transports sortants). La condition de limitation est indiquée par la valeur numérique du compteur. Voici une liste des valeurs et de leur signification respective :
| Condition de limitation | Description |
|---|---|
| 0 | Pas de limitation |
| 1 | Limitation due à des vitesses de remise de messages déséquilibrées (la vitesse en entrée est supérieure à la vitesse en sortie) |
| 3 | Limitation due à un nombre élevé de messages en cours de traitement |
| 4 | Limitation due à une surcharge de la mémoire de processus |
| 5 | Limitation due à une surcharge de la mémoire système |
| 9 | Limitation due à un nombre élevé de threads |
| 10 | Limitation due à un remplacement d'utilisateur pour la remise de messages |
Cette analyse vérifie chacune de ces valeurs et a une alerte spécifique pour chacune d’elles.
Références
Analyse des échecs de connexion de base de données MessageBox BizTalk
Ce compteur de performances correspond au nombre de tentatives d’connexions aux bases de données qui ont échoué depuis que l’hôte instance démarré. Si le service SQL Server qui héberge les bases de données BizTalk devient indisponible pour une raison quelconque, le cluster de base de données transfère les ressources de l’ordinateur actif vers l’ordinateur passif. Lors de ce processus de basculement, les instances du service BizTalk Server rencontrent des problèmes de connexion aux bases de données et relancent automatiquement ces connexions. L'ordinateur contenant la base de données indemne (ordinateur jusqu'alors passif) commence à traiter les connexions de la base de données après avoir pris en charge les ressources durant le basculement.
Les erreurs DBNetLib (bibliothèque réseau de base de données) se produisent lorsque le runtime BizTalk Server ne peut pas communiquer avec les bases de données MessageBox ou de gestion. Dans ce cas, le runtime BizTalk Server instance qui intercepte l’exception s’arrête, puis effectue un cycle toutes les minutes pour case activée pour voir si la base de données est disponible. Pour plus d’informations sur cette rubrique, consultez la section Références.
Lorsqu'un client établit une connexion de socket TCP/IP à un serveur, il se connecte généralement à un port spécifique sur le serveur et demande que le serveur lui réponde via un port éphémère (de courte durée), TCP ou UDP. Sur Windows Server 2003 et Windows XP, la plage par défaut de ports éphémères utilisés par les applications clientes est comprise entre 1025 et 5 000. Dans certaines conditions, il est possible que les ports disponibles dans la plage par défaut soient épuisés. Pour plus d’informations sur cette rubrique, consultez la section Références.
Cette analyse vérifie toute occurrence d’échecs de connexion de base de données. Les échecs de connexion à la base de données sont critiques, car BizTalk ne peut pas fonctionner sans la base de données. Si la cause de l’échec de connexion de base de données est inconnue, examinez les références répertoriées ci-dessous et/ou contactez Support Microsoft pour déterminer la nature de l’échec de connectivité.
Références
Analyse de l’état de limitation de publication de messagerie BizTalk
L’état de limitation de publication de messages BizTalk est l’un des principaux indicateurs de limitation. Il s’agit d’un indicateur indiquant si le système limite la publication des messages (ce qui affecte le traitement des messages XLANG et les transports entrants). La condition de limitation est indiquée par la valeur numérique du compteur. Voici une liste des valeurs et de leur signification respective :
| Condition de limitation | Description |
|---|---|
| 0 | Pas de limitation |
| 2 | Limitation due à des vitesses de publication de messages déséquilibrées (la vitesse en entrée est supérieure à la vitesse en sortie) |
| 4 | Limitation due à une surcharge de la mémoire de processus |
| 5 | Limitation due à une surcharge de la mémoire système |
| 6 | Limitation due à la croissance de la base de données |
| 8 | Limitation due à un nombre élevé de sessions |
| 9 | Limitation due à un nombre élevé de threads |
| 11 | Limitation due à un remplacement d'utilisateur pour la publication de messages |
Cette analyse vérifie chacune de ces valeurs et a une alerte spécifique pour chacune d’elles.
Références
Orchestrations BizTalk résident en mémoire
Nombre d'instances d'orchestration actuellement hébergées par l'instance de l'hôte. Bien que les pics ou les rafales d’orchestrations résidant dans la mémoire puissent être considérés comme normaux, une tendance croissante pourrait indiquer une « accumulation » d’orchestrations dans la mémoire. Une tendance croissante au fil du temps peut se produire lorsque BizTalk ne parvient pas à déshydrater les messages/instances d’orchestration. Essayez de mettre en corrélation ce compteur avec « XLANG/s Orchestrations(?) \Orchestrations déshydratables » où le point d’interrogation (?) est le même compteur instance que ce compteur.
Si un nombre élevé d’orchestrations résident dans la mémoire et si un faible nombre d’orchestrations sont déshydratables, vos orchestrations sont probablement inactives dans la mémoire et peuvent entraîner une condition de fuite de mémoire. Utilisez cette analyse en corrélation avec « \XLANG/s Orchestrations(*)\Orchestrations inactives » le cas échéant. Une tendance croissante dans les orchestrations inactives BizTalk est un meilleur indicateur des fuites de mémoire en raison de l’incapacité à déshydrater les instances d’orchestration.
Cette analyse vérifie une tendance croissante des orchestrations résidant dans la mémoire et si plus de 50 % des orchestrations résidant dans la mémoire ne sont pas déshydratables.
Références
Analyse des octets privés BizTalk
Il s’agit des mégaoctets de mémoire privée allouée pour l’hôte instance et comparable au compteur de performances « \Process(*)\Private Bytes ». Les octets privés sont la taille actuelle, en octets, de la mémoire allouée par un processus et qui ne peut pas être partagée avec d’autres processus. Cette analyse détermine si l’une des instances de l’hôte consomme une grande taille de la mémoire du système et si la instance hôte augmente au fil du temps. Un hôte instance consommant de grandes parties de mémoire est correct tant qu’il retourne la mémoire au système. Recherchez les tendances croissantes dans le graphique. Une tendance croissante sur une longue période peut indiquer une fuite de mémoire.
Cette analyse vérifie une tendance à l’augmentation de 10 Mo par heure. Utilisez cette analyse en corrélation avec l’analyse mémoire disponible et l’analyse des fuites de mémoire. En outre, gardez à l’esprit que les instances d’hôte nouvellement démarrées apparaissent initialement comme une fuite de mémoire lorsqu’il s’agit simplement d’un comportement de démarrage normal. Une fuite de mémoire se produit lorsqu’un processus continue de consommer de la mémoire et de ne pas libérer de mémoire sur une longue période de temps. Si vous soupçonnez une condition de fuite de mémoire, lisez l’article « Croissance de la mémoire dans BizTalk Messaging » référencé ci-dessous. Sinon, installez et utilisez l’outil Debug Diag. Pour plus d’informations sur l’outil Debug Diag, consultez la section références.
Références
Analyse des octets virtuels BizTalk
Il s’agit des mégaoctets réservés à la mémoire virtuelle pour le instance hôte. Cette analyse détermine si l’une des instances hôtes consomme une grande quantité de mémoire du système et si la consommation de mémoire de l’hôte instance augmente au fil du temps. Un hôte instance consommer de grandes portions de mémoire est parfait tant qu’il retourne la mémoire au système. Recherchez les tendances croissantes dans le graphique. Une tendance croissante sur une longue période peut indiquer une fuite de mémoire.
Cette analyse vérifie une tendance à l’augmentation de 10 Mo par heure en octets virtuels. Utilisez cette analyse en corrélation avec l’analyse mémoire disponible et l’analyse des fuites de mémoire. En outre, gardez à l’esprit que les instances d’hôte nouvellement démarrées apparaissent initialement comme une fuite de mémoire lorsqu’il s’agit simplement d’un comportement de démarrage normal. Une fuite de mémoire se produit lorsqu’un processus continue de consommer de la mémoire et de ne pas libérer de mémoire sur une longue période de temps. Si vous soupçonnez une condition de fuite de mémoire, lisez l’article « Croissance de la mémoire dans BizTalk Messaging » ci-dessous. Sinon, installez et utilisez l’outil Debug Diag. Pour plus d’informations sur l’outil Debug Diag, consultez la section références.
Références
Analyse de limitation de session de l’agent de message BizTalk
Il s’agit du nombre de connexions aux bases de données ouverts à MessageBox par rapport à son paramètre de limitation BizTalk respectif. « Connexion de base de données par processeur » correspond au nombre maximal de sessions de base de données simultanées (par processeur) autorisées avant le début de la limitation. Les sessions de base de données inactives dans le pool de sessions par hôte commun ne sont pas incluses dans ce nombre et cette vérification est effectuée strictement sur le nombre de sessions réellement utilisées par l'instance de l'hôte. Cette option est désactivée par défaut ; ce paramètre ne doit, en principe, être activé que si le serveur de base de données constitue un goulot d'étranglement dans le système BizTalk Server. Vous pouvez surveiller le nombre de connexions aux bases de données actifs à l’aide du compteur de performances de session de base de données sous la catégorie d’objets de performances BizTalk:Message Agent. Ce paramètre a une incidence uniquement sur la limitation basée sur la fréquence des messages sortants. Entrez la valeur 0 pour désactiver la limitation basée sur le nombre de sessions de base de données. La valeur par défaut est 0.
La clé de Registre MaxWorkerThreads a une influence sur le nombre de threads disponibles pour BizTalk et peut vous aider dans le cas où la plupart des threads de BizTalk sont occupés avec connexions aux bases de données. Cette analyse vérifie si le nombre d’connexions aux bases de données ouverts dans MessageBox est supérieur à 80 % du paramètre De limitation de session de base de données, ce qui indique qu’une condition de limitation est probable.
Références
Analyse du seuil de limitation de session de l’agent de message BizTalk
Il s’agit du seuil actuel pour le nombre de connexions aux bases de données ouverts dans MessageBox. « Connexion de base de données par processeur » correspond au nombre maximal de sessions de base de données simultanées (par processeur) autorisées avant le début de la limitation. Les sessions de base de données inactives dans le pool de sessions par hôte commun ne sont pas incluses dans ce nombre et cette vérification est effectuée strictement sur le nombre de sessions réellement utilisées par l'instance de l'hôte. Cette option est désactivée par défaut ; ce paramètre ne doit, en principe, être activé que si le serveur de base de données constitue un goulot d'étranglement dans le système BizTalk Server. Vous pouvez surveiller le nombre de connexions aux bases de données actifs à l’aide du compteur de performances de session de base de données sous la catégorie d’objets de performances BizTalk:Message Agent. Ce paramètre a une incidence uniquement sur la limitation basée sur la fréquence des messages sortants. Entrez la valeur 0 pour désactiver la limitation basée sur le nombre de sessions de base de données. La valeur par défaut est 0.
La clé de Registre MaxWorkerThreads a une influence sur le nombre de threads disponibles pour BizTalk et peut vous aider dans le cas où la plupart des threads de BizTalk sont occupés avec connexions aux bases de données. Cette analyse vérifie cette valeur pour voir si elle a été modifiée à partir de son paramètre par défaut. Par défaut, ce paramètre est 0, ce qui signifie que la limitation sur les sessions de base de données est désactivée.
Références
Analyse de la limitation du nombre de messages in-process de l’agent de message BizTalk
Il s’agit du nombre de messages simultanés que la classe de service traite. Le paramètre « Messages en cours de traitement par processeur » dans les paramètres de limitation de l’hôte correspond au nombre maximal de messages remis au gestionnaire de points de terminaison (EPM) ou XLANG qui n’ont pas été traités. Cela n’inclut pas les messages récupérés à partir de la base de données, mais en attente de remise dans la file d’attente en mémoire. Vous pouvez surveiller le nombre de messages in-process à l’aide du compteur de performances In-process message count sous la catégorie d’objet performance BizTalk:Message Agent. Ce paramètre fournit une indication au mécanisme de limitation pour le traitement des conditions de limitation. Le seuil réel fait l'objet d'un réglage automatique. Vous pouvez vérifier le seuil réel en analysant le compteur de performances Nombre de messages en cours de traitement.
Pour les scénarios de messages volumineux (où la taille moyenne des messages est élevée ou où le traitement des messages peut nécessiter une grande quantité de messages), ce paramètre peut être défini sur une valeur plus petite. Un scénario de message volumineux est indiqué si la limitation basée sur la mémoire se produit trop souvent et si le seuil de mémoire est automatiquement ajusté à une valeur sensiblement faible. Un tel comportement indique que le transport sortant doit traiter moins de messages simultanément pour éviter l'utilisation excessive de la mémoire. De même, dans des scénarios dans lesquels l'adaptateur est plus efficace lorsque seulement quelques messages sont traités simultanément (par exemple, lors de la transmission à un serveur qui limite les connexions simultanées), ce paramètre peut avoir une valeur inférieure à celle par défaut. Cette analyse vérifie le compteur Nombre de messages In-Process élevé pour déterminer s’il est supérieur à 80 % de son paramètre de limitation sous le même nom, ce qui indique qu’une condition de limitation est probable.
Références
BizTalk :Analyse du seuil de limitation du nombre de messages in-process de l’agent de message
Il s’agit du seuil actuel pour le nombre de messages simultanés que la classe de service traite. Le paramètre « Messages en cours de traitement par processeur » dans les paramètres de limitation de l’hôte correspond au nombre maximal de messages remis au gestionnaire de points de terminaison (EPM) ou XLANG qui n’ont pas été traités. Cela n’inclut pas les messages récupérés à partir de la base de données, mais en attente de remise dans la file d’attente en mémoire. Vous pouvez surveiller le nombre de messages in-process à l’aide du compteur de performances In-process message count sous la catégorie d’objet performance BizTalk:Message Agent. Ce paramètre fournit une indication au mécanisme de limitation pour le traitement des conditions de limitation. Le seuil réel fait l'objet d'un réglage automatique. Vous pouvez vérifier le seuil réel en analysant le compteur de performances Nombre de messages en cours de traitement.
Pour les scénarios de messages volumineux (où la taille moyenne des messages est élevée ou où le traitement des messages peut nécessiter une grande quantité de messages), ce paramètre peut être défini sur une valeur plus petite. Un scénario de message volumineux est indiqué si la limitation basée sur la mémoire se produit trop souvent et si le seuil de mémoire est automatiquement ajusté à une valeur sensiblement faible. Un tel comportement indique que le transport sortant doit traiter moins de messages simultanément pour éviter l'utilisation excessive de la mémoire. De même, dans des scénarios dans lesquels l'adaptateur est plus efficace lorsque seulement quelques messages sont traités simultanément (par exemple, lors de la transmission à un serveur qui limite les connexions simultanées), ce paramètre peut avoir une valeur inférieure à celle par défaut. Cette analyse vérifie le seuil de limitation du nombre de messages In-Process élevé pour une valeur autre que celle par défaut.
Références
Analyse de limitation de l’utilisation de la mémoire de l’agent de message BizTalk
Il s’agit de l’utilisation de la mémoire du processus actuel (Mo). La limitation de la mémoire du processus BizTalk peut se produire si le lot à publier a des besoins en mémoire élevés ou si trop de threads traitent des messages. Si le système semble trop limité, envisagez d’augmenter la valeur associée au seuil d’utilisation de la mémoire du processus pour l’hôte et vérifiez que le instance hôte ne génère pas d’erreur « mémoire insuffisante ». Si une erreur « mémoire insuffisante » est générée en augmentant le seuil d’utilisation de la mémoire du processus, envisagez de réduire les valeurs de la taille de la file d’attente de messages internes et des messages in-process par seuils d’uc. Cette stratégie est particulièrement adaptée aux scénarios traitant de nombreux messages.
Si votre serveur BizTalk manque régulièrement de mémoire virtuelle, envisagez BizTalk Server 64 bits. Chaque processus sur les serveurs 64 bits peut traiter jusqu’à 4 To de mémoire virtuelle, contre 2 Go en 32 bits. En général, bizTalk 64 bits et SQL Server 64 bits sont fortement recommandés. Pour plus d’informations, consultez la référence « Support BizTalk Server 64 bits ». Cette analyse vérifie si l’utilisation de la mémoire du processus est supérieure à 80 % de son seuil de limitation respectif du même nom. Par défaut, le paramètre de limitation de l’utilisation de la mémoire du processus BizTalk correspond à 25 % de la mémoire virtuelle disponible pour le processus. Le commutateur /3GB n’a aucun effet sur ce paramètre.
Références
Implémentation de la limitation des hôtes par BizTalk Server
Modification des paramètres de limitation par défaut de l'hôte
Capture de l'image mémoire d'un processus subissant des fuites de mémoire
BizTalk:Analyse du seuil de limitation de l’utilisation de la mémoire de l’agent de message (Mo)
Il s’agit du seuil actuel pour l’utilisation de la mémoire du processus actuel (Mo). Le seuil peut être ajusté dynamiquement en fonction de la quantité réelle de mémoire disponible pour ce processus et de son modèle de consommation de mémoire. La limitation de la mémoire du processus BizTalk peut se produire si le lot à publier a des besoins en mémoire élevés ou si trop de threads traitent des messages. Si le système semble trop limité, envisagez d’augmenter la valeur associée au seuil d’utilisation de la mémoire du processus pour l’hôte et vérifiez que le instance hôte ne génère pas d’erreur « mémoire insuffisante ». Si une erreur « mémoire insuffisante » est générée en augmentant le seuil d’utilisation de la mémoire du processus, envisagez de réduire les valeurs de la taille de la file d’attente de messages internes et des messages in-process par seuils d’uc. Cette stratégie est particulièrement adaptée aux scénarios traitant de nombreux messages.
Si votre serveur BizTalk manque régulièrement de mémoire virtuelle, envisagez BizTalk Server 64 bits. Chaque processus sur les serveurs 64 bits peut traiter jusqu’à 4 To de mémoire virtuelle, contre 2 Go en 32 bits. En général, bizTalk 64 bits et SQL Server 64 bits sont fortement recommandés. Pour plus d’informations, consultez la référence « Support BizTalk Server 64 bits ». Cette analyse vérifie si la limitation de la mémoire du processus est définie sur une valeur autre que celle par défaut.