IIS 6 application pool issues

IIS 6 application pool issues

am 30.08.2007 12:06:59 von Horatiu Popovici

Hello
We have a server (2,4 Ghz Xeon with 4 Gb RAM) that is the host
for 150 web applications running in 90 application pools.
The problem we are facing is that sometime one particular application
(Lagarde Storefront eCommerce app) start crunching the CPU and the
memory. We can see that sometime the peaked memory consumption for that
process (worker process have identities) reached 900 Mb which seems to
be extreme when no one is on the server.

I have to mention that on that server, there are some other Storefront
application , but those seems to be relatively ok.

How can I find the "bad guy" in that application. I am not very familiar
with WinDBG to figure it out on how to find out a memory leak.

Is the number of existing application an issue?

Best Regards
Horatiu

Re: IIS 6 application pool issues

am 30.08.2007 16:51:21 von patfilot

What I would recommend is to run IISState (which is a wrapper for WinDBG's
debug engine) against the process that is exhibiting the bad behavior -
while the CPU spike is occurring. We should then (hopefully) be able to
isolate where the spike is happening code wise & suggest some next steps.


Pat




"Horatiu Popovici" wrote in message
news:%23%23FcQ0u6HHA.5184@TK2MSFTNGP03.phx.gbl...
> Hello
> We have a server (2,4 Ghz Xeon with 4 Gb RAM) that is the host
> for 150 web applications running in 90 application pools.
> The problem we are facing is that sometime one particular application
> (Lagarde Storefront eCommerce app) start crunching the CPU and the memory.
> We can see that sometime the peaked memory consumption for that process
> (worker process have identities) reached 900 Mb which seems to be extreme
> when no one is on the server.
>
> I have to mention that on that server, there are some other Storefront
> application , but those seems to be relatively ok.
>
> How can I find the "bad guy" in that application. I am not very familiar
> with WinDBG to figure it out on how to find out a memory leak.
>
> Is the number of existing application an issue?
>
> Best Regards
> Horatiu

Re: IIS 6 application pool issues

am 31.08.2007 09:26:58 von Horatiu Popovici

Thank you for the suggestion.
What I am curious is how is IIS allocating the resources for each
Application pool?
This application (when no one is connected and after pool restart) gets
280Mb of RAM. Well the W3wp actually. Which is the same as other
Storefronts. What will happen with the other applications?

Pat [MSFT] wrote:
> What I would recommend is to run IISState (which is a wrapper for
> WinDBG's debug engine) against the process that is exhibiting the bad
> behavior - while the CPU spike is occurring. We should then (hopefully)
> be able to isolate where the spike is happening code wise & suggest some
> next steps.
>
>
> Pat
>
>
>
>
> "Horatiu Popovici" wrote in message
> news:%23%23FcQ0u6HHA.5184@TK2MSFTNGP03.phx.gbl...
>> Hello
>> We have a server (2,4 Ghz Xeon with 4 Gb RAM) that is the host
>> for 150 web applications running in 90 application pools.
>> The problem we are facing is that sometime one particular application
>> (Lagarde Storefront eCommerce app) start crunching the CPU and the
>> memory. We can see that sometime the peaked memory consumption for
>> that process (worker process have identities) reached 900 Mb which
>> seems to be extreme when no one is on the server.
>>
>> I have to mention that on that server, there are some other Storefront
>> application , but those seems to be relatively ok.
>>
>> How can I find the "bad guy" in that application. I am not very
>> familiar with WinDBG to figure it out on how to find out a memory leak.
>>
>> Is the number of existing application an issue?
>>
>> Best Regards
>> Horatiu
>

Re: IIS 6 application pool issues

am 31.08.2007 21:08:05 von patfilot

IIS doesn't allocate resources - it more or less just manages access, etc.
The OS manages resources. In the memory footprint are things like dll's,
..Net assemblies, in-memory structures, thread stacks, etc. You can see the
memory allocation by using Perfmon: Process:Private Bytes. All 32bit apps
get a 2GB Virtual Memory space (regardless of RAM installed) to host all of
that memory. The OS will then back some of that 2GB with RAM and the rest
with the paging file. It is not unusual for large websites with lots of
objects to have 1GB+ per process. Some sites are 50MB (simple static-only,
etc.).


Pat

"Horatiu Popovici" wrote in message
news:eXiSe$56HHA.1204@TK2MSFTNGP03.phx.gbl...
> Thank you for the suggestion.
> What I am curious is how is IIS allocating the resources for each
> Application pool?
> This application (when no one is connected and after pool restart) gets
> 280Mb of RAM. Well the W3wp actually. Which is the same as other
> Storefronts. What will happen with the other applications?
>
> Pat [MSFT] wrote:
>> What I would recommend is to run IISState (which is a wrapper for
>> WinDBG's debug engine) against the process that is exhibiting the bad
>> behavior - while the CPU spike is occurring. We should then (hopefully)
>> be able to isolate where the spike is happening code wise & suggest some
>> next steps.
>>
>>
>> Pat
>>
>>
>>
>>
>> "Horatiu Popovici" wrote in message
>> news:%23%23FcQ0u6HHA.5184@TK2MSFTNGP03.phx.gbl...
>>> Hello
>>> We have a server (2,4 Ghz Xeon with 4 Gb RAM) that is the host
>>> for 150 web applications running in 90 application pools.
>>> The problem we are facing is that sometime one particular application
>>> (Lagarde Storefront eCommerce app) start crunching the CPU and the
>>> memory. We can see that sometime the peaked memory consumption for that
>>> process (worker process have identities) reached 900 Mb which seems to
>>> be extreme when no one is on the server.
>>>
>>> I have to mention that on that server, there are some other Storefront
>>> application , but those seems to be relatively ok.
>>>
>>> How can I find the "bad guy" in that application. I am not very familiar
>>> with WinDBG to figure it out on how to find out a memory leak.
>>>
>>> Is the number of existing application an issue?
>>>
>>> Best Regards
>>> Horatiu
>>