Quelles mesures puis-je prendre pour réparer les accidents du pool d'applications IIS?

Vérifiez la visionneuse d'événements pour les détails du crash en recherchant les ID d'événements 1000, 1001 ou 1009 sous les journaux du système et des applications pour identifier les exceptions ou les modules défectueux. 2. Activer le traçage des demandes d'échec (FREB) dans IIS Manager pour capturer les journaux de demande détaillés et identifier les demandes ou modules problématiques. 3. Examiner les paramètres du pool d'applications, y compris les configurations de recyclage, la protection rapide et les autorisations d'identité pour exclure les erreurs de configuration. 4. Surveiller la mémoire et gérer l'utilisation via le gestionnaire de tâches ou le moniteur de performances, et utilisez Debugdiag ou ProcDump pour analyser les vidages de mémoire si les fuites sont suspectées. 5. Isoler les problèmes en désactivant les modules tiers, en testant avec une page minimale et en vérifiant les exceptions non perdues, des boucles infinies ou des appels natifs instables dans le code. 6. Assurez-vous que le système, le framework .NET et tous les composants sont mis à jour vers les dernières versions pour résoudre les bogues connus. 7. Configurer les vidages de crash à l'aide de Windows Error Reporting ou Debugdiag pour capturer automatiquement les vidages de mémoire complète lors de l'échec pour l'analyse profonde. 8. Après la résolution, surveillez le pool d'applications à l'aide d'un moniteur de performance et définissez des alertes pour éviter la récidive, en considérant la mise à l'échelle si la pression des ressources persiste. Suivre ces étapes permet systématiquement un diagnostic précis et une résolution des accidents de pool d'applications IIS, les journaux et traces du système fournissant des indices critiques sur la cause profonde.

Les accidents de pool d'applications IIS peuvent perturber vos applications Web et conduire à des temps d'arrêt. Les réparer implique d'identifier la cause profonde, qui découle souvent de problèmes de configuration, d'erreurs de code ou de limitations de ressources. Voici des étapes pratiques que vous pouvez prendre pour diagnostiquer et résoudre ces accidents:

1. Vérifiez la visionneuse d'événements pour les détails du crash

La première étape consiste à examiner la visionneuse de l'événement Windows pour identifier ce qui a causé le crash.

• Visionneuse à événement ouvert (eventvwr.msc)
• Accédez à Windows Logs> Système et application
• Recherchez l'identifiant de l'événement 1000, 1001 ou 1009 liés à "Application Pool", "w3wp.exe" ou "iis-w3svc"
• Ces journaux incluent souvent des codes d'exception (par exemple, 0xc00000fd pour le débordement de pile) ou des noms de modules qui se sont écrasés

CONSEIL: Faites attention aux entrées de l' erreur d'application ou des sources IIS-W3SVC-WP .

2. Activer et analyser le traçage de la demande échoué (FREB)

Échec du traçage des demandes (FREB) aide à capturer des journaux détaillés pour des demandes spécifiques qui peuvent déclencher des accidents.

• Dans IIS Manager, allez sur votre site ou votre application
• Open Règles de traçage de la demande échoue
• Créez une nouvelle règle pour tracer les codes d'état comme 500 , ou définissez-le pour tracer toutes les demandes de dépannage
• Reproduisez le problème et vérifiez les fichiers de journal XML générés dans Inetpub\logs\FailedReqLogFiles

Cela peut révéler des modules problématiques, des boucles infinies ou des demandes mal formées.

3. Revoir les paramètres du pool de candidatures

Les pools d'applications mal configurés sont une cause courante d'instabilité.

• Paramètres de recyclage : le recyclage fréquent peut ressembler à un crash. Passez en revue les paramètres de recyclage dans le pool d'applications> Recyclage.

  • Désactiver temporairement les recycles prévus pour les exclure
  • Vérifiez si le recyclage est déclenché par des limites de mémoire

• Protection rapide : si elle est activée, le pool d'applications s'arrête après un certain nombre de plantages dans une fenêtre de temps.

  • Réinitialisez-le en redémarrant la piscine
  • Envisagez d'augmenter le seuil de comptage de défaillance ou de le désactiver temporairement pendant le dépannage

• Identité et autorisation :

  • Assurez-vous que l'identité du pool d'applications (par exemple, ApplicationPoolIdentity) a des autorisations appropriées de système de fichiers et de registre
  • Essayez de passer temporairement à un compte de travail connu (par exemple, localSystem) pour les tests

4. Vérifiez les fuites de mémoire et manipulez les fuites

Les applications .NET ou les modules natifs avec des fuites de mémoire peuvent épuiser les ressources et écraser le processus de travail.

• Utilisez le gestionnaire de tâches ou le moniteur de performance à surveiller:
  • Octets privés
  • Octets virtuels
  • Poigrés Count
• Si la mémoire ou les poignées se développent en continu, vous avez probablement une fuite
• Utilisez des outils comme:
  • Debugdiag (outil de diagnostic de débogage) pour capturer et analyser les vidages de mémoire
  • ProcDump ( procdump -ma -l w3wp.exe ) pour générer des vidages sur le crash

Après avoir capturé un vidage, ouvrez-le dans Windbg ou Visual Studio pour inspecter les piles d'appels et l'utilisation des objets.

5. Isoler le code ou les modules problématiques

Les modules tiers ou le code défectueux peuvent réduire l'ensemble du processus.

• Désactiver les modules IIS non essentiels dans web.config ou IIS Manager
• Supprimer temporairement les modules ou les gestionnaires HTTP personnalisés
• Testez en déploiement d'une page minimale "Hello World" - si cela fonctionne, le problème est dans votre code d'application
• Pour les applications .NET, vérifiez:
  • Exceptions non gérées dans Application_Error ou Global.asax
  • Boucles infinies ou récursion profonde
  • P / Invoquez des appels à des DLL indigènes instables

6. Mettre à jour et patch

Assurez-vous que votre système est à jour:

• Installez les dernières mises à jour Windows
• Mettre à jour .NET Framework au dernier niveau de correctif
• Mettez à jour les composants tiers (par exemple, les bibliothèques forestières, les filtres ISAPI)

Certains plantages sont causés par des bogues connus fixés dans les mises à jour.

7. Configurer des vidages de crash pour une analyse plus approfondie

Configurez la génération automatique du vidage de mémoire lorsque W3wp.exe se bloque.

• Utilisez Windows Error Reporting (WER) ou Debugdiag pour configurer la création de vidage
• Méthode de registre (avancé):
  • Créez une clé Wer sous HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe
  • Définir DumpFolder , DumpCount et DumpType (2 = Full Dump recommandé)

Analysez plus tard le vidage pour le type d'exception, la pile d'appels et le module défectueux.

8. Surveillez et empêchez les récidives

Une fois fixe, surveillez le pool d'applications:

• Utilisez des performances pour suivre les taux de processeur, de mémoire et de demande
• Configurer des alertes pour une utilisation élevée de la mémoire ou des recycles fréquents
• Envisagez d'équilibrer ou d'équilibrer si la pression des ressources est cohérente

La réparation des accidents de pool d'applications IIS se résume généralement à réduire la cause à travers les journaux, les vidages et les tests systématiques. Commencez par la visionneuse d'événements, éliminez les problèmes de configuration, puis creusez dans le code ou les problèmes de mémoire si nécessaire. La plupart des problèmes sont reproductibles dans les bonnes conditions - la patience et les tests méthodiques sont essentiels.

Fondamentalement, suivez le sentier que le système laisse derrière - il sait généralement ce qui ne va pas.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!