w3wp se bloque parfois sur le recyclage de nuit

J'ai rencontré un problème avec notre application ASP.NET où parfois un cas de recyclage tous les soirs le w3wp à suspendre.w3wp se bloque parfois sur le recyclage de nuit

Voici ce qui se passe:

Recycle est déclenchée. évidemment, cela force ThreadAbortException sur tous les threads en cours d'exécution. Cependant, cela ne semble pas déclencher un nouveau w3wp, ou c'est le nouveau w3wp qui lance réellement l'exception (qui n'a pas encore été capable de le reproduire).

Dans mes journaux, je reçois beaucoup de ThreadAbortException, et le nombre de threads monte et monte indéfiniment, ce qui signifie que toute nouvelle requête engendre un nouveau thread qui ne finit jamais. Si cela aurait été l'ancien w3wp, toute nouvelle requête serait routée vers le w3wp nouvellement démarré. Le délai d'arrêt et la protection contre les défaillances rapides ne semblent pas non plus se déclencher, ce qui rend l'unité inaccessible jusqu'à ce qu'elle soit recyclée manuellement. La plupart du temps, il consomme aussi beaucoup de CPU, ce qui rend le serveur pratiquement inutilisable.

Nous utilisons Monorail MVC qui n'a probablement rien à voir avec cela, mais nous utilisons leur système RescueController. Si nous devons attraper involontairement le ThreadAbortException dans notre gestion des erreurs, cela pourrait-il causer une boucle infinie qui bloquerait tellement le w3wp que IIS ne pourrait pas en récupérer?

Source

2011-07-28 jishi

Vous pouvez vous assurer que vous consignez tous les événements de recyclage. À partir de PowerShell: 'set-webconfigurationproperty /system.applicationHost/applicationPools/applicationPoolDefaults/recycling -name: logEventOnRecycle -value:" Heure, demandes, calendrier, mémoire, IsapiUnhealthy, OnDemand, ConfigChange, PrivateMemory "' –

IIS ne parvient pas à démarrer un nouveau processus de travail avec succès en raison d'une contrainte de ressource, probablement en raison d'un manque de mémoire disponible. Essayez d'ajuster votre limite de mémoire privée dans IIS, en diminuant le nombre de processus de travail maximum appelés Web Garden (le définir rarement à plus de 1 - s'il est plus élevé que le problème sous-jacent à résoudre), en augmentant la RAM physique disponible sur vos serveurs, appelant Marshal.ReleaseComObject de manière appropriée, et triant autrement ce qui empêche la libération de la mémoire. Vous pouvez même envisager de changer le mode de récupération de place du serveur vers le poste de travail (voir http://msdn.microsoft.com/en-us/library/ms229357.aspx).

Source

2011-08-16 01:43:32

Merci beaucoup pour l'entrée . Nous n'utilisons pas de jardin web, cela ne devrait donc pas poser de problème. L'allocation de mémoire limitée semble plausible, je vais m'y pencher. En ce qui concerne le mode de collecte des ordures du serveur, n'était pas au courant qu'il existe deux modes différents. Il s'agit d'une machine quad-core double (8 au total) mais elle exécute plusieurs sites. Quels sont les avantages et les inconvénients des deux modes? Il semble que la collecte simultanée des ordures est une bonne chose? – jishi

Avant de passer aux modes de collecte des ordures, assurez-vous de profiler votre application pour mieux caractériser le problème que vous voyez. Exécutez Analyseur de performances ("% windir% \ system32 \ perfmon.msc/s"), lisez cet article pour vous aider à identifier les compteurs de performance à surveiller. Des outils tels que CLRProfiler (http://msdn.microsoft.com/en-us/library/ff650691.aspx) peuvent vous aider. Si la preuve continue ensuite à pointer vers la mémoire et la récupération de place, consultez ce thread OS: http: // stackoverflow.com/questions/4931309/comment-faire-net-garbage-collection-moins-fréquent –

Mon problème principal avec ceci est que c'est seulement dans l'environnement de production que j'ai remarqué ce comportement, et je n'ai pas accès à ceux les serveurs. En regardant les graphiques de mémoire que nous avons pour les serveurs, je ne vois pas de baisse directe de la mémoire disponible pendant le temps de recyclage, bien qu'ils le surveillent à intervalles de 5 min. Cependant, le serveur est généralement arrêté environ 30 minutes avant un redémarrage manuel, donc pendant ce temps, il devrait être très faible, je suppose, selon les graphiques que j'ai encore environ 3 Go disponibles (sur 16 Go) – jishi

Il s'avère que nous avons eu une boucle de tentative try récursive pour Exception, qui récupère ThreadAbortException et s'invoque elle-même en raison de l'héritage, elle est donc devenue une récursion infinie.

Nous avions la capture pour Exception parce que nous voulions la journalisation et une gestion des erreurs, et serait probablement bien dans tous les autres aspects sauf que ThreadAbortException continuera à lancer pendant l'exécution.

Source

2011-11-22 10:26:54 jishi

Ce n'était pas ça. – jishi

qu'était-ce alors? –

@JasonCoyne Je ne pense pas que nous soyons allés au fond des choses. Nous avons effectué quelques optimisations de démarrage pour réduire la charge de démarrage que nous voyions, et nous avons finalement basculé vers Win2012, ce qui a peut-être amélioré les choses. – jishi

w3wp se bloque parfois sur le recyclage de nuit

Répondre

Questions connexes