Pourquoi IIS ne nettoie-t-il pas les anciens processus de travail (w3wp.exe) lors du recyclage du pool, ce qui entraîne une exception de mémoire insuffisante pour le site Web?
J'ai un site asp.net-mvc et récemment, je reçois une exception de mémoire insuffisante sur mon serveur Web. Je n'ai qu'un seul pool d'applications et nous avons récemment défini IIS à recycler après qu'il atteigne une certaine limite. Je suis allé l'autre jour et j'ai vu 4 processus w3wp.exe en cours d'exécution (chacun avec environ 1,8 Go de mémoire utilisé)
Je suppose que pendant le processus de recyclage, cela ne tue pas l'ancien processus de travail et finalement je sors des exceptions de mémoire sur mon site Web car la boîte n'a que 8 Go de mémoire. Je peux ajouter de la mémoire à la boîte, mais je me demande pourquoi ces anciens processus ne sont pas nettoyés.
Existe-t-il des recommandations pour comprendre pourquoi ce processus de recyclage ne tue pas les anciens processus w3wp.exe et les laisse en cours d'exécution? Avez-vous des suggestions pour comprendre à la fois la cause profonde ou même les solutions de contournement pour éviter ce risque à l'avenir?
J'ai eu un problème similaire lorsque j'exécutais des choses comme FFMpeg.exe ou une conversion PDF avec les graphiques WPF, IIS ne s'arrêtera pas et émettrait de la mémoire non Le problème n'est pas lié à IIS, mais à certains blocages dans le processus qui se bloquent même après un plantage.
La solution de contournement consiste à diviser votre site Web en deux sites Web distincts, l'un ne devrait effectuer le traitement des transactions qu'avec une base de données qui n'a généralement pas de plantages. La logique comme la conversion vidéo/photo, la conversion PDF, ou toute autre logique pouvant provoquer un crash doit être déplacée vers un autre service Web. Et utilisez 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 aucun moyen de contourner le plantage du processus de service Web, j'ai donc décidé de recycler le travailleur du pool d'applications toutes les 100 demandes (j'ai choisi ce nombre après avoir regardé quelques demandes, en moyenne, il dépasserait 1 Go seulement après 200 requêtes) et j'ai transformé le pool d'applications en Web Garden en créant 4 processus par pool.
L'avantage de cette configuration est que vous pouvez facilement déplacer votre processus de service Web vers d'autres machines à 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 recyclages de processus des services Web.
Le recyclage du pool d'applications arrête généralement les anciens processus de travail, donc je ne pense pas que vous rencontriez un bogue d'IIS.
Notez que les processus peuvent vivre plus longtemps s'ils deviennent orphelins, et en fonction de 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 de laisser les techniciens du support Microsoft vous aider.
Le principal suspect à rechercher est les classes qui implémentent IDisposable et toute utilisation de celles-ci qui n'appelle pas Dispose(). J'ai eu un problème similaire, que j'ai déjà publié en réponse à cette question .
La cause la plus probable est que vous n'appelez pas .Dispose() sur les connexions à la base de données. Les gens ont tendance à être confus à ce sujet car le pool de connexions intégré de .NET fait sonner comme vous ne devez pas supprimer les connexions. Cependant, appeler .Dispose() à la fin de la demande (ou lorsque vous avez fini d'utiliser la connexion) est exactement ce que vous devez faire pour éviter les fuites de ressources. Le pool de connexions s'attend à ce que cela se produise.
Je ne pense pas que 4 w3wp.exe les processus sont très préoccupants - il est normal que IIS génère plusieurs processus. Mais il est clair que votre application a des fuites de ressources qui doivent être corrigées. Commencez par regarder IDisposable comme je l'ai mentionné ci-dessus. Si vous avez toujours des problèmes, jetez un œil aux é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, profilez l'application pour voir si vous pouvez localiser la source de la fuite de ressources. Votre application devrait implémenter IDisposable quelque part où ce n'est pas le cas.
Comme il ressort clairement de votre message que définir IIS à recycler après avoir atteint une certaine limite crée une nouvelle application bassin.
Il peut y avoir plusieurs raisons pour lesquelles les anciens ne se terminent pas.
L'une peut être une fuite de mémoire, ne pas éliminer les ressources non gérées, vous pouvez le rechercher.
Pour découvrir une autre raison, Activez "Process Orphaning" dans IIS. Pour découvrir le processus coupable, vous pouvez utiliser " Process Explorer ".
Vous avez également la possibilité de définir un exécutable , cela sera exécuté lorsqu'un processus est orphelin/abandonné.
La solution immédiate peut également consister à définir l'action sur KillW3p après une certaine limite de CPU.
<applicationPools>
<add name="DefaultAppPool">
<cpu limit="80000" action="KillW3wp" resetInterval="00:02:00" />
</add>
</applicationPools>