Partager via

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

  • Article

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 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 du commutateur /3 Go
  • Utilisation de composants personnalisés
  • Quelle version de Microsoft .NET Framework le système est en cours d’exécution
  • 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 le processus s’exécute en mémoire système 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 longue 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.

Durée de reproduction de 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 /3 Go 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 prend en charge l’adresse volumineuse. Un processus prend en compte les grandes adresses lorsque l’exécutable a l’indicateur IMAGE_FILE_LARGE_ADDRESS_AWARE défini dans l’en-tête d’image. Étant donné que le processus BizTalk prend en compte les grandes adresses, BizTalk bénéficie du commutateur /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 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 Analyseur de performances ing et quand alerter les administrateurs

Le commutateur /3 Go augmente également les octets privés maximum 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.

Process Windows Mémoire adressable (avec un processus ample prenant en compte les 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 /3 Go pour répondre aux exigences de performances d’un ordinateur exécutant 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 lorsque le commutateur /3 Go est activé.

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 /3 Go 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 souvenirs. 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 garbage collector du serveur est conçu pour un débit maximal. En outre, le garbage collector de serveur est mis à l’échelle pour fournir des performances élevées. Ce garbage collector alloue de la mémoire, puis libère ultérieurement de la mémoire 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 station de travail n’est pas conçu pour la mise à l’échelle ou pour le débit maximal. Ce garbage collector utilise des méthodes de garbage collector simultanées. 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, voir : Procédure de sauvegarde, de modification et de restauration du 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 : wks

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 : wks

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

Les causes et résolutions courantes sont les suivantes :

Seuils de limitation de 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 la limitation.

  • 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 limitation de 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.

Note

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 octets \Process\Virtual et \Process\Private Bytes Analyseur de performances 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 : \Process\Private Bytes value + 10%

  • Définir MaximalUsage pour les deux propriétés sur la valeur OptimalUsage + 30 %

Par exemple, si la valeur du compteur \Process\Virtual Byte Analyseur de performances pour une instance d’orchestration est de 5 784 787 695 octets (5 517 Mo), définissez la valeur OptimalUsage pour VirtualMemoryThrottlingCriteria à 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 de compteur \Process\Private Bytes Analyseur de performances 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 sont spécifiées dans le fichier BTSNTSvc64.exe.config pour réduire la limitation.

compteur Analyseur de performances Mémoire allouée OptimalUsage MaximumUsage
\Process\Virtual Bytes 5 784 787 695 octets (5517 Mo) 6069 7889
\Process\Private Bytes 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 le processus d’ID à partir du processus \BizTalk : Messaging\ID et \Process\ID Process Analyseur de performances compteurs. Vérifiez ensuite la valeur moyenne affichée pour les compteurs \Process\VirtualBytes et \Process\Private Bytes Analyseur de performances correspondants.

Note

Les informations que l’utilisateur doit remarquer même si la déshydratation élevée peut entraîner une diminution significative des performances lorsque la BizTalkMsgBoxDb base de données s’exécute sur SQL Server 2008.

Service Packs BizTalk Server et mises à jour cumulatives

Les service packs BizTalk Server et les mises à jour cumulatives incluent les derniers correctifs. Celles-ci incluent celles qui affectent les 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é-validation 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 dans le gestionnaire de HeapDeCommitFreeBlockThreshold 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 entraîner la System.Byte[] collecte d’objets en mémoire. Pour réduire la consommation de mémoire, nous vous recommandons de placer une carte qui les utilise functoids dans un petit assembly. 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. Cela ne signifie pas qu’il functoid n’est pas implémenté en tant que script inline et qu’il n’entraîne System.Byte[] pas la collecte d’objets en mémoire.

Fonctoids Script inline ?
Tous les fonctoids de chaîne Oui
Tous les fonctoids mathématiques Oui
Tous les fonctoids logiques à l’exception d’IsNil Oui
Fonctoid IsNil logique Non
Tous les fonctoids date/heure Oui
Tous les fonctoids de conversion Oui
Tous les fonctoids scientifiques Oui
Tous les fonctoids cumulés Oui
Tous les fonctoids de base de données Non
Fonctoids avancés Script inline ?
Fonctoid Bouclage Non
Fonctoid aplatissement de mappage de valeur Non
Fonctoid Déclarer Non
Fonctoid Extracteur de table Non
Fonctoid Bouclage de table Non
Fonctoid script avec Inline C# Oui
Fonctoid script avec JScript.NET inline Oui
Fonctoid script avec Inline Visual Basic .NET Oui
Fonctoid de script avec XSLT inline Non
Fonctoid de script avec le modèle d’appel XSLT inline Non
Fonctoid de script appelant l’assembly externe Non
Fonctoid Valeur nil Non
Fonctoid Mappage des valeurs Non
Fonctoid Copie de masse Non
Fonctoid Itération Non
Fonctoid Index 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.

Valeurs d’attribut volumineuses et valeurs d’élément volumineuses

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 volumineuses
  • Valeurs d’éléments volumineux
  • 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.

Diffusion en continu sous un stress lourd

Envoyez des hôtes hors de mémoire lorsqu’ils fonctionnent sous un stress lourd. BizTalk Server envoie des pipelines et envoie des adaptateurs prennent en charge 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 les problèmes liés à une condition de mémoire insuffisante, utilisez l’outil Diagnostics de débogage pour surveiller les allocations de mémoire au fil du temps. 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 dans l’outil Diagnostics de débogage.

  1. Installez l’outil Debug Diagnostics.

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

    Pour plus d’informations sur la façon de télécharger les fichiers de support Microsoft, consultez l’article Comment obtenir des fichiers de support Microsoft auprès des 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.

  2. 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 Analyseur de performances journalisation avant la fuite de mémoire.

Comment utiliser la journalisation Analyseur 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 Outils d’administration, ouvrez fiabilité et 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 CLR .Net
      • Mémoire CLR .Net
      • BizTalk : Messagerie
      • BizTalk : TDDS
      • Mémoire
      • Process
      • 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 zone De valeur d’intervalle d’exemple sur 5 secondes.

      Note

      La valeur Sample Interval 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.

    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 du 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 le bouton Onglet Fichiers journaux, puis cliquez 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 CLR .Net
      • Mémoire CLR .Net
      • BizTalk : Messagerie
      • BizTalk : TDDS
      • Mémoire
      • Process
      • 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.

      Note

      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 mémoire et gérer la fuite, procédez comme suit :

  1. Démarrez l’outil Debug Diagnostics 1.1.

  2. Sélectionnez Mémoire et Gérer la fuite, puis cliquez sur Suivant.

  3. Sélectionnez le processus Btsntsvc.exe, puis cliquez sur Suivant.

  4. 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 d’échauffement avant que LeakTrack.dll soit injectée 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 et fermer.

    4. Sélectionnez Suivant.

    5. Dans la page Sélectionner l’emplacement de vidage et le nom de la règle, cliquez sur Suivant.

      Note

      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.

      Note

      L’état 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 quand le vidage de la mémoire est créé. Pour ce faire, procédez comme suit :

  1. Démarrez l’outil Debug Diagnostics 1.1.
  2. Cliquez sur l’onglet Processus .
  3. Cliquez avec le bouton droit sur le processus Btsntsvc.exe, puis cliquez sur Surveiller les fuites.
  4. 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 :

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

Lorsque le processus atteint 60 % à 80 % de LA RAM, cliquez avec le bouton droit sur le processus Btsntsvc.exe, puis cliquez sur Créer un utilisateur 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 Analyseur de performances

Si vous capturez un vidage de mémoire et Analyseur de performances données, arrêtez Analyseur de performances journalisation environ deux minutes après la création du vidage de la 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 :

  1. Cliquez sur l’onglet Analyse avancée.
  2. Cliquez sur Ajouter des fichiers de données, puis recherchez le fichier .dmp.
  3. 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 des symboles des fichiers .pdb personnalisés pour l’analyse. Pour ce faire, procédez comme suit :

  1. Ouvrez l’outil Debug Diagnostics.
  2. Dans le menu Outils , cliquez sur Options et Paramètres.
  3. Dans la zone Rechercher le chemin de recherche de symboles pour le débogage , tapez le chemin d’accès au symbole.

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 les services de support client, compressez le fichier de vidage, le journal Analyseur de performances, 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.