Trying to figure out the process to debug these leaks...
Peeks
Posts: 5
Hi guys,
I've just found your product and so I'm giving it a trial run. We develop winform apps and this is one of our smaller products we thought we would test.
We're trying to understand how we should be using the product to help us find poor code that results in memory leaks. So, can someone confirm that our understanding about how we're using the product, is right?
----
First up, it just parses txt files and inserts them into a database. Running this quickly gets the process size up to a Gig+ It's obvious that something isn't getting released, etc. Simple candidate to start off
Second, we're using StructureMap for dependency injection. NLog for logging. Entity Framework for database stuff (with all DB stuff turned off, for this sampling).
In our initial profile, I took a baseline snapshot after the app started (30Mb process size .. no actions taking place). Ran it for a min until it hit 100Mb .. took a second snapshot and stopped. I got this idea from the slideshow help files
So it's pretty informative that - first up - it saying i have a lot of strings that aren't getting released? and then there some other stuff which i _think_ is related to NLog?
So i'm delving deaper and deaper to find some of these things.... to confirm what's going on...
This class list once more confirms some stuff... Strings are going mad .. and once more lots of NLog stuff
hmmm... It's also interesting to see some Net.Socket stuff in there. I think i've got NLog setup to work async? i wonder if this is why we're seeing lots of Socket stuff...
Now, this is where we're starting to get stuck.
This image shows us the Live Size (in bytes) of the objects that are taking up memory, right? If i'm looking at the string class, it's about 9.5MB. I can confirm this by going to the Class reference explorer. But my process is running at around 100Mb. so i don't get what I'm doing wrong.
Secondly, we seriously don't understand why NLog would not be releasing all this info. Is there a way we can see what is stopping it from being released?
One thing one of the team members suggested was that the Retention Graph might be the key here : what is keeping a hold on the strings?
so we checked this out. It's pretty damn kewl how this product allows us to drill down from top to bottom .. asumming we're using the product correctly.
So from here we're not sure what we can do .. suppose to do? Have we even used this right?
We might start another analysis with the Async turned off to compare things....
Thoughts anyone?
I've just found your product and so I'm giving it a trial run. We develop winform apps and this is one of our smaller products we thought we would test.
We're trying to understand how we should be using the product to help us find poor code that results in memory leaks. So, can someone confirm that our understanding about how we're using the product, is right?
----
First up, it just parses txt files and inserts them into a database. Running this quickly gets the process size up to a Gig+ It's obvious that something isn't getting released, etc. Simple candidate to start off
Second, we're using StructureMap for dependency injection. NLog for logging. Entity Framework for database stuff (with all DB stuff turned off, for this sampling).
In our initial profile, I took a baseline snapshot after the app started (30Mb process size .. no actions taking place). Ran it for a min until it hit 100Mb .. took a second snapshot and stopped. I got this idea from the slideshow help files
So it's pretty informative that - first up - it saying i have a lot of strings that aren't getting released? and then there some other stuff which i _think_ is related to NLog?
So i'm delving deaper and deaper to find some of these things.... to confirm what's going on...
This class list once more confirms some stuff... Strings are going mad .. and once more lots of NLog stuff
hmmm... It's also interesting to see some Net.Socket stuff in there. I think i've got NLog setup to work async? i wonder if this is why we're seeing lots of Socket stuff...Now, this is where we're starting to get stuck.
This image shows us the Live Size (in bytes) of the objects that are taking up memory, right? If i'm looking at the string class, it's about 9.5MB. I can confirm this by going to the Class reference explorer. But my process is running at around 100Mb. so i don't get what I'm doing wrong.
Secondly, we seriously don't understand why NLog would not be releasing all this info. Is there a way we can see what is stopping it from being released?
One thing one of the team members suggested was that the Retention Graph might be the key here : what is keeping a hold on the strings?
so we checked this out. It's pretty damn kewl how this product allows us to drill down from top to bottom .. asumming we're using the product correctly.
So from here we're not sure what we can do .. suppose to do? Have we even used this right?
We might start another analysis with the Async turned off to compare things....
Thoughts anyone?
Comments
Part 1:
http://www.youtube.com/watch?v=yZ8dC5nlhiY
Part 2:
http://www.youtube.com/watch?v=bcM6DoCV ... re=related
Regards,
Stephen
There's also a chance that large object heap fragmentation is contributing to your problems.
http://bit.ly/b9z0uu
Stephen
I already checked out those YT vids before so I could get an idea about how to use the product. I suppose I was just double checking that we were going through the process right.
The biggest take away item from the vids was from vid #2 .. about how it said we need to cut a reference to an object so the hierarchy can get GC'd.
Looking at the Renention graph, i was getting so confused because all the data kept pointing back to NLog. The strings were NLog related (connection strings, etc). The Net Socket stuff was also NLog related. It's like it was not releasing some network level code. Our assumption: NLog is ok, but my code is not. After all, NLog is a popular application that is being used by many, many people which suggests it's pretty stable, etc.
I kept thinking .. how can i make it so that those NLog delegates (which Memory Profiler 6 was showing me) could get disconnected/cut?
Until I thought for a second: is anyone else having a memory leak issue with NLog...
google points me to: http://github.com/jkowalski/NLog/commit ... d363ee4b95
Downloaded the latest nightly build and viola! memory leak gone.
Awesome work RedGate
Cheers
-PK-
Does NLog come with the source code? From the reference graph the objects with bolded black text indicate so. Is this correct?
At any rate, glad you have managed to get rid of the memory leak. They can be very annoying to say the least.
S