Pourquoi IIS ne nettoie-t-il pas les anciens processus de travail (w3wp.exe) lors du recyclage du pool, ce qui conduit à une exception de site Web hors mémoire ?

Question

J'ai un site asp.net-mvc et depuis peu, je reçois des exceptions de mémoire insuffisante sur mon serveur web. Je n'ai qu'un seul pool d'applications et nous avons récemment configuré IIS pour qu'il se recycle après avoir atteint une certaine limite. L'autre jour, j'ai vu 4 processus w3wp.exe en cours d'exécution (chacun avec ~1.8GB de mémoire utilisée)

Je suppose que pendant le processus de recyclage, il ne tue pas l'ancien processus de travail et finalement j'obtiens des exceptions de manque de mémoire sur mon site Web parce que la boîte n'a que 8 Go de mémoire. Je peux ajouter de la mémoire au boîtier mais je me demande pourquoi ces anciens processus ne sont pas nettoyés.

Y a-t-il des recommandations pour comprendre pourquoi ce processus de recyclage ne tue pas les anciens processus w3wp.exe et les laisse fonctionner ? Des suggestions pour comprendre la cause profonde ou même des solutions de contournement pour éviter ce risque à l'avenir ?

Answer 1

Le recyclage du pool d'applications arrête généralement les anciens processus de travail, donc je ne pense pas qu'il s'agisse d'un bug de IIS.

Notez que les processus peuvent vivre plus longtemps s'ils deviennent orphelins, et selon la configuration, IIS doit les laisser là pour que vous puissiez les dépanner,

https://www.iis.net/configreference/system.applicationhost/applicationpools/add/failure

Si vous n'êtes pas familier avec le débogage de tels processus, je vous suggère d'ouvrir un dossier de support via http://support.microsoft.com et laissez les gars du support Microsoft vous aider.

Answer 2

J'ai eu un problème similaire lorsque j'exécutais des choses comme FFMpeg.exe ou une conversion PDF avec des graphiques WPF, le processus IIS ne s'arrêtait pas et émettait des erreurs de mémoire non trouvée. Le problème n'est pas avec IIS, mais certains blocages dans le processus qui bloque même après le crash.

La solution consiste à diviser votre site Web en deux sites distincts, dont l'un ne doit traiter que les transactions avec la base de données, qui ne subit généralement pas de pannes. La logique telle que la conversion de vidéos/photos, la conversion de PDF ou toute autre logique susceptible de provoquer des pannes doit être déplacée vers un autre service Web. Et utiliser l'appel HTTP de votre site Web en interne pour les traiter via les services Web.

Maintenant, dans ce cas, il n'y a toujours pas de moyen de contourner le plantage du processus de service Web, donc j'ai décidé de recycler le travailleur du pool d'applications toutes les 100 demandes (j'ai choisi ce nombre après avoir observé quelques demandes, en moyenne il ne dépassera 1GB qu'après avoir atteint 200 demandes) et j'ai transformé le pool d'applications en jardin Web en créant 4 processus par pool.

L'avantage de cette configuration est que vous pouvez déplacer votre processus de service web vers d'autres machines facilement à l'avenir, vous pouvez augmenter/diminuer le nombre de processus par pool. Et votre site Web principal, qui effectue simplement un processus de transaction, devient très réactif car il n'est pas affecté par les recycles de processus des services Web.

Answer 3

Le suspect principal que vous devriez rechercher est une classe qui implémente IDisposable et toute utilisation d'eux qui n'appelle pas Dispose() . J'ai eu un problème similaire, que j'ai déjà posté en réponse à la question suivante cette question .

La cause la plus probable est que vous n'appelez pas .Dispose() sur les connexions aux bases de données. Les gens ont tendance à se tromper à ce sujet, car le pool de connexion intégré à .NET fait que ressemble à vous ne devez pas éliminer les connexions. Cependant, l'appel à .Dispose() à la fin de la requête (ou lorsque vous avez fini d'utiliser la connexion) est exactement ce que vous devez faire pour éviter les fuites de ressources. Le pooling de connexion s'attend à ce que cela se produise.

Je ne pense pas que 4 w3wp.exe n'est pas un problème - il est normal qu'IIS génère plusieurs processus. Mais il est clair que votre application présente des fuites de ressources qui doivent être corrigées. Commencez par regarder IDisposable comme je l'ai mentionné ci-dessus. Si vous rencontrez toujours des problèmes, examinez les éléments que vous avez dans le cache et essayez de déterminer s'il existe une stratégie de mise en cache plus efficace que vous pourriez utiliser. Si tout le reste échoue, établissez le profil de l'application pour voir si vous pouvez localiser la source de la fuite de ressources. Il est fort probable que votre application devrait être mis en œuvre IDisposable quelque part, il ne l'est pas.

Answer 4

Comme il est clair dans votre message que paramétrer IIS pour qu'il se recycle après avoir atteint une certaine limite. est de créer un nouveau pool d'applications.

Il peut y avoir de multiples raisons pour que les personnes âgées ne soient pas licenciées.

Il peut s'agir d'une fuite de mémoire, qui ne permet pas de se débarrasser des ressources non gérées, ce que vous pouvez rechercher.

Pour trouver une autre raison, Activer le "Process Orphaning". dans IIS. Pour trouver le processus coupable, vous pouvez utiliser " Explorateur de processus ".

Vous avez également la possibilité de définir une Exécutable Il sera exécuté lorsqu'un processus est orphelin/abandonné.

Une solution immédiate peut aussi être de définir l'action de KillW3p après une certaine limite de CPU.

<applicationPools>
   <add name="DefaultAppPool">
     <cpu limit="80000" action="KillW3wp" resetInterval="00:02:00" />
   </add>
</applicationPools>