IIS 5 - virtual bytes continuosly maxes out

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.

http://www.50amp.com/iis/memory_tracking.jpg

That's showing samples taken at 20 second intervals. For a more long term
display of this information see this graph:

http://www.50amp.com/iis/graph.jpg

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).

http://www.50amp.com/iis/Memory_Repo..._18AM__375.zip

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.

http://www.50amp.com/iis/Memory_Repo..._39AM__375.zip

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.

http://www.50amp.com/iis/Memory_Repo..._39AM__375.htm

http://www.50amp.com/iis/Memory_Repo..._18AM__375.htm

Just replying to get this crossposted in microsoft.public.windbg. While not
specific to windbg I'm hoping someone over there may have some helpful
insight.


"Chris McFarling" <mcfly09@hotmail.com> wrote in message
news:O1k%23Xxn8IHA.3336@TK2MSFTNGP03.phx.gbl...
>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.
>
> http://www.50amp.com/iis/memory_tracking.jpg
>
> That's showing samples taken at 20 second intervals. For a more long term
> display of this information see this graph:
>
> http://www.50amp.com/iis/graph.jpg
>
> 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
>
> http://www.50amp.com/iis/Memory_Repo..._18AM__375.htm
>
> 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.
>
> http://www.50amp.com/iis/Memory_Repo..._39AM__375.htm
>
> Does anyone with a better understanding DebugDiag reports see anything
> that can explain why this is happening?
>

What you are basically witnessing is virtual memory fragmentation. The most
likley cause of this is a small memory leak. Virtual memory is the 2GB of
address space that every 32bit process gets in Windows. It is not related to
physical (RAM/Paging file) memory.

Whenever you load a DLL, allocate memory, create a thread, etc. - in other
words get a resource within a process, some amount of the virtual memory is
used. When you see it constantly growing, then the most likely cause is
memory fragmentation. The mechanism is generally that a relatively large
amount of memory is requested, and dutifully provided. The memory is then
_almost_ completely freed - i.e. there is a small bit left. Let's assume
that the worst case is that the memory left over is addressed in the middle
of the 1MB space that was previously requested. On the next page request
another 1MB is requested, but b/c there is a bit leftover from last time, we
can't reuse the 1MB block (all memory allocations are contiguous), so a new
1MB block is given up. Watching perfmon, you will see Virtual Memory
increasing relatively steeply and Process:Private Bytes (which tracks
allocations & frees) growing very slowly. Eventually there isn't a 1MB block
left and allocations begin to fail, which then leads to other failures.

There are a few things you can try:
1) If there are a number of websites sharing the same process space, you can
split them up into HIGH isolation. This will give each their own virtual
memory map. This will both increase uptime & (hopefully) tell you where the
offender is.
2) If you suspect a particular COM object, you can try putting it into a
COM+ Server package which will isolate its memory usage and again tell you if
the problem is there or not.
3) You should make sure you have the lastest MDAC, OS Service Pack, & COM+
Rollup packages installed.

Overall these are wickedly difficult problems to track down. The leaks tend
to be very, very small (a few bytes) and are generally lost in the noise of
all of the other work going on. Sometimes its just a lot easier to split
everything into separate processes and recycle the process periodically -
this is more or less what IIS6+ does automatically.


Pat

"Chris McFarling" wrote:

> Just replying to get this crossposted in microsoft.public.windbg. While not
> specific to windbg I'm hoping someone over there may have some helpful
> insight.
>
>
> "Chris McFarling" <mcfly09@hotmail.com> wrote in message
> news:O1k%23Xxn8IHA.3336@TK2MSFTNGP03.phx.gbl...
> >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.
> >
> > http://www.50amp.com/iis/memory_tracking.jpg
> >
> > That's showing samples taken at 20 second intervals. For a more long term
> > display of this information see this graph:
> >
> > http://www.50amp.com/iis/graph.jpg
> >
> > 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
> >
> > http://www.50amp.com/iis/Memory_Repo..._18AM__375.htm
> >
> > 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.
> >
> > http://www.50amp.com/iis/Memory_Repo..._39AM__375.htm
> >
> > Does anyone with a better understanding DebugDiag reports see anything
> > that can explain why this is happening?
> >
>
>
>

Thanks for the insight. Regarding the things to try...

1) I've had one site isolated in a separate process for a while. The same
behavior shows up in that process as in the pooled process.

2) There are 2 3rd party COM objects in use on this server, AbaleZip and
ImageMagick. I tried isolating each into their own process. (How to Isolate
a DLL into a Separate Process By Using Component Services
http://support.microsoft.com/kb/281335) I was successful with AbaleZip but
not with ImageMagick. I have a post here
http://www.imagemagick.org/discourse...hp?f=8&t=11743 trying
to figure that one out. The following error is returned when accessing the
COM object this way: Server object error 'ASP 0193 : 800706be' OnStartPage
Failed

In addition, I'd assume that memory allocations related to a COM component
would coincide with page requests to the ASP pages that include those
components. I've cross referenced page requests to memory allocations and
there is no correlation.

3) This is Windows 2000 SP4 with MDAC 2.7. I haven't installed MDAC 2.8SP1
yet. I thought I recalled something about 2.8 breaking some code that I had.
I'll research that and upgrade if it doesn't cause problems.




"Pat [MSFT]" <PatMSFT@discussions.microsoft.com> wrote in message
news:CC9A58EC-2722-41EB-B501-8C172DF2F6D2@microsoft.com...
> What you are basically witnessing is virtual memory fragmentation. The
> most
> likley cause of this is a small memory leak. Virtual memory is the 2GB of
> address space that every 32bit process gets in Windows. It is not related
> to
> physical (RAM/Paging file) memory.
>
> Whenever you load a DLL, allocate memory, create a thread, etc. - in other
> words get a resource within a process, some amount of the virtual memory
> is
> used. When you see it constantly growing, then the most likely cause is
> memory fragmentation. The mechanism is generally that a relatively large
> amount of memory is requested, and dutifully provided. The memory is then
> _almost_ completely freed - i.e. there is a small bit left. Let's assume
> that the worst case is that the memory left over is addressed in the
> middle
> of the 1MB space that was previously requested. On the next page request
> another 1MB is requested, but b/c there is a bit leftover from last time,
> we
> can't reuse the 1MB block (all memory allocations are contiguous), so a
> new
> 1MB block is given up. Watching perfmon, you will see Virtual Memory
> increasing relatively steeply and Process:Private Bytes (which tracks
> allocations & frees) growing very slowly. Eventually there isn't a 1MB
> block
> left and allocations begin to fail, which then leads to other failures.
>
> There are a few things you can try:
> 1) If there are a number of websites sharing the same process space, you
> can
> split them up into HIGH isolation. This will give each their own virtual
> memory map. This will both increase uptime & (hopefully) tell you where
> the
> offender is.
> 2) If you suspect a particular COM object, you can try putting it into a
> COM+ Server package which will isolate its memory usage and again tell you
> if
> the problem is there or not.
> 3) You should make sure you have the lastest MDAC, OS Service Pack, & COM+
> Rollup packages installed.
>
> Overall these are wickedly difficult problems to track down. The leaks
> tend
> to be very, very small (a few bytes) and are generally lost in the noise
> of
> all of the other work going on. Sometimes its just a lot easier to split
> everything into separate processes and recycle the process periodically -
> this is more or less what IIS6+ does automatically.
>
>
> Pat
>
> "Chris McFarling" wrote:
>
>> Just replying to get this crossposted in microsoft.public.windbg. While
>> not
>> specific to windbg I'm hoping someone over there may have some helpful
>> insight.
>>
>>
>> "Chris McFarling" <mcfly09@hotmail.com> wrote in message
>> news:O1k%23Xxn8IHA.3336@TK2MSFTNGP03.phx.gbl...
>> >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.
>> >
>> > http://www.50amp.com/iis/memory_tracking.jpg
>> >
>> > That's showing samples taken at 20 second intervals. For a more long
>> > term
>> > display of this information see this graph:
>> >
>> > http://www.50amp.com/iis/graph.jpg
>> >
>> > 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
>> >
>> > http://www.50amp.com/iis/Memory_Repo..._18AM__375.htm
>> >
>> > 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.
>> >
>> > http://www.50amp.com/iis/Memory_Repo..._39AM__375.htm
>> >
>> > Does anyone with a better understanding DebugDiag reports see anything
>> > that can explain why this is happening?
>> >
>>
>>
>>

"Chris McFarling" wrote:

> Thanks for the insight. Regarding the things to try...
>
> 1) I've had one site isolated in a separate process for a while. The same
> behavior shows up in that process as in the pooled process.
>
> 2) There are 2 3rd party COM objects in use on this server, AbaleZip and
> ImageMagick. I tried isolating each into their own process. (How to Isolate
> a DLL into a Separate Process By Using Component Services
> http://support.microsoft.com/kb/281335) I was successful with AbaleZip but
> not with ImageMagick. I have a post here
> http://www.imagemagick.org/discourse...hp?f=8&t=11743 trying
> to figure that one out. The following error is returned when accessing the
> COM object this way: Server object error 'ASP 0193 : 800706be' OnStartPage
> Failed
>
> In addition, I'd assume that memory allocations related to a COM component
> would coincide with page requests to the ASP pages that include those
> components. I've cross referenced page requests to memory allocations and
> there is no correlation.
>
> 3) This is Windows 2000 SP4 with MDAC 2.7. I haven't installed MDAC 2.8SP1
> yet. I thought I recalled something about 2.8 breaking some code that I had.
> I'll research that and upgrade if it doesn't cause problems.
>
>
>
>
> "Pat [MSFT]" <PatMSFT@discussions.microsoft.com> wrote in message
> news:CC9A58EC-2722-41EB-B501-8C172DF2F6D2@microsoft.com...
> > What you are basically witnessing is virtual memory fragmentation. The
> > most
> > likley cause of this is a small memory leak. Virtual memory is the 2GB of
> > address space that every 32bit process gets in Windows. It is not related
> > to
> > physical (RAM/Paging file) memory.
> >
> > Whenever you load a DLL, allocate memory, create a thread, etc. - in other
> > words get a resource within a process, some amount of the virtual memory
> > is
> > used. When you see it constantly growing, then the most likely cause is
> > memory fragmentation. The mechanism is generally that a relatively large
> > amount of memory is requested, and dutifully provided. The memory is then
> > _almost_ completely freed - i.e. there is a small bit left. Let's assume
> > that the worst case is that the memory left over is addressed in the
> > middle
> > of the 1MB space that was previously requested. On the next page request
> > another 1MB is requested, but b/c there is a bit leftover from last time,
> > we
> > can't reuse the 1MB block (all memory allocations are contiguous), so a
> > new
> > 1MB block is given up. Watching perfmon, you will see Virtual Memory
> > increasing relatively steeply and Process:Private Bytes (which tracks
> > allocations & frees) growing very slowly. Eventually there isn't a 1MB
> > block
> > left and allocations begin to fail, which then leads to other failures.
> >
> > There are a few things you can try:
> > 1) If there are a number of websites sharing the same process space, you
> > can
> > split them up into HIGH isolation. This will give each their own virtual
> > memory map. This will both increase uptime & (hopefully) tell you where
> > the
> > offender is.
> > 2) If you suspect a particular COM object, you can try putting it into a
> > COM+ Server package which will isolate its memory usage and again tell you
> > if
> > the problem is there or not.
> > 3) You should make sure you have the lastest MDAC, OS Service Pack, & COM+
> > Rollup packages installed.
> >
> > Overall these are wickedly difficult problems to track down. The leaks
> > tend
> > to be very, very small (a few bytes) and are generally lost in the noise
> > of
> > all of the other work going on. Sometimes its just a lot easier to split
> > everything into separate processes and recycle the process periodically -
> > this is more or less what IIS6+ does automatically.
> >
> >
> > Pat
> >
> > "Chris McFarling" wrote:
> >
> >> Just replying to get this crossposted in microsoft.public.windbg. While
> >> not
> >> specific to windbg I'm hoping someone over there may have some helpful
> >> insight.
> >>
> >>
> >> "Chris McFarling" <mcfly09@hotmail.com> wrote in message
> >> news:O1k%23Xxn8IHA.3336@TK2MSFTNGP03.phx.gbl...
> >> >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.
> >> >
> >> > http://www.50amp.com/iis/memory_tracking.jpg
> >> >
> >> > That's showing samples taken at 20 second intervals. For a more long
> >> > term
> >> > display of this information see this graph:
> >> >
> >> > http://www.50amp.com/iis/graph.jpg
> >> >
> >> > 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
> >> >
> >> > http://www.50amp.com/iis/Memory_Repo..._18AM__375.htm
> >> >
> >> > 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.
> >> >
> >> > http://www.50amp.com/iis/Memory_Repo..._39AM__375.htm
> >> >
> >> > Does anyone with a better understanding DebugDiag reports see anything
> >> > that can explain why this is happening?
> >> >
> >>
> >>
> >>
>
>
>

The virtual memory usage will probablly not correlate to page requests -
unless there are very large memory allocations. The example I used was a bit
extreme. Given the large number of caching mechanisms, delayed cleanup, etc.
it can be pretty tough to correlate a specific action to a specific memory
leak (one reason why these issues are so hard to track down).

Some COM objects cannot run in a Server Package. Most can, but it isn't a
bug if they can't, it just means that they are assuming a certain context.

Pat

"Chris McFarling" wrote:

> Thanks for the insight. Regarding the things to try...
>
> 1) I've had one site isolated in a separate process for a while. The same
> behavior shows up in that process as in the pooled process.
>
> 2) There are 2 3rd party COM objects in use on this server, AbaleZip and
> ImageMagick. I tried isolating each into their own process. (How to Isolate
> a DLL into a Separate Process By Using Component Services
> http://support.microsoft.com/kb/281335) I was successful with AbaleZip but
> not with ImageMagick. I have a post here
> http://www.imagemagick.org/discourse...hp?f=8&t=11743 trying
> to figure that one out. The following error is returned when accessing the
> COM object this way: Server object error 'ASP 0193 : 800706be' OnStartPage
> Failed
>
> In addition, I'd assume that memory allocations related to a COM component
> would coincide with page requests to the ASP pages that include those
> components. I've cross referenced page requests to memory allocations and
> there is no correlation.
>
> 3) This is Windows 2000 SP4 with MDAC 2.7. I haven't installed MDAC 2.8SP1
> yet. I thought I recalled something about 2.8 breaking some code that I had.
> I'll research that and upgrade if it doesn't cause problems.
>
>
>
>
> "Pat [MSFT]" <PatMSFT@discussions.microsoft.com> wrote in message
> news:CC9A58EC-2722-41EB-B501-8C172DF2F6D2@microsoft.com...
> > What you are basically witnessing is virtual memory fragmentation. The
> > most
> > likley cause of this is a small memory leak. Virtual memory is the 2GB of
> > address space that every 32bit process gets in Windows. It is not related
> > to
> > physical (RAM/Paging file) memory.
> >
> > Whenever you load a DLL, allocate memory, create a thread, etc. - in other
> > words get a resource within a process, some amount of the virtual memory
> > is
> > used. When you see it constantly growing, then the most likely cause is
> > memory fragmentation. The mechanism is generally that a relatively large
> > amount of memory is requested, and dutifully provided. The memory is then
> > _almost_ completely freed - i.e. there is a small bit left. Let's assume
> > that the worst case is that the memory left over is addressed in the
> > middle
> > of the 1MB space that was previously requested. On the next page request
> > another 1MB is requested, but b/c there is a bit leftover from last time,
> > we
> > can't reuse the 1MB block (all memory allocations are contiguous), so a
> > new
> > 1MB block is given up. Watching perfmon, you will see Virtual Memory
> > increasing relatively steeply and Process:Private Bytes (which tracks
> > allocations & frees) growing very slowly. Eventually there isn't a 1MB
> > block
> > left and allocations begin to fail, which then leads to other failures.
> >
> > There are a few things you can try:
> > 1) If there are a number of websites sharing the same process space, you
> > can
> > split them up into HIGH isolation. This will give each their own virtual
> > memory map. This will both increase uptime & (hopefully) tell you where
> > the
> > offender is.
> > 2) If you suspect a particular COM object, you can try putting it into a
> > COM+ Server package which will isolate its memory usage and again tell you
> > if
> > the problem is there or not.
> > 3) You should make sure you have the lastest MDAC, OS Service Pack, & COM+
> > Rollup packages installed.
> >
> > Overall these are wickedly difficult problems to track down. The leaks
> > tend
> > to be very, very small (a few bytes) and are generally lost in the noise
> > of
> > all of the other work going on. Sometimes its just a lot easier to split
> > everything into separate processes and recycle the process periodically -
> > this is more or less what IIS6+ does automatically.
> >
> >
> > Pat
> >
> > "Chris McFarling" wrote:
> >
> >> Just replying to get this crossposted in microsoft.public.windbg. While
> >> not
> >> specific to windbg I'm hoping someone over there may have some helpful
> >> insight.
> >>
> >>
> >> "Chris McFarling" <mcfly09@hotmail.com> wrote in message
> >> news:O1k%23Xxn8IHA.3336@TK2MSFTNGP03.phx.gbl...
> >> >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.
> >> >
> >> > http://www.50amp.com/iis/memory_tracking.jpg
> >> >
> >> > That's showing samples taken at 20 second intervals. For a more long
> >> > term
> >> > display of this information see this graph:
> >> >
> >> > http://www.50amp.com/iis/graph.jpg
> >> >
> >> > 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
> >> >
> >> > http://www.50amp.com/iis/Memory_Repo..._18AM__375.htm
> >> >
> >> > 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.
> >> >
> >> > http://www.50amp.com/iis/Memory_Repo..._39AM__375.htm
> >> >
> >> > Does anyone with a better understanding DebugDiag reports see anything
> >> > that can explain why this is happening?
> >> >
> >>
> >>
> >>
>
>
>