Comment dépanner une fuite de mémoire ou une exception hors mémoire dans le processus BizTalk Server

2020-03-16

Cet article explique comment dépanner une fuite de mémoire ou une exception hors mémoire dans le processus BizTalk Server de Microsoft BizTalk Server.

Version du produit d’origine : BizTalk Server 2010, 2009
Numéro de la base de connaissances d’origine : 918643

Résumé

Les fuites de mémoire sont un problème courant. Vous devrez peut-être essayer plusieurs étapes pour rechercher la cause spécifique d’une fuite de mémoire ou d’une exception de mémoire insuffisante (OOM) dans Microsoft BizTalk Server. Cet article traite des éléments importants à prendre en compte lorsque vous évaluez l’utilisation de la mémoire et les problèmes de mémoire possibles. Ces considérations incluent les éléments suivants :

RAM physique
Traitement de messages volumineux
Utilisation de l'option /3GB
Utilisation de composants personnalisés
Quelle version de Microsoft .NET Framework le système exécute
Nombre de processeurs

Le processus BizTalk Server peut rencontrer une fuite de mémoire lorsque l’utilisation de la mémoire dans Microsoft Windows Task Manager consomme plus de 50 % de la RAM physique. Une fuite de mémoire peut entraîner une exception de mémoire insuffisante lorsque l’utilisation de la mémoire augmente jusqu’à ce que la mémoire système soit épuisée ou jusqu’à ce que le processus cesse de fonctionner. Pour ce problème, tenez compte des éléments suivants :

Utilisation de la mémoire et de la ram physique

Étant donné qu’il peut être prévu qu’un processus utilise environ la moitié de la RAM physique, utilisez l’utilisation de la mémoire comme recommandations. Par exemple, si BizTalk Server a 4 gigaoctets (Go) de RAM et que le processus BizTalk Server utilise environ 500 mégaoctets (Mo) de RAM, il se peut qu’il n’y ait pas de fuite. Si le processus BizTalk Server utilise environ 1 Go de RAM, il peut y avoir une fuite de mémoire ou une situation de mémoire élevée. La consommation de mémoire peut être due à une procédure stockée exécutée sur une longue durée ou à une orchestration. Assurez-vous que vous savez combien de mémoire l’hôte BizTalk utilise généralement pour déterminer si une fuite de mémoire ou une condition de mémoire élevée se produit.

Messages volumineux

Lorsque BizTalk Server traite des messages volumineux, le système semble avoir une fuite de mémoire. Toutefois, les messages peuvent utiliser une grande quantité de mémoire.

Considérez également que l’utilisation élevée de la mémoire peut être attendue si BizTalk Server traite les messages volumineux. Vous pouvez mettre à niveau votre matériel pour répondre aux exigences de performances de BizTalk Server dans votre environnement.

Combien de temps faut-il pour reproduire la fuite de mémoire ?

Les fuites de mémoire peuvent se produire immédiatement ou elles peuvent s’accumuler au fil du temps. Les deux scénarios sont courants.

Utilisation du commutateur /3GB sur les ordinateurs 32 bits

En règle générale, un processus peut accéder à 2 Go d’espace d’adressage virtuel. Le commutateur /3 Go est une option pour les systèmes qui nécessitent plus de mémoire adressable. Cette option peut améliorer l’utilisation de la mémoire pour le traitement des messages. Toutefois, le commutateur /3 Go autorise uniquement 1 Go de mémoire adressable pour les opérations en mode noyau. En outre, ce commutateur peut augmenter le risque d’épuisement de la mémoire du pool.

Lorsque le commutateur /3 Go est activé sur une version 32 bits de Windows, le processus peut accéder à 3 Go d’espace d’adressage virtuel si le processus est conscient de l'espace d'adressage étendu. Un processus prend en compte les grandes adresses lorsque l’exécutable a l’indicateur de IMAGE_FILE_LARGE_ADDRESS_AWARE défini dans l’en-tête d’image. Étant donné que le processus BizTalk est capable d'adressage étendu, BizTalk bénéficiera de l'option /3 Go.

Si une instance hôte BizTalk 32 bits s’exécute sur une version 64 bits de Windows (AMD64), le processus BizTalk tire parti de l’espace d’adressage de mémoire de 4 Go, car BizTalk prend en charge les adresses volumineuses. Par conséquent, le déplacement de vos applications à mémoire élevée vers un serveur 64 bits peut être la meilleure solution.

Un processus BizTalk 64 bits sur une version 64 bits de Windows (AMD64) a 8 To de mémoire adressable.

Vous devez également prendre en compte les octets virtuels et les octets privés utilisés par le processus. Une instance d'hôte BizTalk (qui est une application .NET Framework) peut recevoir une erreur de mémoire insuffisante avant que la valeur "Octets virtuels" atteigne 2 Go. Cette situation peut se produire même si la mémoire maximale adressable par un processus sur une version 32 bits de Windows (sans le commutateur /3 Go) est de 2 Go. Pour obtenir une explication de la raison pour laquelle cette situation peut se produire, visitez le site web Microsoft Developer Network (MSDN) suivant :
ASP.NET analyse des performances et quand alerter les administrateurs

Le commutateur /3 Go augmente également la mémoire privée maximale du processus BizTalk de 800 Mo à 1800 Mo. Pour plus d’informations sur les performances des applications .NET Framework avec le commutateur /3 Go activé, consultez le chapitre 17 : Réglage des performances des applications .NET.

Le tableau suivant récapitule ces informations et inclut les limites pratiques pour les octets virtuels et les octets privés.

Processus	Fenêtres	Mémoire adressable (avec un processus à grande échelle sensible aux adresses)	Limite pratique pour les octets virtuels	Limite pratique pour les octets privés
32 bits	32 bits	2 Go	1400 MO	800 Mo
32 bits	32 bits avec /3 Go	3 Go	2400 MO	1800 Mo
32 bits	64 bits	4 Go	3400 Mo	2800 Mo
64 bits	64 bits	8 To	Non applicable	Non applicable

Pour plus d’informations sur la mémoire adressable pour les versions 32 bits et 64 bits de Windows, visitez Les Limites de Mémoire pour les Versions Windows et Windows Server.

Le tableau suivant répertorie la prise en charge de PAE et de 3 Go pour différentes versions de BizTalk Server.

Produit	PAE	3 Go
BizTalk Server 2004	Oui	Non
BizTalk Server 2006	Oui	Oui
BizTalk Server 2006 R2	Oui	Oui
BizTalk Server 2009	Oui	Oui

Si vous devez activer le commutateur /3GB pour répondre aux exigences de performances d’un ordinateur fonctionnant sous BizTalk Server, vous pouvez envisager d’ajouter des serveurs au groupe BizTalk. Cela vous permet d’effectuer un scale-out des instances d’hôte nécessitant beaucoup de mémoire.

Les composants BizTalk qui s’exécutent à l’intérieur d’un processus IIS (Internet Information Services) peuvent également bénéficier de l'activation de l'option /3GB.

Le commutateur /3 Go n’est pas pris en charge sur les ordinateurs exécutant Windows SharePoint Services 2.0 ou versions ultérieures ou SharePoint Portal Server 2003 SP2 ou versions ultérieures. Le commutateur Windows Server 2003 /3GB n’est pas pris en charge dans Windows SharePoint Services 2.0 ou versions ultérieures ou dans SharePoint Portal Server 2003 Service Pack 2 ou versions ultérieures.

Utilisation de composants personnalisés

Si vous utilisez des composants personnalisés, tels que des pipelines ou des composants de service, vous devez savoir ce que ces composants font. Vous devez également connaître l’effet potentiel de ces composants sur l’utilisation de la mémoire. Un problème de mémoire courant se produit lorsqu’un composant transforme un document. L’opération de transformation est une opération gourmande en mémoire. Lorsqu’un document est transformé, BizTalk Server transmet le flux de messages à la classe Microsoft .NET Framework XslTransform au sein du processus BizTalk.

Un autre problème courant se produit lorsqu’il existe une manipulation intensive de chaînes. Une manipulation intensive de chaînes peut consommer beaucoup de mémoire. Pour plus d’informations sur les façons d’améliorer les performances, consultez Amélioration des performances du code managé.

Version du .NET Framework

Microsoft .NET Framework 2.0 et .NET Framework 1.1 ont un comportement de mémoire différent. Vous pouvez donc voir des résultats différents entre eux. Si vous utilisez .NET Framework, vérifiez que la dernière version de .NET Framework Service Pack 1 est installée. Ces Service Packs résolvent plusieurs problèmes de mémoire connus.

Nombre de processeurs

Le Common Language Runtime (CLR) a les garbage collectors (GCS) suivants :

Station de travail (Mscorwks.dll)
Serveur (Mscorsvr.dll)

Si l’ordinateur qui exécute BizTalk Server est un système multiprocesseur, le .NET Framework utilise la version serveur du moteur d’exécution. C’est le paramétrage par défaut. Le ramasse-miettes du serveur est conçu pour un débit maximal. En outre, le collecteur de déchets du serveur est mis à l’échelle pour fournir des performances élevées. Ce ramasse-miettes alloue de la mémoire, puis la libère ensuite pour fournir des performances élevées sur le système. Par conséquent, un ordinateur exécutant BizTalk Server avec certains composants .NET Framework semble avoir une fuite de mémoire. Toutefois, dans ce scénario, l’utilisation élevée de la mémoire est le comportement attendu. Si l’ordinateur manque de mémoire système ou si le processus cesse de fonctionner en raison d’une mémoire adressable insuffisante, une condition de fuite de mémoire peut exister.

Si l’ordinateur exécutant BizTalk Server est un système de processeur unique, le .NET Framework utilise la version de station de travail du moteur d’exécution. Il s’agit du comportement par défaut. L’algorithme d’allocation du récupérateur de mémoire de la Workstation n’est pas conçu pour la mise à l’échelle ou pour la performance maximale. Ce collecteur de déchets utilise des méthodes de collecte de déchets concurrentes. Ces méthodes sont conçues pour les applications qui ont des interfaces utilisateur complexes. Ces applications peuvent nécessiter un garbage collection plus agressif.

Important

Cette section, méthode ou tâche contient des étapes vous indiquant comment modifier le Registre. Toutefois, des problèmes graves peuvent se produire si vous modifiez le Registre de manière incorrecte. Veillez donc à suivre attentivement ces étapes. Pour une protection supplémentaire, sauvegardez le Registre avant de le modifier. Ensuite, vous pouvez restaurer le Registre si un problème se produit. Pour plus d’informations sur la sauvegarde et la restauration du Registre, consultez Comment sauvegarder et restaurer le Registre dans Windows.

Parfois, il peut être approprié d’exécuter la version de station de travail du moteur d’exécution sur un système multiprocesseur. Vous pouvez utiliser la clé de Registre suivante pour basculer vers la version de station de travail du moteur d’exécution.

BizTalk 2006 et versions ultérieures

Créez la clé de registre de chaînes suivante CRL Hosting avec les valeurs correspondantes :

Clé :HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BizTalkHostName\CLR Hosting
Nom de la valeur : Saveur
Données de valeur : semaines

BizTalk 2004

Créez la clé de registre de chaînes suivante CRL Host avec les valeurs correspondantes :

Clé :HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc{GUID }\CLR Hosting
Nom de la valeur : Saveur
Données de valeur : semaines

Pour plus d’informations, consultez Considérations relatives aux performances pour les technologies Run-Time dans le .NET Framework.

Les causes et résolutions courantes sont les suivantes :

Seuils de limitation appliqués à l'utilisation de la mémoire physique et des processus

Les seuils de limitation de l’utilisation de la mémoire du processus et de la mémoire physique peuvent être modifiés dans BizTalk Server 2006 et dans les versions ultérieures.

Par défaut, le seuil de limitation de l’utilisation de la mémoire du processus est défini sur 25. Si cette valeur est dépassée et que l’utilisation de la mémoire du processus BizTalk est supérieure à 300 Mo, une condition de limitation peut se produire. Sur un serveur 32 bits, vous pouvez augmenter la valeur d’utilisation de la mémoire du processus à 50. Sur un serveur 64 bits, vous pouvez augmenter cette valeur à 100. Cela permet une consommation de mémoire supplémentaire par le processus BizTalk avant le contrôle.
Le seuil de limitation de l’utilisation de la mémoire physique a la valeur par défaut 0. Ce seuil mesure la mémoire système totale. Par conséquent, si une valeur autre que 0 est configurée, une condition de limitation peut se produire si un processus non BizTalk utilise une mémoire élevée.

Seuils de gestion de la déshydratation

Les seuils de déshydratation de mémoire par défaut peuvent entraîner une déshydratation trop importante lorsque des orchestrations sont exécutées sur un hôte 64 bits. Pour plus d’informations sur ce problème, consultez Propriétés par défaut de déshydratation.

Remarque

Les hôtes 64 bits sont pris en charge dans BizTalk Server 2006 et versions ultérieures.

Sur un matériel équivalent dans une instance hôte 32 bits, la déshydratation observée est nominale lorsque les mêmes orchestrations sont exécutées à l’aide des seuils de limitation de déshydratation de mémoire par défaut.

Étant donné que l’architecture 64 bits fournit un espace d’adressage de mémoire étendu (16 To au lieu de 4 Go), les instances d’hôte 64 bits sont allouées plus de mémoire que les instances d’hôte 32 bits. Cela peut entraîner le dépassement des seuils de limitation de mémoire par défaut.

Pour contourner ce comportement, modifiez les valeurs VirtualMemoryThrottlingCriteria et PrivateMemoryThrottlingCriteria dans le fichier BTSNTSvc64.exe.config. Utilisez les compteurs d'analyse de performances \Process\Virtual Bytes et \Process\Private Bytes pour déterminer la plus grande quantité de mémoire allouée par une instance d'orchestration.

Définissez la valeur OptimalUsage pour les deux propriétés en fonction des éléments suivants :
- VirtualMemoryThrottlingCriteria : \Process\Virtual Bytes value + 10%
- PrivateMemoryThrottlingCriteria : valeur \Process\Private Bytes + 10%
Définissez MaximalUsage pour les deux propriétés sur la valeur OptimalUsage + 30%

Par exemple, si la valeur du compteur \Process\Virtual Byte Performance Monitor pour une instance d’orchestration est de 5 784 787 695 octets (5 517 Mo), définissez la valeur OptimalUsage pour VirtualMemoryThrottlingCri à 6 069 Mo (5 784 787 695 * 1,10 = 6 363 266 464,5 octets).

Définissez la valeur MaximalUsage pour VirtualMemoryThrottlingCriteria sur 7 889 Mo (6 363 266 464,5 * 1,30 = 8 272 246 403,85 octets).

Si la valeur du compteur \Process\Private Bytes Performance Monitor est 435689400 octets (415 Mo), définissez la valeur OptimalUsage pour PrivateMemoryThrottlingCriteria sur 457 Mo (435689400 * 1,10 = 479258340 octets).

Définissez la valeur MaximalUsage pour PrivateMemoryThrottlingCriteria sur 594 Mo (479258340 * 1,30 = 623035842).

Pour cet exemple, les valeurs suivantes seraient spécifiées dans le fichier BTSNTSvc64.exe.config pour diminuer la régulation.

compteur du moniteur de performances	Mémoire allouée	Utilisation Optimale	Utilisation Maximale
\Process\Virtual Bytes	5 784 787 695 octets (5517 Mo)	6069	7889
\Process\Bytes privés	435 689 400 octets (415 Mo)	457	594

Ces valeurs sont ensuite représentées dans le fichier BTSNTSvc64.exe.config comme suit :

<xlangs>
    <Configuration>
       <Dehydration>
         <VirtualMemoryThrottlingCriteria OptimalUsage="6069" MaximalUsage="7889" IsActive="true" />
         <PrivateMemoryThrottlingCriteria OptimalUsage="457" MaximalUsage="594" IsActive="true" />
       </Dehydration>
    </Configuration>
</xlangs>

Pour déterminer l'instance hôte qui exécute l'orchestration, vous pouvez faire correspondre l'ID de processus à partir des compteurs \BizTalk : Messaging\ID Process et \Process\ID Process Performance Monitor. Vérifiez ensuite la valeur moyenne affichée pour les compteurs \Process\VirtualBytes et \Process\Private Bytes Analyseur de performances correspondants.

Remarque

Il est important de noter que même une déshydratation élevée peut entraîner une diminution significative des performances lorsque la BizTalkMsgBoxDb base de données fonctionne sur SQL Server 2008.

Packs de services et mises à jour cumulatives de BizTalk Server

Les service packs BizTalk Server et les mises à jour cumulatives incluent les derniers correctifs. Celles-ci incluent celles qui affectent des problèmes connus System.OutOfMemoryException.

HeapDeCommitFreeBlockThreshold

Par défaut, la valeur de la clé de HeapDeCommitFreeBlockThreshold Registre est 0. La valeur 0 signifie que le gestionnaire de tas désactive chaque page de 4 kilo-octets (Ko) qui devient disponible. Les opérations de désengagement peuvent entraîner une fragmentation de la mémoire virtuelle. La taille du HeapDeCommitFreeBlockThreshold paramètre dans le gestionnaire de tas dépend du type de travail effectué par le système. Une taille de 0x00040000 est une valeur de départ recommandée.

Tenez compte des informations suivantes avant de modifier la valeur de la HeapDeCommitFreeBlockThreshold clé de Registre :

Cette modification s’applique uniquement aux problèmes de fragmentation de la mémoire.
Cette modification est à l’échelle du système. Par conséquent, la plupart des processus utilisent davantage de mémoire au démarrage.
Considérez uniquement cette modification pour les systèmes qui ont BizTalk Server comme mission principale.

Pour réduire la fragmentation de la mémoire virtuelle, vous pouvez augmenter la taille du paramètre HeapDeCommitFreeBlockThreshold dans le gestionnaire de tas en modifiant la valeur de la clé de Registre suivante sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager:

Nom de la valeur : HeapDeCommitFreeBlockThreshold
Type de valeur : REG_DWORD
Données de valeur : 0x00040000 (il s’agit de la valeur de départ recommandée.)
Valeur par défaut : non présente

Opérations de transformation

Lorsque BizTalk Server effectue des opérations de transformation XML sur des messages assez volumineux dans un port de réception, dans un port d’envoi ou dans XLANG, les transformations XSL chargent le message entier en mémoire.

Pour résoudre ce problème, utilisez l’une des méthodes suivantes :

Réduisez le nombre de messages que BizTalk Server traite en même temps.
Réduisez la taille du message XML en cours de transformation.

L’objet System.Policy.Security.Evidence est fréquemment utilisé dans les transformations et peut consommer beaucoup de mémoire. Lorsqu’une carte contient un script functoid qui utilise C# inline (ou tout autre langage inline), l’assembly est créé en mémoire. L’objet System.Policy.Security.Evidence utilise l’objet de l’assembly appelant réel. Cette situation crée un objet rooté qui n’est pas supprimé tant que le service BizTalk n’est pas redémarré.

La plupart des bizTalk functoids par défaut sont implémentés en tant que script inline. Ces éléments peuvent provoquer l'accumulation d'objets en mémoire. Pour réduire la consommation de mémoire, nous vous recommandons de placer toute carte qui utilise ces functoids dans un petit assemblage. Ensuite, référencez cet assembly. Utilisez le graphique suivant pour déterminer l’utilisation functoids d’un script inline et qui functoids n’utilisent pas de script inline.

Dans la deuxième colonne, Oui signifie qu’il functoid est implémenté en tant que script inline et qu’il entraîne System.Byte[] la collecte d’objets en mémoire. Non signifie que ce functoid n’est pas implémenté en tant que script inline et qu’il n’entraîne pas la collecte d’objets en mémoire.

Fonctoïdes	Script en ligne ?
Tous les fonctoids de chaîne	Oui
Toutes les fonctions mathématiques	Oui
Tous les composants logiques à l'exception d'IsNil	Oui
Fonctoid logique IsNil	Non
Tous les fonctoids de date/heure	Oui
Tous les fonctoids de conversion	Oui
Toutes les fonctionnalités scientifiques	Oui
Tous les fonctoids cumulatifs	Oui
Toutes les fonctions de base de données	Non

Fonctoids avancés	Script en ligne ?
Fonctoid de Bouclage	Non
Fonctoid de l'aplatissement du mappage de valeur	Non
Fonctoid Déclarer	Non
Extracteur de fonctoids pour tables	Non
Fonctoid Boucle de table	Non
Fonction de script avec C# intégré	Oui
Programmation du fonctoid avec JScript.NET en ligne	Oui
Fonctoid script avec Inline Visual Basic .NET	Oui
Fonctoid de script avec XSLT inline	Non
Fonction de script avec modèle d'appel XSLT intégré	Non
Fonctoid de scriptage appelant l’assembly externe	Non
Fonctoid Valeur nil	Non
Fonctoid de mappage des valeurs	Non
Fonction Copie en Masse	Non
Itération du Fonctoid	Non
Index de Fonctoid	Non
Fonctoid Nombre d’enregistrements	Non

BizTalk Server 2006 et versions ultérieures améliorent considérablement la gestion de la mémoire pour les documents volumineux. Pour ce faire, BizTalk Server implémente un seuil de taille de message configurable pour le chargement de documents en mémoire pendant les opérations de transformation. Le seuil de taille de message par défaut est de 1 Mo. Pour plus d’informations sur le paramètre TransformThreshold, consultez comment BizTalk Server traite les messages volumineux.

Grandes valeurs d'attribut et grandes valeurs d'élément

Lorsque BizTalk Server exécute un pipeline de réception ou un pipeline d’envoi sur un document XML, la charge utile est traitée en mémoire si le document contient une ou plusieurs des entités suivantes :

Valeurs d’attribut grandes
Valeurs d’éléments importants
Balises d’attribut ou d’élément volumineuses

Pour résoudre ce problème, limitez la taille de ces entités. Si cette méthode n’est pas possible, assurez-vous que votre instance HÔTE BizTalk ne traite pas plusieurs documents tels que ceux-ci en même temps.

Composants de pipeline personnalisés

Vous utilisez un composant de pipeline personnalisé qui charge l’ensemble du flux en mémoire. Tous les composants inclus dans BizTalk Server, à l’exception des transformations, prennent en charge la diffusion en continu. Ces composants n’utilisent pas autant de mémoire pendant la diffusion en continu. Toutefois, les composants de pipeline personnalisés peuvent ne pas prendre en charge la diffusion en continu.

Streaming sous forte pression

Les hôtes tombent en panne de mémoire lorsqu'ils fonctionnent sous une forte pression. BizTalk Server utilise des pipelines et des adaptateurs qui supportent la diffusion en continu. En streaming, chaque composant charge un petit fragment du flux en mémoire. Étant donné que chaque message inclut d’autres structures de données, ainsi qu’un contexte de message pouvant être significatif ou petit, ce comportement affecte le comportement de BizTalk Server sous un stress lourd.

Le comportement de BizTalk Server est affecté, car le moteur charge un nombre préconfiguré de messages. Le nombre de messages que le moteur charge est basé sur les valeurs qui apparaissent dans le champ LowWaterMark et le champ HighWaterMark de la Adm_serviceClass table. La Adm_serviceClass table se trouve dans la base de données de gestion BizTalk. Ces valeurs contrôlent le nombre de messages que BizTalk Server traite ou envoie en même temps.

La valeur HighWaterMark correspond au nombre total de messages que le moteur traite en même temps. La valeur par défaut est 200 messages par processeur. Par conséquent, sur un serveur 8 processeurs, l’hôte d’envoi tente de traiter 1 600 messages (200 * 8) en même temps.

Si vous supposez que chaque message est de 50 Ko, les messages sont 80 Mo (1 600 * 50 = 80 000 Ko).

Pour résoudre ce problème, vous pouvez modifier la valeur HighWaterMark et la valeur LowWaterMark dans la base de données. Les valeurs que vous utilisez dépendent de la taille des messages. Pour BizTalk Server 2006 et versions ultérieures, vous pouvez modifier les paramètres de limitation d’hôte par défaut.

Essayez de simplifier le problème

Si vous avez identifié une fuite de mémoire, essayez de déterminer la cause en supprimant des composants personnalisés ou en simplifiant une carte. Essayez également de reproduire le problème à l’aide d’une orchestration simple ou d’une solution simple. En règle générale, vous devez créer des hôtes de réception distincts pour les adaptateurs de réception. Vous devez également créer des hôtes d’envoi distincts pour les adaptateurs d’envoi. Lorsque vous utilisez cette méthode, chaque adaptateur peut s’exécuter dans un processus distinct. Par conséquent, si votre processus BizTalk Server rencontre une condition de mémoire insuffisante, vous savez quels composants sont impliqués.

Étapes de dépannage

Pour résoudre une situation de mémoire insuffisante, utilisez l'outil Debug Diagnostics pour surveiller les allocations de mémoire sur une période. L’outil Diagnostics de débogage peut créer et analyser un fichier de vidage de fuite de mémoire (.dmp). Lorsque vous résolvez les fuites de mémoire, l’objectif est d’attacher Leaktrack.dll avant que la condition de mémoire élevée ne se reproduise pour capturer la croissance de la mémoire au fil du temps. Leaktrack.dll est inclus avec l'outil de diagnostique de débogage.

Installez l’outil Debug Diagnostics.

Vous pouvez télécharger le fichier suivant à partir du Centre de téléchargement Microsoft :
Téléchargez maintenant le package de l'outil de débogage et de diagnostic

Pour plus d’informations sur le téléchargement des fichiers de support Microsoft, consultez Comment obtenir des fichiers de support Microsoft à partir de services en ligne.

Microsoft a analysé ce fichier en vue de détecter la présence de virus. Microsoft a utilisé les logiciels de détection de virus les plus récents disponibles à la date de publication de ce fichier. Le fichier est conservé sur des serveurs sécurisés, ce qui empêche toute modification non autorisée du fichier.
Utilisez Analyseur de performances pour collecter des données sur les performances du système. Ces données peuvent fournir des indicateurs importants sur l’efficacité de votre environnement BizTalk Server. L’objectif est de capturer les performances du processus au fil du temps. Par conséquent, activez la journalisation de l'Analyseur de performances avant qu'une fuite de mémoire ne se produise.

Comment utiliser la journalisation du Moniteur de performances

Les sections suivantes décrivent comment utiliser la journalisation du moniteur de performances.

Sélectionner les données à journaliser

Pour sélectionner les données à consigner, utilisez la méthode appropriée pour votre système d’exploitation :

Pour Windows Server 2008 et Windows Server 2008 R2
1. Dans Les outils d’administration, ouvrez La fiabilité et l’Analyseur de performances.
2. Cliquez avec le bouton droit sur Analyseur de performances, cliquez sur Nouveau , puis sur Jeu de collecteurs de données.
3. Dans la zone Nom , tapez un nom descriptif, puis cliquez sur Suivant.
4. Notez le répertoire racine , puis cliquez sur Suivant.
5. Cliquez sur Démarrer ce jeu de collecteurs de données maintenant, puis sur Terminer.
6. Développez Jeux de collecteurs de données, développez Défini par l’utilisateur puis sélectionnez votre fichier.
7. Cliquez avec le bouton droit sur Journal du moniteur système, puis cliquez sur Propriétés.
8. Cliquez sur Ajouter sous l’onglet Compteurs de performances . Sélectionnez les objets suivants, puis cliquez sur Ajouter après avoir sélectionné chaque objet :
  - Exceptions .Net CLR
  - Mémoire .Net CLR
  - BizTalk : Messagerie
  - BizTalk : TDDS
  - Mémoire
  - Processus
  - Processeur
  - XLANG/s Orchestrations
  Si SQL Server est local, ajoutez également les objets suivants :
  - SQLServer : Bases de données
  - SQLServer : Statistiques générales
  - SQLServer : Gestionnaire de mémoire
9. Cliquez sur OK.
10. Modifiez la valeur de l'intervalle d'échantillonnage à 5 secondes.
  
  Remarque
  
  La valeur de l'intervalle d'échantillonnage et l'heure de début de la surveillance sont subjectives. Ces valeurs dépendent du moment où la fuite de mémoire est reproduite. Étant donné que le fichier journal peut être volumineux, spécifiez un intervalle dans lequel vous pouvez obtenir les informations dont vous avez besoin sans surcharger le serveur.
11. Cliquez sur OK.

Pour arrêter la collecte de données, cliquez sur Arrêter dans le menu Action .

Pour Windows Server 2003 ou pour Windows XP
1. Développez les journaux de performances et les alertes.
2. Cliquez avec le bouton droit sur Journaux du compteur, puis cliquez sur Nouveaux paramètres de journal. La boîte de dialogue Nouveaux paramètres de journal s’affiche.
3. Dans la zone Nom , tapez un nom descriptif, puis cliquez sur OK.
4. Notez l’emplacement du fichier journal. (Vous pouvez également cliquer sur l’onglet Fichiers journaux , puis sur Configurer pour modifier l’emplacement du fichier journal.)
5. Cliquez sur Ajouter des compteurs.
6. Sélectionnez Tous les compteurs et toutes les instances.
7. Dans la liste des objets Performance , sélectionnez les objets suivants. Cliquez sur Ajouter après avoir sélectionné chaque objet.
  - Exceptions .Net CLR
  - Mémoire .Net CLR
  - BizTalk : Messagerie
  - BizTalk : TDDS
  - Mémoire
  - Processus
  - Processeur
  - XLANG/s Orchestrations
  Si SQL Server est local, ajoutez également les objets suivants :
  - SQLServer : Bases de données
  - SQLServer : Statistiques générales
  - SQLServer : Gestionnaire de mémoire
8. Cliquez sur Fermer.
9. Remplacez la valeur dans l’intervalle d’échantillonnage des données par 5 secondes.
  
  Remarque
  
  La valeur de l’intervalle d’échantillonnage des données et l’heure de début à surveiller sont subjectives. Ces valeurs dépendent du moment où la fuite de mémoire est reproduite. Étant donné que le fichier journal peut être volumineux, spécifiez un intervalle dans lequel vous pouvez obtenir les informations dont vous avez besoin sans surcharger le serveur.
10. Cliquez sur OK. Pour arrêter la collecte de données, cliquez avec le bouton droit sur le nom du journal des compteurs, puis cliquez sur Arrêter.

Obtenir le fichier de vidage

Pour obtenir le fichier de vidage, utilisez l’une des méthodes suivantes :

Méthode 1 : Automatique

La création d’une règle de fuite de mémoire et de *handle* avec DebugDiag est l’approche recommandée pour capturer un vidage de mémoire. La règle mémoire et de gestion des fuites attache automatiquement Leaktrack.dll. Il est utilisé pour suivre les allocations de mémoire. Pour créer la règle sur la mémoire et la fuite de gestion, procédez comme suit :

Démarrez l’outil Debug Diagnostics 1.1.
Sélectionnez Mémoire et Gérer la fuite, puis cliquez sur Suivant.
Sélectionnez le processus Btsntsvc.exe, puis cliquez sur Suivant.
Dans la page Configurer la règle de fuite , procédez comme suit :
1. Cliquez pour activer la case à cocher Démarrer le suivi de la mémoire immédiatement lorsque la règle est activée . Sinon, vous pouvez spécifier une durée de préchauffement avant que LeakTrack.dll ne soit injecté dans le processus de BTSNTSvc.exe.
2. Cliquez sur Configurer, puis procédez comme suit :
  - Vérifiez que la création automatique d’une règle de blocage est sélectionnée. En sélectionnant cette option, un vidage de mémoire est créé automatiquement si le processus BTSNTSvc.exe s’arrête.
  - Cliquez pour sélectionner générer un userdump lorsque des octets virtuels atteignent la case à cocher, puis conservez la valeur par défaut 1024.
  - Cliquez pour sélectionner la case à cocher et chaque case à cocher supplémentaire , puis conservez la valeur par défaut 200. En sélectionnant l’option d’accès aux octets virtuels, un vidage de mémoire est automatiquement créé lorsque les octets virtuels utilisent 1024 Mo. Si les octets virtuels augmentent de 200 Mo, un autre vidage de mémoire est automatiquement créé.
3. Cliquez sur Enregistrer & Fermer.
4. Cliquez sur Suivant.
5. Dans la page Sélectionner l’emplacement de vidage et le nom de la règle , cliquez sur Suivant.
  
  Remarque
  
  Vous pouvez également modifier le chemin du fichier de vidage dans la zone Emplacement Userdump de cette page.
6. Cliquez sur Terminer pour activer la règle maintenant.
  
  Remarque
  
  Le statut de la règle est maintenant Suivi. Chaque fois qu’un vidage de mémoire est créé, la valeur augmente dans la colonne Nombre Userdump sous l’onglet Règles . L’emplacement de vidage de mémoire par défaut est C:\Program Files\DebugDiag\Logs.

Méthode 2 : Manuel

Vous pouvez également attacher manuellement Leaktrack.dll et obtenir manuellement le fichier de vidage de mémoire. Cela vous permet de contrôler le moment où le vidage de la mémoire est créé. Pour ce faire, procédez comme suit :

Démarrez l’outil Debug Diagnostics 1.1.
Cliquez sur l’onglet Processus .
Cliquez avec le bouton droit sur le processus Btsntsvc.exe, puis cliquez sur Surveiller les fuites.
Dans la boîte de dialogue Outil Debug Diagnostics , cliquez sur Oui, puis sur OK.

Créez une règle de blocage pour surveiller le même processus Btsntsvc.exe en cas d’arrêt du processus avant de pouvoir créer le vidage de la mémoire :

Démarrez l’outil Debug Diagnostics 1.1.
Sélectionnez Crash, puis cliquez sur Suivant.
Sélectionnez un processus spécifique, puis cliquez sur Suivant.
Sélectionnez le même processus Btsntsvc.exe, puis cliquez sur Suivant.
Dans la page Configuration avancée (facultatif), cliquez sur Suivant.
Dans la boîte de dialogue Sélectionner l’emplacement de vidage et le nom de la règle (facultatif), cliquez sur Suivant.
Sélectionnez Activer la règle maintenant, puis cliquez sur Terminer.

Lorsque le processus atteint 60 % à 80 % de RAM, cliquez avec le bouton droit sur le processus Btsntsvc.exe, puis cliquez sur Créer un dump mémoire complet. Si le processus BizTalk s’arrête avant de pouvoir créer le vidage utilisateur, la règle crash doit prendre effet et créer le vidage de la mémoire.

Arrêter la journalisation du Moniteur de performances

Si vous capturez un vidage de mémoire et des données avec l'Analyseur de performances, arrêtez la journalisation de l'Analyseur de performances environ deux minutes après la création du vidage de mémoire.

Analyser le fichier de vidage

Pour déterminer la cause d’une fuite de mémoire, vous pouvez utiliser l’outil Debug Diagnostics pour analyser le fichier de vidage. Pour ce faire, procédez comme suit :

Cliquez sur l’onglet Analyse avancée .
Cliquez sur Ajouter des fichiers de données, puis recherchez le fichier .dmp.
Sélectionnez le script Analyse de la pression de la mémoire , puis cliquez sur Démarrer l’analyse.

Par défaut, un fichier de rapport d’analyse (fichier .mht) est créé dans le C:\Program Files\DebugDiag\Reports dossier lorsque l’analyse est terminée. Le fichier de rapport s’affiche également dans votre navigateur. Le fichier de rapport contient les résultats de l’analyse. En outre, le fichier de rapport peut contenir des recommandations pour résoudre la fuite de mémoire.

Si vous utilisez des DLL personnalisées, vous pouvez ajouter le chemin d’accès aux symboles des fichiers .pdb personnalisés pour l’analyse. Pour ce faire, procédez comme suit :

Ouvrez l’outil Debug Diagnostics.
Dans le menu Outils , cliquez sur Options et Paramètres.
Dans la zone Chemin de recherche des symboles pour le débogage, tapez le chemin de symboles.

Si vous souhaitez obtenir de l’aide sur l’analyse du fichier de vidage, contactez les services de support technique Microsoft. Pour obtenir la liste complète des numéros de téléphone des services de support client et des informations sur les coûts de support, consultez le support technique.

Avant de contacter le service client, compressez le fichier de vidage, le journal du Moniteur de performance, le fichier de rapport d’analyse et les journaux d’événements mis à jour (fichiers .evt). Vous devrez peut-être envoyer ces fichiers à un ingénieur du support technique BizTalk Server.

Partager via