Capturer des vidages de mémoire sur la plateforme Azure App Service

Article
11/20/2024

Cet article fournit des conseils sur les fonctionnalités de débogage de Microsoft Azure App Service pour capturer des vidages de mémoire. La méthode de capture que vous utilisez est dictée par le scénario dans lequel vous capturez un vidage de 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 excessive de mémoire 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 des scénarios de vidage de 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 un vidage de mémoire. Il existe tellement d’approches pour capturer un vidage de mémoire que le processus peut prêter à confusion. Si vous maîtrisez déjà la capture d’un vidage de 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	Fonctionnalité de débogage Azure App Service	Commande
Ne répond pas ou ralentit	Réparation automatique (durée de la requête)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`
Incident (arrêt du processus)	Surveillance des incidents	Utilise DbgHost pour capturer un vidage de mémoire
Incident (exceptions gérées)	Traces dans Application Insights/Log Analytics	Aucun(e)
Blocage (exceptions non gérées)	Débogueur de capture instantanée d’Application Insights	Aucun(e)
Utilisation excessive du processeur	Surveillance proactive du processeur	`procdump -accepteula -dc "Message" -ma <PID> <PATH>`
Consommation excessive de mémoire	Réparation automatique (limite de mémoire)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`

Note

Nous avons une recommandation secondaire pour capturer un vidage de mémoire de processus W3WP dans le scénario non réponse ou lent. Si ce scénario est reproductible et que vous souhaitez capturer immédiatement le vidage, vous pouvez utiliser l’outil de diagnostic Collecter un vidage mémoire. Cet outil se trouve dans la page Diagnostiquer et résoudre les problèmes de l’application web App Service donnée dans le Portail Azure. Un autre emplacement pour rechercher des exceptions générales et des performances médiocres se trouve sur la page Journaux des événements d’application. (Vous pouvez également accéder aux journaux d’activité d’application à partir du Diagnostiquer et résoudre les problèmes page.) 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 non répond ou lent

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

Un scénario non répond peut être permanent (et susceptible d’expirer) ou lent. Par conséquent, le scénario de non réponse est un scénario dans lequel une demande 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. En fait, si vous voyez des métriques de performances qui indiquent la lenteur, ou un super utilisateur indique que le serveur répond plus lentement que la normale, vous avez un scénario sans réponse ou lent.

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

Depuis de nombreuses 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 terminé le 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 pile peuvent arrêter le 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 sous 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 qui est interceptée dans le bloc catch correspondant. Dans ce cas, le développeur a prévu qu’une exception pouvait se produire et 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 afin que le problème puisse être reproduit et, finalement, résolu. Les exceptions sont des chemins de code coûteux en termes de performances. Par conséquent, la présence 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 crash (arrêt du processus), ce code n’est pas contenu dans un bloc de code try-catch. Dans ce cas, le développeur ne s’attendait pas à ce qu’une exception se produise dans cette section de code.

Ce scénario diffère des deux scénarios d’exception précédents. Dans le scénario Crash (exceptions non gérées), le code en question est le code que le développeur a écrit. Ce n’est pas le code d’infrastructure qui lève l’exception, et ce n’est pas l’une des exceptions non gérées qui tue le processus de w3wp.exe . En outre, étant donné que le code qui lève une exception n’est pas dans un bloc try-catch, il n’existe aucune possibilité de gérer l’exception correctement. La résolution des problèmes du code est initialement un peu plus complexe. Votre objectif consiste à rechercher le texte, le type et la pile d’exceptions qui identifient 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 consigner les détails des exceptions qui doivent exister dans le scénario crash (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 de w3wp.exe est de 80 pour cent, votre application est dans une situation critique qui peut provoquer différents symptômes. Certains symptômes possibles sont les suivants :

Lenteur
Erreurs
Autre comportement non défini

Même une utilisation de l’UC de 20 % 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 excessif du processeur en générant un vidage de mémoire ne vous aidera probablement pas à déterminer la méthode spécifique qui l’utilise. Le meilleur que vous pouvez faire consiste à déterminer les demandes qui ont probablement pris le plus de temps, puis à 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é cette rafale. Dans de nombreux cas, vous pouvez provoquer des problèmes de performances en ayant des moniteurs exécutés en temps réel.

Scénario de consommation excessive de mémoire

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 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 excessive de mémoire dépend des facteurs suivants :

Bitness du processus (32 bits ou 64 bits)
Quantité d’utilisation de la mémoire considérée comme « normale ».

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

Maintenant que vous avez un peu plus de contexte sur les différents scénarios de processus qu’un vidage de mémoire peut vous aider à résoudre les problèmes, nous aborderons l’outil recommandé pour capturer des 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 destinées à collecter des vidages de mémoire. Chacune de ces fonctionnalités est accessible à partir du 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 requête)

La fonctionnalité de réparation automatique (durée de requête) est utile pour capturer un vidage de mémoire si la réponse prend plus de temps que prévu. Vous pouvez voir le lien vers la 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 s’affiche dans la capture d’écran suivante.

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

Collecter une fonctionnalité de vidage de mémoire

Pour comprendre la configuration de la fonctionnalité Collecter un vidage de mémoire, consultez Collecter les services d’application de vidage de 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 le vidage de la mémoire. Sélectionnez ensuite l’instance de serveur à partir de laquelle vous souhaitez collecter le vidage de la mémoire. Si vous avez plus d’une seule instance, vérifiez que le problème que vous déboguez se produit sur cette instance. Notez qu’un redémarrage peut ne pas être optimal sur une application de production en cours d’opération.

Fonctionnalité de surveillance des incidents

La fonctionnalité surveillance des incidents est utile pour capturer un vidage de mémoire si une exception non gérée entraîne l’arrêt du processus W3WP. La capture d’écran suivante montre la page Surveillance des incidents dans Les outils de diagnostic :

Pour afficher une procédure pas à pas guidée sur la configuration de la fonctionnalité de surveillance des incidents dans Azure App Service, consultez Surveillance 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 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 requis pour rechercher 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 à poser des questions sur ces types d’exceptions et les attributs nécessaires à la capture pour analyser les causes racines.

La meilleure approche pour ajouter cette fonctionnalité à votre code d’application dépend de la pile de codes 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, passez en revue la journalisation 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 d’instantané 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 ne nécessite pas d’ajouter de 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 d’application 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 en toute sécurité que la fonctionnalité Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware contient du code pour intercepter cette exception non gérée afin que l’arrêt du processus soit évité. 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 par rapport aux journaux des événements d’application.

Fonctionnalité de surveillance proactive du processeur

Pendant des scénarios d’utilisation excessive du processeur, vous pouvez utiliser l’outil de supervision 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 du processeur dans Outils de diagnostic.

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

Seuil du processeur
Seuil secondes
Fréquence de surveillance

Le seuil du processeur identifie la quantité d’UC de l’ordinateur utilisée par le processus ciblé (W3WP dans ce cas). Le seuil des secondes est la durée pendant laquelle l’UC a été utilisée au seuil du processeur. Par exemple, s’il existe 75 % d’utilisation du processeur pendant un total de 30 secondes, le vidage de la mémoire est capturé. Comme configuré sur la page Surveillance proactive du processeur, le processus est vérifié pour 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 un vidage de mémoire si le processus consomme plus de mémoire que prévu. Là encore, faites attention à la bitness (32 ou 64). Si vous rencontrez une pression de mémoire dans le contexte de processus 32 bits et que la consommation de mémoire est attendue, vous pouvez envisager de modifier la quantité de bits en 64. En règle générale, si vous modifiez le bit, vous devez également recompiler l’application.

La modification du bit 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 comme prévu, 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 « Descriptions des fonctionnalités de débogage Azure App Service étendues », vous pouvez voir le lien vers la 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, accédez à la section « Réparation automatique » de la vue d’ensemble des diagnostics Azure App Service.

La fonctionnalité de réparation automatique s’affiche 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 lorsque cette limite de mémoire est violée. Par exemple, si vous entrez 6291456 comme valeur, un vidage de mémoire du processus W3WP est pris lorsque 6 Go de mémoire sont consommés.

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

Descriptions des commandes développées

L’art de la collection de vidages mémoire prend un certain temps pour étudier, expérimenter et parfait. 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 d’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 ralentit	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -n 3 -s # <PID>`
Incident (arrêt du processus)	Utilise DbgHost pour capturer le vidage de mémoire	`procdump -accepteula -ma -t <PID>`
Incident (exceptions gérées)	Aucun (Application Insights)	`procdump -accepteula -ma -e 1 -f <filter> <PID>`
Blocage (exceptions non gérées)	Aucun (débogueur d’instantané 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 excessive de mémoire	`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 de mémoire dans Azure App Service diffèrent des commandes procdump que vous utiliseriez si vous capturez manuellement des vidages. Si vous passez en revue la section précédente, vous devez remarquer que la fonctionnalité du portail de collecte de vidage de mémoire dans Azure App Service expose la configuration. Par exemple, dans le scénario de consommation excessive de mémoire dans la table, 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 commandes procdump générale spécifie un seuil de mémoire.

Un outil nommé DaaS (Diagnostics en tant que service) est responsable de la gestion et de la supervision de 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 un vidage de 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 une instance spécifique. Pour plus d’informations sur DaaS, consultez DaaS – Diagnostics en tant que service pour les sites web Azure.

Une utilisation excessive du processeur est une autre raison pour laquelle la plateforme gère la collecte de vidage de mémoire afin qu’elle corresponde aux modèles de processus recommandés. La commande procdump, comme indiqué dans le tableau précédent, collecte trois (-n 3) vidages de mémoire complète (-ma) 30 secondes d’écart (-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 du processeur ». Pour des raisons de concision, cette section n’a montré que les trois premières options de configuration : seuil du processeur (-c), seuil secondes (-s) et fréquence de surveillance. La capture d’écran suivante montre que Configurer l’action, les actions maximales (-n) et la durée maximale sont des fonctionnalités supplémentaires disponibles.

Après avoir étudié les différentes approches de capture des vidages de mémoire, l’étape suivante consiste à effectuer des captures. Vous pouvez utiliser des exemples de code sur GitHub conjointement avec les laboratoires de débogage IIS et 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 de la mémoire dans chaque scénario donné. Au fil du temps et après la pratique, vous pouvez perfectionner votre approche pour capturer 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 vidage de mémoire :

La capture d’un vidage de mémoire consomme des ressources système importantes et interrompt encore davantage les performances.
La capture des vidages de mémoire sur la première chance n’est pas optimale, car vous capturerez probablement trop de mémoire. Ces vidages de mémoire de première chance ne sont probablement pas pertinents.
Nous vous recommandons de désactiver Application Insights avant de capturer un vidage de 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 du vidage de la mémoire)

La façon d’analyser les vidages de mémoire est en dehors de l’étendue de cet article. Toutefois, il existe de nombreuses ressources pour ce sujet, telles que la série d’entraînement Defrag Tools et une liste de commandes WinDbg à connaître.

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 tué après la collecte du vidage de la mémoire. Un paramètre nommé CollectKillAndAnalyze analyse le vidage de mémoire collecté. Dans ce scénario, l’analyse de la plateforme peut trouver le problème afin que vous n’ayez pas à ouvrir le vidage de 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 vidage de mémoire et fournit des recommandations pour aborder le diagnostic à l’aide de ces méthodes. Si vous avez déjà étudié, expérimenté et parfait vos procédures de collection, et qu’ils 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.

Partager via