Résoudre les problèmes d’incidents de pool d’applications sur une machine virtuelle Services cloud
Cet article explique comment résoudre les incidents de pool d’applications sur une machine virtuelle dans Microsoft Azure Cloud Services. Si un pool d’applications se bloque, votre application cesse de répondre.
Étape 1 : Rechercher les erreurs dans les processus qui servent les pools d’applications
Dans observateur d'événements, si vous sélectionnezSystème de journaux> Windows dans l’arborescence de la console, vous pouvez voir l’un des événements suivants :
Un processus servant le pool d’applications « %1 » a subi une erreur de communication irrécupérable avec le service d’activation de processus Windows. L’ID de processus était « %2 ». Le champ de données contient le numéro d’erreur.
Un processus de service du pool d’applications « %1 » s’est arrêté de façon inattendue. L’ID de processus était « %2 ». Le code de sortie du processus était « %3 ».
Ces événements indiquent clairement un plantage du pool d’applications. Étant donné qu’un problème s’est produit au sein de l’application, le pool d’applications a dû être arrêté. Une fois le pool d’applications terminé, son processus dew3wp.exe correspondant est également arrêté. Toutes les informations basées sur le cache ou sur la session que vous avez enregistrées dans le processus dew3wp.exe seront effacées.
Étape 2 : Vérifier si le pool d’applications a été automatiquement désactivé en raison d’échecs de processus associés
Dans l’idéal, lorsqu’un pool d’applications se bloque, un nouveau processus w3wp.exe est généré automatiquement pour honorer les demandes entrantes. Toutefois, si le pool d’applications se bloque plus de cinq fois pendant une période de cinq minutes, le pool d’applications passe à l’état arrêté. Vous devez redémarrer le pool d’applications manuellement pour le rendre opérationnel. Si quelque chose de similaire se produit, vous observerez l’événement suivant sous les journaux système dans observateur d'événements :
Le pool d’applications « %1 » est automatiquement désactivé en raison d’une série d’échecs dans le ou les processus qui servent ce pool d’applications.
Vous pouvez configurer ces paramètres dans la boîte de dialogue Paramètres avancés de ce pool d’applications, sous la section Protection contre la défaillance rapide . La propriété Enabled a la valeur par défaut True. Si la propriété Enabled a la valeur True, le pool d’applications s’arrête une fois la limite d’échec atteinte dans un certain délai. La limite d’échec est représentée par la propriété Nombre maximal d’échecs . Cette propriété a une valeur par défaut de 5. L’intervalle de temps est représenté par la propriété Intervalle d’échec (minutes). Cette propriété a également la valeur par défaut 5.
Étape 3 : Capturer les fichiers de vidage du processus w3wp.exe
Une fois que vous avez déterminé que l’application s’est plantée, déterminez exactement pourquoi elle s’est bloquée. Vous devrez capturer un fichier de vidage du processus w3wp.exe juste avant qu’il ne se termine. Il existe de nombreuses façons de capturer ce fichier. Vous pouvez configurer Rapport d'erreurs Windows (WER), ProcDump et DebugDiag pour capturer un fichier de vidage sur incident. Cet article décrit uniquement la méthode DebugDiag de capture des données.
Pour télécharger et installer DebugDiag, procédez comme suit :
Accédez au site Outil de diagnostic de débogage v2 , puis sélectionnez Télécharger.
Pour Choisir le téléchargement souhaité, sélectionnez la version de fichier Microsoft Windows Installer (MSI) appropriée pour l’architecture de votre ordinateur, puis sélectionnez Suivant.
Ouvrez le fichier téléchargé. Dans l’Assistant Installation, acceptez les options par défaut, puis terminez l’installation de l’application.
Pour configurer l’application DebugDiag 2 Collection , procédez comme suit :
Sélectionnez Démarrer, entrez DebugDiag 2 Collection, puis ouvrez l’application nouvellement installée dans la liste des résultats.
Dans la boîte de dialogue Sélectionner le type de règle , sélectionnez l’option Blocage , puis sélectionnez Suivant.
Dans la boîte de dialogue Sélectionner le type de cible , sélectionnez l’option Un pool d’applications web IIS spécifique , puis sélectionnez Suivant.
Dans la boîte de dialogue Sélectionner une cible , sélectionnez le pool d’applications spécifique qui se bloque, puis sélectionnez Suivant. Si une fenêtre s’ouvre et indique que la gestion des services Internet (IIS) n’est pas installée et que les pools d’applications ne sont pas répertoriés, sélectionnez OK, puis entrez le nom de l’application manuellement.
Dans la boîte de dialogue Configuration avancée (facultatif), sélectionnezPoints d’arrêt> Ajouter un point d’arrêt.
Effectuez les sélections suivantes pour créer un point d’arrêt, puis sélectionnez OK.
Champ Description Valeur Offset Expression Processus de capture Ntdll !ZwTerminateProcess Type d'action Type de vidage capturé Userdump complet Limite d’action Nombre de vidages à capturer 10 Dans la boîte de dialogue Configurer les points d’arrêt, vérifiez que le nouvel élément Expression de point d’arrêt est affiché. Sélectionnez Enregistrer & Fermer pour revenir à la boîte de dialogue Configuration avancée (facultatif), puis sélectionnez Suivant pour activer le point d’arrêt.
Dans la boîte de dialogue Sélectionner l’emplacement de vidage et le nom de la règle (facultatif), entrez un nom de règle, puis remplacez l’emplacement userdump par un lecteur et un répertoire disposant de suffisamment d’espace disque libre, si nécessaire. (La taille de chaque fichier de vidage correspond à ce qui est consommé par le processus w3wp.exe en mémoire.)
Sélectionnez Suivant.
Pour activer la règle, sélectionnez Terminer.
À présent, la règle d’incident est dans un état actif et le nombre d’utilisateurs est 0. Lorsque le problème se produit, le nombre de vidages augmente immédiatement et un fichier de vidage correspondant est généré.
Remarque
Un recyclage normal du pool d’applications peut également déclencher un fichier de vidage. Cela se produit parce que, lors du recyclage, l’ID de processus (PID) dew3wp.exe correspondant du pool d’applications change. Cela génère un fichier de vidage. Ce fichier est un faux positif. Par conséquent, cela ne vous aidera pas à analyser l’incident du pool d’applications. Chaque fois que vous voyez un incrément dans le nombre de userdump, case activée les journaux des événements pour voir si les événements d’incident attendus se sont produits. Si les événements sont comme prévu, le vidage capturé est correct.
Étape 4 : Analyser les fichiers de vidage du processus w3wp.exe
Une fois le fichier de vidage capturé, vous pouvez ouvrir Démarrer l’analyse>DebugDiag 2. Cette application vous permet d’analyser le fichier de vidage sur incident capturé.
Vérifiez que le chemin du symbole est correctement défini. Il s’agit d’un processus en deux parties. Dans Déboguer AnalysisDiag 2, sélectionnez Paramètres (icône d’engrenage). Sous Chemins de recherche de symboles à utiliser pour l’analyse, vérifiez que _NT_SYMBOL_PATH et les serveurs de symboles publics Microsoft sont sélectionnés .
Rouvrez La collection DebugDiag 2, puis sélectionnez Outils>Options et paramètres. Ensuite, dans la boîte de dialogue Options & Paramètres, vérifiez que la zone Symbole Recherche Chemin d’accès pour le débogage (par exemple, Règles d’incident) est définie sur srv*c :\symcache*https://msdl.microsoft.com/download/symbols. Ce chemin d’accès permet à DebugDiag de télécharger les symboles selon les besoins à partir du serveur de symboles publics Microsoft, puis de les stocker dans le répertoire c :\symcache .
Après avoir modifié ou vérifié vos paramètres de chemin d’accès de symbole, vous pouvez analyser les fichiers de vidage capturés. Pour démarrer l’analyse, revenez à DéboguerDiag 2 Analyse, puis double-cliquez sur le nom d’un fichier de vidage. Une fois le rapport généré, vous pouvez l’ouvrir dans le navigateur et comprendre la pile des appels du thread qui a déclenché l’expression de point d’arrêt. Lisez la pile des appels de bas en haut, puis déterminez la méthode ou le composant qui a déclenché le blocage du pool d’applications. Si vous ne trouvez pas de pile d’appels d’exception précise, examinez plus en détail la pile des appels .NET dans la même analyse de fichier de vidage.
Étape 5 : Rechercher les exceptions non gérées dans le processus w3wp.exe ou WaWorkerHost.exe
Pour case activée également les exceptions non gérées qui ont provoqué l’arrêt du processusw3wp.exe ou WaWorkerHost.exe, consultez Exceptions non gérées à l’origine d’ASP. Les applications basées sur NET doivent être interrompues de manière inattendue dans le .NET Framework.
Exclusion de responsabilité de tiers
Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.
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.