3

Considérons une application ASP.NET avec un problème de fuite de mémoire de pool de connexions (lorsque les connexions ne sont pas fermées correctement, par exemple).Pool d'applications IIS et récupération de place .NET

Le recyclage du pool d'applications efface-t-il le pool de connexions (permettant ainsi d'effectuer davantage de connexions)?

Si les connexions sont laissées en mémoire jusqu'à ce que le Garbage Collector les supprime, cela se produit-il lorsque le pool d'applications est redémarré (ou sont/peuvent-ils rester au-delà)? Je comprends également que le garbage collector peut les nettoyer à tout moment, mais est-il encore utilisé et impossible à collecter jusqu'à la réinitialisation ou le redémarrage du pool d'applications? Je passe en revue un système où l'objectif final est évidemment d'avoir le code corrigé pour gérer les connexions correctement, et j'essaie de mieux comprendre le processus de récupération de place/pool d'applications.

Répondre

5

Oui, le recyclage du pool d'applications tue et redémarre le processus IIS responsable de l'exécution de votre application. Toutes les ressources sont libérées à ce stade, simplement parce que le processus est en cours de fermeture.

Si le processus n'est jamais redémarré et qu'il fuit simplement les poignées, le garbage collector finira par les nettoyer. Cependant, il est probable que vous ne disposerez plus de poignées pour toute ressource qui fuit avant que cela se produise. C'est pourquoi il est important d'appeler Dispose() sur ces objets (de préférence par le modèle "using") afin que les ressources soient libérées dès que l'application est faite avec elles et non quand le ramasse-miettes se déplace.

1

Un pool de connexions est un cache de connexions à une base de données. Un pool d'applications est un (ou plusieurs) processus de travail. Ainsi, lorsque vous fermez le pool d'applications, vous arrêtez vos processus de travail et vous lancez de nouveaux processus de travail. cela entraînera la destruction du pool et la fermeture de toutes les connexions du pool de connexions.

Si vous n'appelez pas Close ou Dispose sur une connexion et que vous utilisez le garbage collector, la connexion peut être renvoyée ou non au pool. Je pense qu'il ne sera ajouté au pool que si la connexion est toujours valide et que la taille maximale du pool a été atteinte. Comme vous le savez probablement, vous ne devriez jamais compter sur le garbage collector pour cela. Un moyen facile de s'assurer que la connexion est Disposée est d'utiliser l'instruction using qui appellera automatiquement Dispose à la fin du bloc de code.

Dans ADO.NET 2.0, il existe de nouvelles méthodes pour gérer par programme les pools: ClearAllPools et ClearPool. Cela pourrait vous aider avec votre problème jusqu'à ce que vous puissiez réparer tout le code d'accès aux données.

+0

chanceux pour moi je ne serai pas le seul à faire la réparation! le vrai problème est l'utilisation excessive des gestionnaires de données dans l'application ... il n'y a pas de bloc try/catch/finally donc si une erreur survient quand le code de disposition ne s'exécute jamais et que les connexions s'usent ... – davidsleeps

+0

... c'est drôle/triste comment les mêmes erreurs apparaissent encore et encore. –

Questions connexes