inetinfo virtual memory behavior

inetinfo virtual memory behavior

am 30.12.2005 19:44:01 von EH

Hi, I have a question about IIS process Inetinfo's memory behavior. Over the
course of two days, the perfmon process,virtual bytes counter grows from 1G
to 2G at which time out of memory errors are thrown and the server is
restarted.

However, during this time, private bytes and working set grow only from 500M
to 600M. Committed bytes grow from 1.1G to 1.3G, and available bytes goes
from 2.5G to 2.2G.

My question is why virtual bytes might grow so much quicker than the other
counters. My only theory is that there could be a slow memory leak, whose
pages in RAM are not active and so eventually moved to the paging file, thus
showing up in the virtual bytes but not the working set. But wouldn't the
leak then show up in committed bytes and available bytes? Is this behavior
consistent with a slow memory leak, or is another theory more plausible.
Thank you.

Re: inetinfo virtual memory behavior

am 31.12.2005 03:41:53 von someone

It all depends on the code that you have running inside of inetinfo.exe.
What ISAPI Filters, ISAPI Extensions, and in-process COM objects are used by
your application?

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

"eh" wrote in message
news:CB8ED7F9-DACB-445E-AC78-5D3E9EB3B9C9@microsoft.com...
> Hi, I have a question about IIS process Inetinfo's memory behavior. Over
> the
> course of two days, the perfmon process,virtual bytes counter grows from
> 1G
> to 2G at which time out of memory errors are thrown and the server is
> restarted.
>
> However, during this time, private bytes and working set grow only from
> 500M
> to 600M. Committed bytes grow from 1.1G to 1.3G, and available bytes goes
> from 2.5G to 2.2G.
>
> My question is why virtual bytes might grow so much quicker than the other
> counters. My only theory is that there could be a slow memory leak, whose
> pages in RAM are not active and so eventually moved to the paging file,
> thus
> showing up in the virtual bytes but not the working set. But wouldn't the
> leak then show up in committed bytes and available bytes? Is this
> behavior
> consistent with a slow memory leak, or is another theory more plausible.
> Thank you.

Re: inetinfo virtual memory behavior

am 05.01.2006 00:40:02 von EH

The code is all C++ ISAPI dlls running in-process within inetinfo.dll. Is it
possible that a memory leak in the in-process code would appear in
inetinfo.dll's virtual memory counter, but not to some of its other counters
such as private bytes?

"David Wang [Msft]" wrote:

> It all depends on the code that you have running inside of inetinfo.exe.
> What ISAPI Filters, ISAPI Extensions, and in-process COM objects are used by
> your application?
>
> --
> //David
> IIS
> http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no rights.
> //
>
> "eh" wrote in message
> news:CB8ED7F9-DACB-445E-AC78-5D3E9EB3B9C9@microsoft.com...
> > Hi, I have a question about IIS process Inetinfo's memory behavior. Over
> > the
> > course of two days, the perfmon process,virtual bytes counter grows from
> > 1G
> > to 2G at which time out of memory errors are thrown and the server is
> > restarted.
> >
> > However, during this time, private bytes and working set grow only from
> > 500M
> > to 600M. Committed bytes grow from 1.1G to 1.3G, and available bytes goes
> > from 2.5G to 2.2G.
> >
> > My question is why virtual bytes might grow so much quicker than the other
> > counters. My only theory is that there could be a slow memory leak, whose
> > pages in RAM are not active and so eventually moved to the paging file,
> > thus
> > showing up in the virtual bytes but not the working set. But wouldn't the
> > leak then show up in committed bytes and available bytes? Is this
> > behavior
> > consistent with a slow memory leak, or is another theory more plausible.
> > Thank you.
>
>
>

Re: inetinfo virtual memory behavior

am 20.01.2006 03:58:26 von someone

Windows does not distinguish between DLLs loaded inside of a process as
"INETINFO" or "ISAPI". It is just a process with some arbitrary DLLs inside
of it. Some of those DLLs implement IIS; others are ISAPI DLLs extending IIS
behavior.

Virtual Memory and Private Memory correspond to different stages of memory
that is in use across all DLLs inside the process.

Personally, a memory leak is a memory leak. It doesn't matter if it is slow
or fast; nor does it matter what sort of memory appears to be growing or
that it got paged out or not. Any memory/resource leak that exists in a
service has to be fixed or else it will drive the server to its knees.

You want to use a tool like DebugDiag to track down what type of memory
allocation is most abundant right before reaching "Out of Memory" so that
you can figure out what is leaking.

http://www.microsoft.com/windowsserver2003/iis/diagnostictoo ls/default.mspx

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

"eh" wrote in message
news:71CE31D0-9605-40C9-BE2C-2B6A62A02F86@microsoft.com...
> The code is all C++ ISAPI dlls running in-process within inetinfo.dll. Is
> it
> possible that a memory leak in the in-process code would appear in
> inetinfo.dll's virtual memory counter, but not to some of its other
> counters
> such as private bytes?
>
> "David Wang [Msft]" wrote:
>
>> It all depends on the code that you have running inside of inetinfo.exe.
>> What ISAPI Filters, ISAPI Extensions, and in-process COM objects are used
>> by
>> your application?
>>
>> --
>> //David
>> IIS
>> http://blogs.msdn.com/David.Wang
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> //
>>
>> "eh" wrote in message
>> news:CB8ED7F9-DACB-445E-AC78-5D3E9EB3B9C9@microsoft.com...
>> > Hi, I have a question about IIS process Inetinfo's memory behavior.
>> > Over
>> > the
>> > course of two days, the perfmon process,virtual bytes counter grows
>> > from
>> > 1G
>> > to 2G at which time out of memory errors are thrown and the server is
>> > restarted.
>> >
>> > However, during this time, private bytes and working set grow only from
>> > 500M
>> > to 600M. Committed bytes grow from 1.1G to 1.3G, and available bytes
>> > goes
>> > from 2.5G to 2.2G.
>> >
>> > My question is why virtual bytes might grow so much quicker than the
>> > other
>> > counters. My only theory is that there could be a slow memory leak,
>> > whose
>> > pages in RAM are not active and so eventually moved to the paging file,
>> > thus
>> > showing up in the virtual bytes but not the working set. But wouldn't
>> > the
>> > leak then show up in committed bytes and available bytes? Is this
>> > behavior
>> > consistent with a slow memory leak, or is another theory more
>> > plausible.
>> > Thank you.
>>
>>
>>