Diagnosing root cause of .NET application using nearly 500 MB memory

  • Thread starter Thread starter Matt Adamson
  • Start date Start date
M

Matt Adamson

We have a .NET application which is obviously using nearly 500MB memory and
we can't understand why. I created a dump for a different issue and the
server ended up creating a process shutdown dump of this size.

I have seen the DumpLargeObjectSegments command however I'm not sure what to
look for next i.e. the output shows

0:000> !sos.dl
Loaded Son of Strike data table version 5 from
"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorwks.dll"
Going to dump the Large Object Segments.
Large object heap starts at 0x02071000
segment begin allocated size
02070000 02071000 02fbbf98 0x00f4af98(16,035,736)
0bd80000 0bd81000 0cd6f7c8 0x00fee7c8(16,705,480)
294b0000 294b1000 2a414908 0x00f63908(16,136,456)
1d010000 1d011000 1df65518 0x00f54518(16,074,008)
1e010000 1e011000 1ef99320 0x00f88320(16,286,496)
1f010000 1f011000 1ffd67a0 0x00fc57a0(16,537,504)
21010000 21011000 21fb4d48 0x00fa3d48(16,399,688)
23010000 23011000 23fe4ed0 0x00fd3ed0(16,596,688)
25010000 25011000 25fe7440 0x00fd6440(16,606,272)
274b0000 274b1000 284a4b18 0x00ff3b18(16,726,808)
2c4b0000 2c4b1000 2d4ac560 0x00ffb560(16,758,112)
2e4b0000 2e4b1000 2f47ddd0 0x00fccdd0(16,567,760)
2f4b0000 2f4b1000 304a3970 0x00ff2970(16,722,288)
304b0000 304b1000 314ad208 0x00ffc208(16,761,352)
08ce0000 08ce1000 09cd6d18 0x00ff5d18(16,735,512)
09ce0000 09ce1000 0accb370 0x00fea370(16,687,984)
0ace0000 0ace1000 0bc63c70 0x00f82c70(16,264,304)
0cd80000 0cd81000 0dd7f908 0x00ffe908(16,771,336)
0dd80000 0dd81000 0eba3a50 0x00e22a50(14,821,968)


0:000> !dumpheap -stat
total 141,545 objects
Statistics:

which produced a ton of objects in order of total size but the bottom part
is most useful I suspect i.e.

3379620 32,539 390,468
Tranmit.Sprinter.DataAccess.SQLDataAccess.SQLStaticDataStore
3379c3c 32,537 780,888 Tranmit.Sprinter.XMLBatchRecord
337bfcc 32,537 1,561,776
Tranmit.Sprinter.DataAccess.SQLDataAccess.SQLXMLBatchRecordData
95236c 127 7,808,984 System.Char[]
1501c8 801 76,190,256 Free
9526b0 438 116,192,444 System.Byte[]
79b94638 36,369 251,137,772 System.String
Total 141,545 objects
 
I'm no good at figuring out memory dumps, but I have done my share of
diagnostic work when it comes to memory issues.

I highly recomment getting a memory profiler to help see the mamanged heap
allocations. You can use the free CLR Profiler
(http://www.microsoft.com/downloads/...52-d7f4-4aeb-9b7a-94635beebdda&displaylang=en)
or you could use a commercial profiler (.Net Memory Profiler is one, and Red
Gate has their Ants profiler). With this you can see which object(s) are
using the most memory at a given time. There are also several Perf counters
which you can use to see the allocation of the CLR managed heap (.Net CLR
Memory Performance Object Category). With these tools you can get an idea of
what your application is doing.

There are a nice series of posts discussing the GC and managed heap health
at: http://blogs.msdn.com/maoni/default.aspx.

Hope this helps.

Casey

Matt Adamson said:
We have a .NET application which is obviously using nearly 500MB memory and
we can't understand why. I created a dump for a different issue and the
server ended up creating a process shutdown dump of this size.

I have seen the DumpLargeObjectSegments command however I'm not sure what to
look for next i.e. the output shows

0:000> !sos.dl
Loaded Son of Strike data table version 5 from
"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorwks.dll"
Going to dump the Large Object Segments.
Large object heap starts at 0x02071000
segment begin allocated size
02070000 02071000 02fbbf98 0x00f4af98(16,035,736)
0bd80000 0bd81000 0cd6f7c8 0x00fee7c8(16,705,480)
294b0000 294b1000 2a414908 0x00f63908(16,136,456)
1d010000 1d011000 1df65518 0x00f54518(16,074,008)
1e010000 1e011000 1ef99320 0x00f88320(16,286,496)
1f010000 1f011000 1ffd67a0 0x00fc57a0(16,537,504)
21010000 21011000 21fb4d48 0x00fa3d48(16,399,688)
23010000 23011000 23fe4ed0 0x00fd3ed0(16,596,688)
25010000 25011000 25fe7440 0x00fd6440(16,606,272)
274b0000 274b1000 284a4b18 0x00ff3b18(16,726,808)
2c4b0000 2c4b1000 2d4ac560 0x00ffb560(16,758,112)
2e4b0000 2e4b1000 2f47ddd0 0x00fccdd0(16,567,760)
2f4b0000 2f4b1000 304a3970 0x00ff2970(16,722,288)
304b0000 304b1000 314ad208 0x00ffc208(16,761,352)
08ce0000 08ce1000 09cd6d18 0x00ff5d18(16,735,512)
09ce0000 09ce1000 0accb370 0x00fea370(16,687,984)
0ace0000 0ace1000 0bc63c70 0x00f82c70(16,264,304)
0cd80000 0cd81000 0dd7f908 0x00ffe908(16,771,336)
0dd80000 0dd81000 0eba3a50 0x00e22a50(14,821,968)


0:000> !dumpheap -stat
total 141,545 objects
Statistics:

which produced a ton of objects in order of total size but the bottom part
is most useful I suspect i.e.

3379620 32,539 390,468
Tranmit.Sprinter.DataAccess.SQLDataAccess.SQLStaticDataStore
3379c3c 32,537 780,888 Tranmit.Sprinter.XMLBatchRecord
337bfcc 32,537 1,561,776
Tranmit.Sprinter.DataAccess.SQLDataAccess.SQLXMLBatchRecordData
95236c 127 7,808,984 System.Char[]
1501c8 801 76,190,256 Free
9526b0 438 116,192,444 System.Byte[]
79b94638 36,369 251,137,772 System.String
Total 141,545 objects
Click to expand...
 
Thanks Casey,

I've had some input on another group about the dump although I will explore
CLR profiler too. I've got a lot with lots of wonderful graphs ;) but can't
make head or tail of them yet!


Casey Kramer said:
I'm no good at figuring out memory dumps, but I have done my share of
diagnostic work when it comes to memory issues.

I highly recomment getting a memory profiler to help see the mamanged heap
allocations. You can use the free CLR Profiler
(http://www.microsoft.com/downloads/...52-d7f4-4aeb-9b7a-94635beebdda&displaylang=en)
or you could use a commercial profiler (.Net Memory Profiler is one, and
Red
Gate has their Ants profiler). With this you can see which object(s) are
using the most memory at a given time. There are also several Perf
counters
which you can use to see the allocation of the CLR managed heap (.Net CLR
Memory Performance Object Category). With these tools you can get an idea
of
what your application is doing.

There are a nice series of posts discussing the GC and managed heap health
at: http://blogs.msdn.com/maoni/default.aspx.

Hope this helps.

Casey

Matt Adamson said:
We have a .NET application which is obviously using nearly 500MB memory
and
we can't understand why. I created a dump for a different issue and the
server ended up creating a process shutdown dump of this size.

I have seen the DumpLargeObjectSegments command however I'm not sure what
to
look for next i.e. the output shows

0:000> !sos.dl
Loaded Son of Strike data table version 5 from
"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorwks.dll"
Going to dump the Large Object Segments.
Large object heap starts at 0x02071000
segment begin allocated size
02070000 02071000 02fbbf98 0x00f4af98(16,035,736)
0bd80000 0bd81000 0cd6f7c8 0x00fee7c8(16,705,480)
294b0000 294b1000 2a414908 0x00f63908(16,136,456)
1d010000 1d011000 1df65518 0x00f54518(16,074,008)
1e010000 1e011000 1ef99320 0x00f88320(16,286,496)
1f010000 1f011000 1ffd67a0 0x00fc57a0(16,537,504)
21010000 21011000 21fb4d48 0x00fa3d48(16,399,688)
23010000 23011000 23fe4ed0 0x00fd3ed0(16,596,688)
25010000 25011000 25fe7440 0x00fd6440(16,606,272)
274b0000 274b1000 284a4b18 0x00ff3b18(16,726,808)
2c4b0000 2c4b1000 2d4ac560 0x00ffb560(16,758,112)
2e4b0000 2e4b1000 2f47ddd0 0x00fccdd0(16,567,760)
2f4b0000 2f4b1000 304a3970 0x00ff2970(16,722,288)
304b0000 304b1000 314ad208 0x00ffc208(16,761,352)
08ce0000 08ce1000 09cd6d18 0x00ff5d18(16,735,512)
09ce0000 09ce1000 0accb370 0x00fea370(16,687,984)
0ace0000 0ace1000 0bc63c70 0x00f82c70(16,264,304)
0cd80000 0cd81000 0dd7f908 0x00ffe908(16,771,336)
0dd80000 0dd81000 0eba3a50 0x00e22a50(14,821,968)


0:000> !dumpheap -stat
total 141,545 objects
Statistics:

which produced a ton of objects in order of total size but the bottom
part
is most useful I suspect i.e.

3379620 32,539 390,468
Tranmit.Sprinter.DataAccess.SQLDataAccess.SQLStaticDataStore
3379c3c 32,537 780,888 Tranmit.Sprinter.XMLBatchRecord
337bfcc 32,537 1,561,776
Tranmit.Sprinter.DataAccess.SQLDataAccess.SQLXMLBatchRecordData
95236c 127 7,808,984 System.Char[]
1501c8 801 76,190,256 Free
9526b0 438 116,192,444 System.Byte[]
79b94638 36,369 251,137,772 System.String
Total 141,545 objects
Click to expand...
Click to expand...
 
Back
Top