app pool setting kills threads but keeps sessions

[Scott]

Im having a problem with a .net 2.0 aspx app on IIS6 creating a silly number
of threads using the w3wp.exe process for its specifc app pool. I see this
issue once every few weeks. The app has been isolated to its own app pool
with the following settings:
---------------------------------------------------------------------
RECYCLING
recycle worker processses (in minutes) : 870
recycle worker process (no of requests): (not ticked)
recycle worker processes at the following times: 00:00
max virtual memory: (not ticked)
max used memory (in mb): 1000mb (1gb)

PERFORMANCE
shutdown worker processes after being idle for (time in mins): 20
limit the kernal request queue (number of requests): 1000
enable cpu monitoring (%): 85
refresh cpu usage numbers (in mins): 5
action performed when cpu usage exceeds maximum cpu uses: NO ACTION (keeps
sessions)
max number of worker processes: 1

HEALTH
enable pinging (checked)
ping worker process every (seconds) : 30
enable rapid fail protection (checked)
failures: 5
time period (in mins):5
start time limit - worker process must startup within (seconds): 90
shutdown time limit - worker process must shutdown within (seconds): 90
---------------------------------------------------------------------
Normal running would see the w3wp.exe process utilise 300MB ram and 50
therads. When my problem occurs the thread count slowly increases to 10,000
, ram to 1GB before the threads are knocked back to 0. The w3wp.exe process
is NOT shutdown and my users are not logged out (crucially), ie they keep
their session and dont have to log back in . Altough the standard 50 threads
are killed in amoungst the 10, 000 rouge threads some running processes may
return an error but no reports incoming from end users. I have debugging
tools in place that allow me to log possible calls the threads make , hoping
to see a pattern.

1)Just wondering if any expert can offer any pros/cons on the above app pool
settings ?

2)I think the "max used mem" setting appears to be doing the trick to
automatiaclly handle this issue (by killing the threads, keeping the session
alive , but can someone explain why ? ... i take it threads are unrelated to
the session).

Apparently the app uses server based session but we store a local cookie in
a browser for authentication.

Thank you.

[Jeffrey Ingalls]

Hi Scott,

Sorry to hear of your website problems. The Recycling section values should
depend on information you gather in perf mon. If you find the threads in
w3wp.exe to linearly increase within 60 minutes you may want to change the
value of 870 minutes to 60 minutes. Perhaps you see threads increase around
1:00pm everyday therefore you may want to recycle around that time. What you
are aiming for is analyzing the data to make best guesses on how to get the
app to limp by until you resolve the problem.

To get to root cause there are a few places you can look after gathering
performance monitor data such as the System and Application event viewer logs
and the IIS logs themselves around the time of the problem (match up the time
when threads begin to increase). If this data isn't helping you get to a
solution, you can try using tools like Request Monitor, IIS Trace and the IIS
Request Viewer. The Debug Diagnostic Tool is another valuable tool.

More information...

IIS Request Monitor:
http://technet.microsoft.com/en-us/library/cc786561(WS.10).aspx

How to Trace Requests in IIS 6.0:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/b0f48764-9df2-4d4f-9746-2601e336f0ad.mspx?mfr=true

Debug Diagnostic Tool v1.1
http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en

All the best,
Jeffrey Ingalls

Post by Scott
Im having a problem with a .net 2.0 aspx app on IIS6 creating a silly number
of threads using the w3wp.exe process for its specifc app pool. I see this
issue once every few weeks. The app has been isolated to its own app pool
---------------------------------------------------------------------
RECYCLING
recycle worker processses (in minutes) : 870
recycle worker process (no of requests): (not ticked)
recycle worker processes at the following times: 00:00
max virtual memory: (not ticked)
max used memory (in mb): 1000mb (1gb)
PERFORMANCE
shutdown worker processes after being idle for (time in mins): 20
limit the kernal request queue (number of requests): 1000
enable cpu monitoring (%): 85
refresh cpu usage numbers (in mins): 5
action performed when cpu usage exceeds maximum cpu uses: NO ACTION (keeps
sessions)
max number of worker processes: 1
HEALTH
enable pinging (checked)
ping worker process every (seconds) : 30
enable rapid fail protection (checked)
failures: 5
time period (in mins):5
start time limit - worker process must startup within (seconds): 90
shutdown time limit - worker process must shutdown within (seconds): 90
---------------------------------------------------------------------
Normal running would see the w3wp.exe process utilise 300MB ram and 50
therads. When my problem occurs the thread count slowly increases to 10,000
, ram to 1GB before the threads are knocked back to 0. The w3wp.exe process
is NOT shutdown and my users are not logged out (crucially), ie they keep
their session and dont have to log back in . Altough the standard 50 threads
are killed in amoungst the 10, 000 rouge threads some running processes may
return an error but no reports incoming from end users. I have debugging
tools in place that allow me to log possible calls the threads make , hoping
to see a pattern.
1)Just wondering if any expert can offer any pros/cons on the above app pool
settings ?
2)I think the "max used mem" setting appears to be doing the trick to
automatiaclly handle this issue (by killing the threads, keeping the session
alive , but can someone explain why ? ... i take it threads are unrelated to
the session).
Apparently the app uses server based session but we store a local cookie in
a browser for authentication.
Thank you.
.