Capturer des images mémoire sur la plateforme Azure App Service

Article
06/22/2023

Cet article fournit des conseils sur les fonctionnalités de débogage de Microsoft Azure App Service pour capturer les images mémoire. La méthode de capture que vous utilisez est dictée par le scénario dans lequel vous capturez une image mémoire pour résoudre un problème de performances ou de disponibilité. Par exemple, la capture d’un vidage de mémoire est différente pour un processus qui subit une consommation de mémoire excessive que pour un processus qui lève des exceptions ou répond lentement. Le processus dans ce contexte est le processus de travail IIS (Internet Information Services) (W3WP, qui s’exécute en tant que w3wp.exe).

Mappage de scénarios de vidage mémoire aux fonctionnalités de débogage Azure App Service

Le tableau suivant fournit des recommandations sur les commandes exécutées par chaque fonctionnalité App Service pour générer une image mémoire. Il existe tellement d’approches pour capturer une image mémoire que le processus peut prêter à confusion. Si vous maîtrisez déjà la capture d’un vidage mémoire W3WP, ces informations ne sont pas destinées à modifier votre approche. Au lieu de cela, nous espérons fournir des conseils pour les utilisateurs inexpérimentés qui n’ont pas encore développé de préférence.

Scénario	Azure App Service fonctionnalité de débogage	Command
Ne répond pas ou lent	Réparation automatique (durée de la demande)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`
Plantage (arrêt du processus)	Surveillance des incidents	Utilise DbgHost pour capturer une image mémoire
Plantage (exceptions gérées)	Traces dans Application Insights/Log Analytics	Aucun
Blocage (exceptions non gérées)	Débogueur de capture instantanée Application Insights	Aucun
Utilisation excessive du processeur	Surveillance proactive du processeur	`procdump -accepteula -dc "Message" -ma <PID> <PATH>`
Consommation de mémoire excessive	Réparation automatique (limite de mémoire)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`

Remarque

Nous avons une recommandation secondaire pour la capture d’un vidage mémoire de processus W3WP dans le scénario qui ne répond pas ou lent. Si ce scénario est reproductible et que vous souhaitez capturer le vidage immédiatement, vous pouvez utiliser l’outil de diagnostic Collecter une image mémoire . Cet outil se trouve dans la page d’ensemble d’outils Diagnostiquer et résoudre les problèmes pour l’application web App Service donnée dans le Portail Azure. Un autre emplacement pour case activée pour les exceptions générales et les performances médiocres se trouve sur la page Journaux des événements de l’application. (Vous pouvez également accéder aux journaux des applications à partir de la page Diagnostiquer et résoudre les problèmes.) Nous abordons toutes les méthodes disponibles dans la section « Descriptions des fonctionnalités de débogage Azure App Service développées ».

Descriptions des scénarios de processus développés

Cette section contient des descriptions détaillées des six scénarios présentés dans le tableau précédent.

Scénario ne répondant pas ou lent

Lorsqu’une requête est envoyée à un serveur web, un certain code doit généralement être exécuté. L’exécution du code se produit dans le processusw3wp.exe sur les threads. Chaque thread a une pile qui montre ce qui est en cours d’exécution.

Un scénario qui ne répond pas peut être permanent (et susceptible d’expirer) ou lent. Par conséquent, le scénario qui ne répond pas est un scénario dans lequel une requête prend plus de temps que prévu pour s’exécuter. Ce que vous pouvez envisager d’être lent dépend de ce que fait le code. Pour certaines personnes, un délai de trois secondes est lent. Pour d’autres, un délai de 15 secondes est acceptable. Fondamentalement, si vous voyez des métriques de performances qui indiquent une lenteur, ou si un super utilisateur déclare que le serveur répond plus lentement que la normale, vous avez un scénario qui ne répond pas ou est lent.

Scénario d’incident (arrêt du processus)

Au fil des années, Microsoft .NET Framework a amélioré la gestion des exceptions. Dans la version actuelle de .NET, l’expérience de gestion des exceptions est encore meilleure.

Historiquement, si un développeur n’a pas mis d’extraits de code dans un bloc try-catch et qu’une exception a été levée, le processus s’est terminé. Dans ce cas, une exception non gérée dans le code du développeur a mis fin au processus. Les versions plus modernes de .NET gèrent certaines de ces exceptions « non gérées » afin que le processus qui exécute le code ne se bloque pas. Toutefois, toutes les exceptions non gérées ne sont pas levées directement à partir du code personnalisé. Par exemple, les violations d’accès (telles que 0xC0000005 et 0x80070005) ou un dépassement de capacité de la pile peuvent mettre fin au processus.

Scénario d’incident (exceptions gérées)

Bien qu’un développeur de logiciels prenne particulièrement soin de déterminer tous les scénarios possibles dans lesquels le code s’exécute, quelque chose d’inattendu peut se produire. Les erreurs suivantes peuvent déclencher une exception :

Valeurs Null inattendues
Cast non valide
Objet instancié manquant

Il est recommandé de placer l’exécution du code dans des blocs de code try-catch. Si un développeur utilise ces blocs, le code a la possibilité d’échouer correctement en gérant spécifiquement ce qui suit l’événement inattendu. Une exception gérée est une exception levée à l’intérieur d’un bloc try et interceptée dans le bloc catch correspondant. Dans ce cas, le développeur s’attendait à ce qu’une exception puisse se produire et a codé un bloc try-catch approprié autour de cette section de code.

Dans le bloc catch, il est utile de capturer suffisamment d’informations dans une source de journalisation pour que le problème puisse être reproduit et, au final, résolu. Les exceptions sont des chemins de code coûteux en termes de performances. Par conséquent, le fait d’avoir de nombreuses exceptions affecte les performances.

Scénario d’incident (exceptions non gérées)

Des exceptions non gérées se produisent lorsque le code tente d’effectuer une action qu’il ne s’attend pas à rencontrer. Comme dans le scénario d’incident (arrêt du processus), ce code n’est pas contenu dans un bloc de code try-catch. Dans ce cas, le développeur n’a pas prévu qu’une exception puisse se produire dans cette section de code.

Ce scénario diffère des deux scénarios d’exception précédents. Dans le scénario Incident (exceptions non gérées), le code en question est le code que le développeur a écrit. Ce n’est pas le code du framework qui lève l’exception, ni l’une des exceptions non gérées qui tue le processus w3wp.exe . En outre, étant donné que le code qui lève une exception ne se trouve pas dans un bloc try-catch, il n’est pas possible de gérer l’exception correctement. La résolution des problèmes du code est initialement un peu plus complexe. Votre objectif est de trouver le texte, le type et la pile de l’exception qui identifie la méthode qui lève cette exception non gérée. Ces informations vous permettent d’identifier l’emplacement où vous devez ajouter le bloc de code try-catch. Ensuite, le développeur peut ajouter la logique similaire pour journaliser les détails des exceptions qui doivent exister dans le scénario d’incident (exceptions non gérées).

Scénario d’utilisation excessive du processeur

Qu’est-ce que l’utilisation excessive du processeur ? Cette situation dépend de ce que fait le code. En général, si l’utilisation du processeur à partir du processus w3wp.exe est de 80 %, votre application se trouve dans une situation critique qui peut entraîner divers symptômes. Voici quelques symptômes possibles :

Lenteur
Erreurs
Autre comportement non défini

Même une utilisation de 20 % du processeur peut être considérée comme excessive si le site web ne fournit que des fichiers HTML statiques. La résolution des problèmes post-mortem d’un pic de processeur excessif en générant une image mémoire ne vous aidera probablement pas à déterminer la méthode spécifique qui l’utilise. Le mieux que vous puissiez faire est de déterminer quelles demandes ont probablement pris le plus de temps, puis d’essayer de reproduire le problème en testant la méthode identifiée. Cette procédure suppose que vous n’exécutez pas d’analyseurs de performances sur les systèmes de performances qui ont capturé ce burst. Dans de nombreux cas, vous pouvez provoquer des problèmes de performances en faisant en sorte que les moniteurs s’exécutent constamment en temps réel.

Scénario de consommation de mémoire excessive

Si une application s’exécute dans un processus 32 bits, une consommation excessive de mémoire peut être un problème. Même une petite quantité d’activité peut consommer les 2 à 3 Go d’espace d’adressage virtuel alloué. Un processus 32 bits ne peut jamais dépasser un total de 4 Go, quelle que soit la quantité de mémoire physique disponible.

Un processus 64 bits est alloué plus de mémoire qu’un processus 32 bits. Il est plus probable que le processus 64 bits consomme la quantité de mémoire physique sur le serveur que le processus consomme son espace d’adressage virtuel alloué.

Par conséquent, ce qui constitue un problème de consommation de mémoire excessive dépend des facteurs suivants :

Nombre de bits du processus (32 bits ou 64 bits)
Quantité de mémoire considérée comme « normale ».

Si votre processus consomme plus de mémoire que prévu, collectez une image mémoire à des fins d’analyse afin de déterminer ce qui consomme des ressources mémoire. Pour plus d’informations, consultez Créer un vidage mémoire de votre App Service lorsqu’il consomme trop de mémoire.

Maintenant que vous disposez d’un peu plus de contexte sur les différents scénarios de processus qu’un vidage mémoire peut vous aider à résoudre les problèmes, nous allons aborder l’outil recommandé pour capturer les vidages de mémoire sur la plateforme Azure App Service.

Descriptions des fonctionnalités de débogage Azure App Service développées

Dans le tableau de la section « Mappage des scénarios de vidage de mémoire aux fonctionnalités de débogage Azure App Service », nous avons identifié six fonctionnalités de débogage qui sont destinées à collecter des vidages mémoire. Chacune de ces fonctionnalités est accessible à partir de la Portail Azure dans la page Diagnostiquer et résoudre les problèmes lorsque vous sélectionnez la vignette Outils de diagnostic.

Dans les sections suivantes, nous abordons chacune de ces fonctionnalités de débogage plus en détail.

Fonctionnalité de réparation automatique (durée de la demande)

La fonctionnalité de réparation automatique (durée de la demande) est utile pour capturer une image mémoire si la réponse prend plus de temps que prévu. Vous pouvez voir le lien vers réparation automatique dans la vignette Outils de diagnostic dans la capture d’écran précédente. Sélectionnez ce lien pour accéder directement à la fonctionnalité, ou sélectionnez la vignette Outils de diagnostic pour passer en revue tous les outils disponibles dans la page Outils de diagnostic . Pour plus d’informations sur la configuration de cette fonctionnalité, consultez les articles suivants :

La fonctionnalité de réparation automatique est illustrée dans la capture d’écran suivante.

Une autre fonctionnalité nommée « Collecter une image mémoire » est utile dans ce scénario lorsque le problème se produit actuellement ou est reproductible. Cette fonctionnalité collecte rapidement une image mémoire à la demande manuelle.

Collecter une fonctionnalité de vidage mémoire

Pour comprendre la configuration de la fonctionnalité Collecter un vidage mémoire, consultez Collecter les services d’application de vidage mémoire. Cette approche nécessite une intervention manuelle. La capture d’écran suivante montre la page Collecter un vidage mémoire .

Pour utiliser la fonctionnalité, sélectionnez un compte de stockage dans lequel stocker l’image mémoire. Ensuite, sélectionnez le serveur instance à partir duquel vous souhaitez collecter l’image mémoire. Si vous avez plusieurs instance, assurez-vous que le problème que vous déboguez se produit sur cette instance. En outre, cette configuration redémarre votre application. Notez qu’un redémarrage peut ne pas être optimal sur une application de production en cours d’exécution.

Fonctionnalité de surveillance des incidents

La fonctionnalité Analyse des incidents est utile pour capturer une image mémoire si une exception non gérée provoque l’arrêt du processus W3WP. La capture d’écran suivante montre la page Analyse des incidents dans outils de diagnostic :

Pour afficher une procédure guidée sur la configuration de la fonctionnalité de surveillance des incidents dans Azure App Service, consultez Supervision des incidents dans Azure App Service.

Traces dans la fonctionnalité Application Insights/Log Analytics

Une exception gérée est un scénario dans lequel le code contenu dans un bloc try-catch tente d’effectuer une action inattendue ou non prise en charge. Par exemple, l’extrait de code suivant tente de diviser un nombre par zéro, même s’il s’agit d’une opération illégale :

decimal percentage = 0, number = 1000, total = 0;
try
{
  percentage = number / total;
}
catch (DivideByZeroException divEx)
{
  _logger.LogError("A handled exception just happened: -> {divEx.Message}", divEx.Message);
}

Cet extrait de code provoque une exception de division par zéro qui est gérée, car l’opération mathématique non prise en charge est placée dans un bloc try-catch. Application Insights ne journalise pas les exceptions gérées, sauf si vous incluez intentionnellement le package NuGet Microsoft.ApplicationInsights dans votre code d’application, puis ajoutez le code pour journaliser les informations. Si l’exception se produit après l’ajout du code, vous pouvez afficher l’entrée dans Log Analytics, comme illustré dans la capture d’écran suivante.

Le code Kusto suivant contient la requête utilisée pour extraire les données de Log Analytics :

traces
| where message has "handled"
 | project timestamp, severityLevel, message, operation_Name, cloud_RoleInstance

La message colonne est l’emplacement dans lequel vous pouvez stocker les détails nécessaires pour trouver la cause racine de l’exception. Le code utilisé pour écrire cette requête se trouve dans l’extrait de code division par zéro. Le développeur de logiciels qui a écrit ce code est la meilleure personne pour poser des questions sur ces types d’exceptions et les attributs nécessaires à la capture pour l’analyse des causes racines.

La meilleure approche pour ajouter cette fonctionnalité à votre code d’application dépend de la pile du code d’application et de la version dont vous disposez (par exemple, ASP.NET, ASP.NET Core, MVC, Razor, etc.). Pour déterminer la meilleure approche pour votre scénario, consultez Journalisation d’Application Insights avec .NET.

Fonctionnalité Journaux des événements d’application (exceptions gérées)

Vous pouvez également trouver des exceptions non gérées dans l’exception gérée dans la page Journaux des événements d’application des outils de diagnostic dans le Portail Azure, comme illustré dans la capture d’écran suivante.

Dans ce cas, vous recevez le même message d’erreur que celui que vous avez enregistré via votre code. Toutefois, vous perdez une certaine flexibilité dans la façon dont vous pouvez personnaliser les requêtes sur les journaux de suivi Application Insights.

Fonctionnalité de débogueur de capture instantanée Application Insights

Les exceptions non gérées sont également consignées dans la page Journaux des événements de l’application , comme indiqué dans le texte de sortie de la section suivante. Toutefois, vous pouvez également activer le débogueur d’instantané Application Insights. Cette approche n’exige pas que vous ajoutiez du code à votre application.

Fonctionnalité Journaux des événements d’application (exceptions non gérées)

La sortie suivante provient de la page Journaux des événements des applications des Outils de diagnostic dans le Portail Azure. Il montre un exemple de texte d’une exception d’application non gérée :

Category: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
EventId: 1
SpanId: 311d8cb5d10b1a6e
TraceId: 041929768411c12f1c3f1ccbc91f6751
ParentId: 0000000000000000
RequestId: 8000006d-0001-bf00-b63f-84710c7967bb
RequestPath: /Unhandled

An unhandled exception has occurred while executing the request.

Exception:
System.DivideByZeroException: Attempted to divide by zero.
   at System.Decimal.DecCalc.VarDecDiv(DecCalc& d1, DecCalc& d2)
   at System.Decimal.op_Division(Decimal d1, Decimal d2)
   at contosotest.Pages.Pages Unhandled.ExecuteAsync()
     in C:\Users\contoso\source\repos\contosorepo\contosorepo\Pages\Unhandled.cshtml:line 12

Une différence ici par rapport à l’exception gérée dans le journal des applications est l’existence de la pile qui identifie la méthode et la ligne à partir de laquelle l’exception est levée. En outre, vous pouvez supposer sans risque que la fonctionnalité Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware contient du code pour intercepter cette exception non gérée afin d’éviter l’arrêt du processus. L’exception est affichée dans Application Insights sous l’onglet Exceptions de la page Échecs , comme illustré dans la capture d’écran suivante.

Dans cette vue, vous voyez toutes les exceptions, pas seulement celle que vous recherchez. La représentation graphique de toutes les exceptions qui se produisent dans votre application est utile pour obtenir une vue d’ensemble de l’intégrité de votre système. Le tableau de bord Application Insights est plus utile visuellement que les journaux des événements d’application.

Fonctionnalité de surveillance proactive du processeur

Dans les scénarios d’utilisation excessive du processeur, vous pouvez utiliser l’outil de surveillance proactive du processeur. Pour plus d’informations sur cet outil, consultez Atténuer vos problèmes de processeur avant qu’ils ne se produisent. L’image suivante montre la page Surveillance proactive de l’UC dans outils de diagnostic.

Vous devez considérer l’utilisation du processeur de 80 % ou plus comme une situation critique qui nécessite une investigation immédiate. Dans la page Surveillance proactive de l’UC , vous pouvez définir le scénario pour lequel vous souhaitez capturer un vidage mémoire en fonction des catégories de surveillance des données suivantes :

Seuil du processeur
Seuil en secondes
Fréquence de surveillance

Le seuil du processeur identifie la quantité de processeur de l’ordinateur utilisée par le processus ciblé (W3WP dans ce cas). Le seuil en secondes est la durée pendant laquelle le processeur a été utilisé au seuil de l’UC. Par exemple, s’il y a 75 % d’utilisation du processeur pendant un total de 30 secondes, le vidage de la mémoire est capturé. Comme configuré dans la page Surveillance proactive de l’UC , le processus est vérifié pour détecter les violations de seuil toutes les 15 secondes.

Fonctionnalité de réparation automatique (limite de mémoire)

La fonctionnalité de réparation automatique (limite de mémoire) est utile pour capturer une image mémoire si le processus consomme plus de mémoire que prévu. Là encore, faites attention au nombre de bits (32 ou 64). Si vous rencontrez une sollicitation de la mémoire dans le contexte du processus 32 bits et que la consommation de mémoire est attendue, vous pouvez envisager de remplacer le nombre de bits par 64. En règle générale, si vous modifiez le nombre de bits, vous devez également recompiler l’application.

La modification du nombre de bits ne réduit pas la quantité de mémoire utilisée. Cela permet au processus d’utiliser plus de 4 Go de mémoire totale. Toutefois, si la consommation de mémoire n’est pas celle attendue, vous pouvez utiliser cette fonctionnalité pour déterminer ce qui consomme la mémoire. Ensuite, vous pouvez effectuer une action pour contrôler la consommation de mémoire.

Dans la section « Description des fonctionnalités de débogage Azure App Service développée », vous pouvez voir le lien vers Réparation automatique dans la vignette Outils de diagnostic dans la première capture d’écran. Sélectionnez ce lien pour accéder directement à la fonctionnalité, ou sélectionnez la vignette et passez en revue tous les outils disponibles dans la page Outils de diagnostic . Pour plus d’informations, consultez la section « Réparation automatique » de Azure App Service diagnostics vue d’ensemble.

La fonctionnalité de réparation automatique est illustrée dans la capture d’écran suivante.

Lorsque vous sélectionnez la vignette Limite de mémoire , vous avez la possibilité d’entrer une valeur de mémoire qui déclenche la capture d’un vidage de mémoire en cas de dépassement de cette limite de mémoire. Par exemple, si vous entrez 6291456 comme valeur, une image mémoire du processus W3WP est effectuée lorsque 6 Go de mémoire sont consommés.

La fonctionnalité Collecter un vidage mémoire est utile dans ce scénario si le problème se produit actuellement ou est reproductible. Cette fonctionnalité collecte rapidement une image mémoire à la demande manuelle. Pour plus d’informations, consultez la section « Collecter une image mémoire ».

Descriptions des commandes développées

L’art de la collection de vidage de mémoire prend un certain temps à étudier, à expérimenter et à perfectionner. Comme vous l’avez appris, différentes procédures sont basées sur les symptômes affichés par le processus, comme indiqué dans le tableau de la section « Descriptions des scénarios de processus développés ». En revanche, le tableau suivant compare la commande de capture de vidage mémoire de l’Azure App Service à la commande procdump que vous exécutez manuellement à partir de la console Kudu.

Scénario	commande Azure App Service	Commande procdump générale
Ne répond pas ou lent	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -n 3 -s # <PID>`
Plantage (arrêt du processus)	Utilise DbgHost pour capturer l’image mémoire	`procdump -accepteula -ma -t <PID>`
Plantage (exceptions gérées)	Aucun (Application Insights)	`procdump -accepteula -ma -e 1 -f <filter> <PID>`
Blocage (exceptions non gérées)	Aucun (Débogueur de capture instantanée Application Insights)	`procdump -accepteula -ma -e <PID>`
Utilisation excessive du processeur	`procdump -accepteula -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -n 3 -s # -c 80 <PID>`
Consommation de mémoire excessive	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -m 2000 <PID>`

Les commandes que vous utilisez dans les fonctionnalités de capture de vidage mémoire dans Azure App Service différentes des commandes procdump que vous utiliseriez si vous capturez les images mémoire manuellement. Si vous passez en revue la section précédente, vous devez remarquer que la fonctionnalité du portail de collecte de vidage mémoire dans Azure App Service expose la configuration. Par exemple, dans le scénario de consommation de mémoire excessive dans le tableau, la commande exécutée par la plateforme ne contient pas de seuil de mémoire. Toutefois, la commande affichée dans la colonne de commande procdump générale spécifie un seuil de mémoire.

Un outil nommé DaaS (Diagnostics as a service) est chargé de gérer et de surveiller la configuration spécifiée dans le portail de débogage Azure App Service. Cet outil s’exécute en tant que travail web sur les machines virtuelles qui exécutent votre application web. L’un des avantages de cet outil est que vous pouvez cibler une machine virtuelle spécifique dans votre batterie de serveurs web. Si vous essayez de capturer une image mémoire à l’aide de procdump directement, il peut être difficile d’identifier, de cibler, d’accéder et d’exécuter cette commande sur un instance spécifique. Pour plus d’informations sur DaaS, consultez DaaS – Diagnostics as a service pour les sites web Azure.

L’utilisation excessive du processeur est une autre raison pour laquelle la plateforme gère la collection de vidages mémoire afin qu’elles correspondent aux modèles procdump recommandés. La commande procdump, comme indiqué dans le tableau précédent, collecte trois (-n 3) images mémoire complètes (-ma) séparées de 30 secondes (-s #, dont # 30) lorsque l’utilisation du processeur est supérieure ou égale à 80 pour cent (-c 80). Enfin, vous fournissez l’ID de processus (<PID>) à la commande : procdump -accepteula -ma -n 3 -s # -c 80 <PID>.

Vous pouvez voir la configuration du portail dans la section « Surveillance proactive de l’UC ». Par souci de concision, cette section n’a présenté que les trois premières options de configuration : Seuil du processeur (-c), Seuil en secondes (-s) et Fréquence du moniteur. La capture d’écran suivante montre que Configurer l’action, Actions maximales (-n) et Durée maximale sont des fonctionnalités supplémentaires disponibles.

Après avoir étudié les différentes approches de capture des images mémoire, l’étape suivante consiste à effectuer des captures. Vous pouvez utiliser des exemples de code sur GitHub conjointement avec des laboratoires de débogage IIS et des Azure Functions pour simuler chacun des scénarios répertoriés dans les deux tables. Après avoir déployé le code sur la plateforme Azure App Service, vous pouvez utiliser ces outils pour capturer le vidage mémoire dans chaque scénario donné. Au fil du temps et après la pratique, vous pouvez perfectionner votre approche de capture des vidages de mémoire à l’aide des fonctionnalités de débogage Azure App Service. La liste suivante contient quelques suggestions à prendre en compte lorsque vous continuez à en savoir plus sur la collecte de vidages mémoire :

La capture d’une image mémoire consomme des ressources système importantes et perturbe encore davantage les performances.
La capture des images mémoire à la première chance n’est pas optimale, car vous en capturerez probablement trop. Ces vidages mémoire de première chance ne sont probablement pas pertinents.
Nous vous recommandons de désactiver Application Insights avant de capturer une image mémoire W3WP.

Une fois le vidage de la mémoire collecté, l’étape suivante consiste à analyser le vidage de la mémoire pour déterminer la cause du problème, puis à corriger ce problème.

Étapes suivantes (analyse de l’image mémoire)

La façon d’analyser les vidages mémoire n’entre pas dans le cadre de cet article. Toutefois, il existe de nombreuses ressources pour ce sujet, telles que la série de formation Outils defragation et une liste de commandes WinDbg incontournables.

Vous avez peut-être remarqué l’option Configurer l’action dans la capture d’écran précédente. Le paramètre par défaut de cette option est CollectAndKill. Ce paramètre signifie que le processus est arrêté après la collecte de l’image mémoire. Un paramètre nommé CollectKillAndAnalyze analyse l’image mémoire collectée. Dans ce scénario, l’analyse de la plateforme peut trouver le problème afin que vous n’ayez pas à ouvrir l’image mémoire dans WinDbg et à l’analyser.

Il existe d’autres options pour résoudre et diagnostiquer les problèmes de performances sur la plateforme Azure App Service. Cet article se concentre sur la collecte de vidages mémoire et fait quelques recommandations pour aborder le diagnostic à l’aide de ces méthodes. Si vous avez déjà étudié, expérimenté et perfectionné vos procédures de collection et qu’elles fonctionnent bien pour vous, vous devez continuer à utiliser ces procédures.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.