IIS 5 & IIS 6
IIS 5 - virtual bytes continuously maxes out
Last post Jul 30, 2008 02:47 PM by cmcfarling
Jul 30, 2008 02:47 PM|cmcfarling|LINK
I have a Windows 2000 server running IIS 5. I have multiple ASP (classic) based sites running under Medium (Pooled) Application Protection. All sites are essentially clones and are constructed of essentially the same ASP pages. Every week to two weeks the
sites stop responding or generate various error messages. The problem appears to be memory related, a leak perhaps.
If I track the virtual bytes for the DLLHOST process that these sites run in, it eventually grows to the 2GB per process limit, at which point the problems occur. This has been going on for a while and I just unload the application periodically to resolve
the issue temporarily. I'd like to finally try to get to the bottom of this now though.
When virtual bytes increases, it usually jumps up instantly as opposed to a slow grow. This System Monitor screen shot shows the latest increase.
That's showing samples taken at 20 second intervals. For a more long term display of this information see this graph:
This shows memory tracking data from 7/23/08 to 7/30/08. On 7/23 virtual bytes jumped 256MB. Over the course of the next 7 days it stayed rather steady until 7/30 when it jumped 128MB.
The last few days I've been using Debug Diagnostic Tool to see if I could nail this down. I'm not well versed at interpreting memory dumps but I have been able to gleen some info. Here's the latest Debug Diag report that was tracking memory usage when that
latest jump in virtual bytes occurred (in ZIP format).
This is what I know... the default process heap seems to be where all of the memory allocation is going. The details for Heap 1 - 0x00070000 show several entries under the Segment Information subheading. Each of those segments corresponds to the increases
I'm seeing in system monitor for virtual bytes. When a segment fills up a new segment is requested, the latest being a 128MB segment. What that means exactly I'm not sure. That particular report represents DebugDiag monitoring memory for a 2 hour period. Here's
a report for another 2 hour period earlier this morning for comparison.
Does anyone with a better understanding DebugDiag reports see anything that can explain why this is happening?
Here are the above reports in html format so they can be viewed natively in your browser. The mht files were not viewing correctly over the web so I ZIPed them in the original post.
Also, if anyone has suggestions on a different/better forum to post this too I'd be happy to hear.