Onderwerp: Hangende (niet reagerende) AppPools

Hetzelfde heb ik al gepost in het "Troubleshooting" forum op forums.iis.net, maar helaas (nog) zonder nuttige reactie. Hopelijk heeft iemand hier hetzelfde ondervonden én opgelost.

Unresponsive (hanging) Application Pool

Het komt er eigenlijk op neer dat we steeds vaker merken dat applicatiepools ("AppPool") niet reageren, zonder dat IIS dit merkt. Dit bij verschillende AppPool configuraties (draaiende onder NETWORK SERVICE, of als anonieme IUSR). Een website van een klant blijft maar laden en laden tot de AppPool gerecycled wordt.

Iemand enig idee?

De enige keer dat ik zoiets meemaakte was bij extreem ranzige code die uitgevoerd werd (loops etc).

Iedere application pool onder een eigen gebruiker laten draaien, dan kan je makkelijk zien welke website voor problemen zorgt.

Oorspronkelijk geplaatst door Ingvald

Iedere application pool onder een eigen gebruiker laten draaien, dan kan je makkelijk zien welke website voor problemen zorgt.

Inderdaad, sowieso iedere klant een eigen AppPool geven en onder zijn eigen Windows account laten draaien.

Vaak zijn het slechte ActiveX Components die de Application Pool laten hangen, waardoor eigenlijk de hele Application Pool crasht of hangt. Als je er dan nog niet uitkomt kun je DebugDiag proberen.

Controlleer de gebruikersnaam en wachtwoord van de application pool.
Zoals hiervoor door andere gezegd, laat elke klant in eigen application pool. Dit zorgt voor veel opheldering.

Laat de klanten hun crappy code bekijken. Het is meestal hun eigen fout dat dit gebeurt.

Per klant een eigen pool zorgt ervoor dat je andere klanten geen problemen ondervinden.

Success, moet het niet lukken laat maar iets horen.

inderdaad elke klant een eigen pool en als je de foute hebt gevonden dan klant mailen dat zijn app iedere keer crashed. Tevens kan je de recycle waarde korter zetten.

su6

Algemene reactie op de gegeven reacties:

Het maakt geen verschil of de AppPools draaien onder NETWORK SERVICE, of een eigen identity. Van een crash is ook niet echt sprake, daar alles blijft draaien volgens IIS. Alleen de AppPool reageert niet meer, hij "hangt".

David Wang: How To: Understand and diagnose an AppPool crash

"Practically speaking, a crash is something that will simply wipe out its host process; this will stop whatever server side work and response generation that the process was supposed to perform."

"A hang, on the other hand, will usually keep its host process around but the hang prevents any real work from being done."

Het maakt ook niet uit welk soort scripting de klanten gebruiken, het komt voor bij ASP.NET, PHP, ASP en zelfs plain ol' HTML. Dat doet mij vermoeden dat een ISAPI filter de oorzaak is, maar hiervan heb ik nog niets terug kunnen vinden.

Met DebugDiag spelen op een live-systeem vind ik net iets té veel van het goede. Ik had gehoopt dat iemand anders dezelfde symptomen al eens had meegemaakt op zijn/haar webservers.

Nogmaals, doe gewoon het volgende:

- Plaats iedere klant in zijn Eigen AppPool (zorg dmv de naamgeving ook dat je weet welke website/klant gelinkt is aan welke AppPool)
- Run Process Explorer: http://live.sysinternals.com/procexp.exe
- Naast elke wp3.exe zie je een Process ID (PID)
- Voer vanaf een command prompt volgende commando uit: iisapp
- Je ziet naast elke AppPool een referentie naar een PID en zo kan je dus uitzoeken welke klant/webiste problemen geeft.

De oorzaak kan vanalles en nog wat zijn, daar is moelijk over te oordelen zonder zelf de server te bekijken/monitoren.

Nog even een slag om de arm houdende lijkt het een ISAPI filter geweest te zijn dat voor de hangende AppPools zorgde. In ons geval ISAPI_Rewrite v2.13.73. Sinds we vorige week één versie teruggegaan zijn (v2.12.72) heeft er geen AppPool meer vastgezeten.