views:

113

answers:

3

I'm working on a c# service application and i have this problem where out of no where and for no obvious reason, the memory for the process will climb from 150mb to almost 2gb in about 5 seconds and then back to 150mb. But nothing in our system should be using any where near that amount of memory (so its probably a bug somewhere). It might be a tight while true loop somewhere but the cpu usage at the time was very low so i thought i'd look for other ideas.

Now the weirder thing is when i compile the service for 64bit, the same massive burst will occur except it exceeded 10gb of ram (paging most of it) and it just caused lots of problems with the computer and everything running on it. After a while it shuts down but it looks like windows is still willing to give it more memory.

Would you have any ideas or tools that i can use in order to find this? Yes it has lots of logging however nothing in the logs stand out as to why this is happening.

I can run the service in a console app mode, so my next test was going to be running it in visual studio debugger and see if i can find anything.

It only happens occasionally but usually about 10-20 minutes after startup. On 32bit mode it cleans up and continues on like normally. 64bit mode it crashes after a while and uses stupid amounts of memory. But i'm really stumped as to why this is happening!!!

EDIT: Please see the commends to the windbg post

+1  A: 

You are doing a lot of allocation that then you release. Your memory builds up, until the GC kicks in and start cleaning after you. On amd64 platforms all structures are larger since pointers, v-tables and other structures are inherently double in size compared to x86.

The simplest solution is to run with the application under debugger and wait for the bulge, then freeze it and take a dump. Then analyze the dump:

.loadby sos mscorwks
!dumpheap -stat

Your leaked type will be on the top of the list, with lots of allocations. This is the same technique you'd use to analyze a memory leak, except that the memory is probably technically not leaked, see CLR Memory Leak.

Remus Rusanu
I'm trying this out now, how do i make windbg not stop on first chance exceptions and just run until i say pause?
Daniel
sxd <exeption>. eg. `sxd av` or `sxd eh` or `sxd clr`. The exception type to use will be printed when it stops.
Remus Rusanu
Ok brilliant, it is currently at 2gb of memory and i have stopped it, ran those commands and this is my problem: 000007fef9a4ec90 74179 1895994904 System.String74179 instances of System.Strings and its consuming 1.8gb of ram, how can i narrow down this further?
Daniel
When i do the !gcroot command and pass it 000007fef9a4ec90, nothing is found and it reads "Please note that 000007fef9a4ec90 is not a valid object"
Daniel
Ah whoops thats the wrong address lol
Daniel
Ok this was extremely helpful, i have now found where the problem resides! I'll have a look at the code to find out whats causing it, thanks so much!
Daniel
I have the same problem with "...is not a valid object". what address did you use? (i'm trying with addresses from the first column of !dumpheap -type System.String)
jgauffin
+2  A: 

You could try a profiler, like the CLRProfiler, a free download from MS (it's pretty cool). It can profile services. Run it until you see the memory spike, then stop it and look at the heap dump.

Charles
Ok thanks i'll give this a shot too
Daniel
A: 

Sounds like you may be doing string concatenation instead of using StringBuilder?

Dave Clemmer