Applicability KB 831138: app that uses WebRequest has OutOfMemoryE

[Guest]

--
This request concerns the applicability of KB 831138:
FIX: A .NET Framework application that uses the System.Net.WebRequest method
very frequently experiences OutOfMemoryException errors
--

Our applications (website, webservices and windows services that communicate
with external webservices) use the System.Net.WebRequest very frequently for
sending and receiving Client certificates. Moreover, we encounter many
OutOfMemoryExceptions (and other performance problems). It seems therefore
that KB 831138 applies.

However, as a resolution the KB article mentions the usage of a proxyserver.
As our performance problems (including out of memory exceptions) seem to be
related to incoming requests, this casts some doubt about the applicability
to our applications.

Should we install the hotfix for KB 831138 and - just as important - how do
we obtain it?

Regards,
Martijn Kaag
______________________________
www.VECOZO.nl

 

[Jim Cheshire]

Hi Martijn,

That fix is included in SP1 and it's certainly recommended that you upgrade
to SP1.

If you want to find out if you might be encountering this issue, you can use
the debugger to check out your ServicePoint objects. See my blog for
details.

--
Jim Cheshire
================================
Blog: http://blogs.msdn.com/jamesche

Latest entry: Digging into Objects
Describes the details of digging into
memory usage with the debugger.

 

[Edwin Knoppert]

What SP, windows (which i never do) or FrameWork v2.x ?
Today i just started using this object.
Is there a workaround?

 

[Jim Cheshire]

What SP, windows (which i never do) or FrameWork v2.x ?
Today i just started using this object.
Is there a workaround?

Depends on your OS. If you're running Windows 2003, you should upgrade to
SP1.

This hotfix is a 1.1 hotfix, so Framework 2.0 does not apply.

--
Jim Cheshire
================================
Blog: http://blogs.msdn.com/jamesche

Latest entry: Digging into Objects
Describes the details of digging into
memory usage with the debugger.

 

[Guest]

Thanx Jim.

Sp1 turned out to be installed already, so we'll have to look elsewhere.
Your blog turns out to be an amazing startingpoint. Thanx a million!

Martijn

 

[Jim Cheshire]

Thanx Jim.

Sp1 turned out to be installed already, so we'll have to look
elsewhere. Your blog turns out to be an amazing startingpoint. Thanx
a million!

Martijn

Martijn,

One of my colleagues has just written a new command into SOS that allows you
to dump all ServicePoints easily. I don't believe it's in the public
extension, but look for it. It may make it in there in a later build.

--
Jim Cheshire
================================
Blog: http://blogs.msdn.com/jamesche

Latest entry:
Getting the PID and TID of a COM Call

Describes how to get the PID of the
dllhost process a COM call is executing
in and how to locate the thread as well.

 

[Guest]

Thanx Jim,

I got everything up and running. Well.. I mean... I got all debugger tools
up and running. Our services are still down and we're awaiting a support
engineer.

Meanwhile I posted some results in
microsoft.public.dotnet.framework.performance.
http://msdn.microsoft.com/newsgroup...97a85e-4c9e-48a7-8fca-4623769d46c2&sloc=en-us. Do you understand this?

Regards,
Martijn Kaag



______________________________
www.VECOZO.nl

 

[Jim Cheshire]

Thanx Jim,

I got everything up and running. Well.. I mean... I got all debugger
tools
up and running. Our services are still down and we're awaiting a
support
engineer.

Meanwhile I posted some results in
microsoft.public.dotnet.framework.performance.
http://msdn.microsoft.com/newsgroup...97a85e-4c9e-48a7-8fca-4623769d46c2&sloc=en-us.
Do you understand this?

Yes. You are seeing large amounts of fragmentation, likely in the large
object heap. That's actually to be expected since we don't ever compact the
LOH. One important thing to keep in mind is that we WILL reuse parts of the
LOH segments if we can so that fragmentation isn't as serious as it would be
in lower gens. (We added that in a hotfix a while back.)

Your application appears to also be creating many large objects . . . REALLY
large objects. Depending on your architecture, if you are freeing these
objects in a specific place, I would strongly consider calling GC.Collect.
This is one of the times when that is a suitable solution. For example, when
we trim cache, we call GC.Collect because we expect to be freeing large
blocks and expect that you are under memory pressure.

If you are waiting on a dump analysis from Microsoft, that will come from
one of my colleagues who can likely provide you with more information.
Because I haven't done an analysis on your dump, I could be way off with my
recommendation, so I'd wait. A dump analysis can take anywhere from 10
minutes to 10 hours.

--
Jim Cheshire
================================
Blog: http://blogs.msdn.com/jamesche

Latest entry:
Getting the PID and TID of a COM Call

Describes how to get the PID of the
dllhost process a COM call is executing
in and how to locate the thread as well.

 

[Guest]

Thanx Jim,

I do not see that much allocation in the LOH; it has the size of only
approx. 5% of the total GEN 2. So I'll await *judgment* of your colleague.

You did help me answer the question why GC.Collect is included in the
framework although it is recommended not to be used..

Thanx for your help. It is really appreciated.

Martijn Kaag





______________________________
www.VECOZO.nl

 

[Jim Cheshire]

Thanx Jim,

I do not see that much allocation in the LOH; it has the size of only
approx. 5% of the total GEN 2. So I'll await *judgment* of your
colleague.

You did help me answer the question why GC.Collect is included in the
framework although it is recommended not to be used..

Thanx for your help. It is really appreciated.

Martijn Kaag

I'd have to dig more into it to say for sure. Your LOH segments don't look
right on the output from your post. I'm not sure if that's just partial
output or what.

The primary concern based ONLY on what I see is the large number of free
blocks. I would investigate what is sitting next to those blocks since it's
likely that whatever is close to them was created in a similar time frame.

Good luck!

--
Jim Cheshire
================================
Blog: http://blogs.msdn.com/jamesche

Latest entry:
Getting the PID and TID of a COM Call

Describes how to get the PID of the
dllhost process a COM call is executing
in and how to locate the thread as well.