This question is locked. New answers and comments are not allowed.
Hi
I have an application that has a slow memory leak that I'd like to plug so I'm looking at memory profilers. I've previously used ANTS which seems to leave my app alone running at its normal speed. If I run my app from JustTrace though, execution comes down a crawl.. mere initialization takes half a minute instead of seconds, and since the whole thing is a server for real-time clients and it gets information in real time, working that slow means I cannot really be sure the app even works as intended anymore.
Is there a handbrake I need to release somewhere? Also.. what is JustTrace looking for when attaching to an already running process? What debugging tools for windows?
I have an application that has a slow memory leak that I'd like to plug so I'm looking at memory profilers. I've previously used ANTS which seems to leave my app alone running at its normal speed. If I run my app from JustTrace though, execution comes down a crawl.. mere initialization takes half a minute instead of seconds, and since the whole thing is a server for real-time clients and it gets information in real time, working that slow means I cannot really be sure the app even works as intended anymore.
Is there a handbrake I need to release somewhere? Also.. what is JustTrace looking for when attaching to an already running process? What debugging tools for windows?
5 Answers, 1 is accepted
0
Hello Stephan,
Memory profiler can significantly slow down your application if you enable Collect allocation call stacks. We also added an Accurate object age option which will be available in the next internal build (which is scheduled for next week). Unfortunately in the SP1 release it is unavailable and always turned ON. This generally shouldn't be a problem, but it could incur a significant performance hit if the profiled application has a large heap and frequently triggers GCs. If your app does many GCs only during initialization it should be running at near full speed afterwards.
When attaching to a running process with memory profiler, JustTrace uses the console debugger which ships with Debugging Tools for Windows. You need to install the x86 and/or x64 versions depending on what kind of applications you want to attach to. Debugging Tools are distributed as part of the Windows SDK. You can download it from here. In this mode no profiler is attached to the application, only the debugger and only while getting a snapshot. You should be able to profile your application without impacting its performance in this way.
All the best,
Martin
the Telerik team
Memory profiler can significantly slow down your application if you enable Collect allocation call stacks. We also added an Accurate object age option which will be available in the next internal build (which is scheduled for next week). Unfortunately in the SP1 release it is unavailable and always turned ON. This generally shouldn't be a problem, but it could incur a significant performance hit if the profiled application has a large heap and frequently triggers GCs. If your app does many GCs only during initialization it should be running at near full speed afterwards.
When attaching to a running process with memory profiler, JustTrace uses the console debugger which ships with Debugging Tools for Windows. You need to install the x86 and/or x64 versions depending on what kind of applications you want to attach to. Debugging Tools are distributed as part of the Windows SDK. You can download it from here. In this mode no profiler is attached to the application, only the debugger and only while getting a snapshot. You should be able to profile your application without impacting its performance in this way.
All the best,
Martin
the Telerik team
0
Stephan
Top achievements
Rank 1
Rank 1
answered on 13 Mar 2013, 10:41 AM
Hi Martin
I forgot to mention - I'm not using any of the optional options you can turn on when starting a session, so [b]Collection allocation call stacks[b] is not active.
My app indeed triggers frequent GCs (the most memory consuming operation I have is a webservice call that loads a few MBs of data every few minutes.. and I've found it to take really long to free up the memory again (can be longer than the next webservice call), so it just kept piling on memory and to more reliably judge memory usage I figure I'd kick it in the butt once I've processed the loaded data). But other than that, one GC.collect call during initialization is all there is.
There's quite a bit of objects on the heap - there's information that is dynamic and must be accessible without expensive lookups.
Where I'm still puzzled is for the Windows Debugging Tools - this may be clear to somebody familiar with those tools - but the setup you linked to (and the Win7 SDK that I already have installed since its a W2008R2 machine), installs the 64bit tool since the OS is 64bit... but my app is 32bit (I do W32 interop with a 32bit DLL from a third party.. and they don't offer a 64bit version) - and I have no clue how I can get those 32bit debug tools. I think I'm on the way now but need to uninstall the SDK, then chose a different setup mode where I can extract the MSIs. The process is so convoluted though that I think it would deserve a help page.
Stephan
@edit: for those in the same boat as me, when you install the SDK and are being asked to install or download for another machine, select the latter. Then make sure you the debugging tools are checked so they will be downloaded.You'll then find the installers you're looking for in "Windows Kits\8.0\StandaloneSDK\Installers" under your User folder (if you didn't change the "installation" folder). The files are called X64 Debuggers And Tools-x64_en-us.msi and X86 Debuggers And Tools-x86_en-us.msi respectively, and they install to C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x86 and C:\Program Files\Debugging Tools for Windows (x64) respectively.
@Martin: Do I miss anything if I attach instead of run the app from within JustTrace if I'm just after the memory? And is JustTrace supposed to eat 2 GB of memory when my app uses 260MB worth of private bytes?
I forgot to mention - I'm not using any of the optional options you can turn on when starting a session, so [b]Collection allocation call stacks[b] is not active.
My app indeed triggers frequent GCs (the most memory consuming operation I have is a webservice call that loads a few MBs of data every few minutes.. and I've found it to take really long to free up the memory again (can be longer than the next webservice call), so it just kept piling on memory and to more reliably judge memory usage I figure I'd kick it in the butt once I've processed the loaded data). But other than that, one GC.collect call during initialization is all there is.
There's quite a bit of objects on the heap - there's information that is dynamic and must be accessible without expensive lookups.
Where I'm still puzzled is for the Windows Debugging Tools - this may be clear to somebody familiar with those tools - but the setup you linked to (and the Win7 SDK that I already have installed since its a W2008R2 machine), installs the 64bit tool since the OS is 64bit... but my app is 32bit (I do W32 interop with a 32bit DLL from a third party.. and they don't offer a 64bit version) - and I have no clue how I can get those 32bit debug tools. I think I'm on the way now but need to uninstall the SDK, then chose a different setup mode where I can extract the MSIs. The process is so convoluted though that I think it would deserve a help page.
Stephan
@edit: for those in the same boat as me, when you install the SDK and are being asked to install or download for another machine, select the latter. Then make sure you the debugging tools are checked so they will be downloaded.You'll then find the installers you're looking for in "Windows Kits\8.0\StandaloneSDK\Installers" under your User folder (if you didn't change the "installation" folder). The files are called X64 Debuggers And Tools-x64_en-us.msi and X86 Debuggers And Tools-x86_en-us.msi respectively, and they install to C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x86 and C:\Program Files\Debugging Tools for Windows (x64) respectively.
@Martin: Do I miss anything if I attach instead of run the app from within JustTrace if I'm just after the memory? And is JustTrace supposed to eat 2 GB of memory when my app uses 260MB worth of private bytes?
0
Hi Stephan,
Regardless of the fact that you call GC.Collect only once the garbage collector can trigger numerous collections on its own. Even Gen0 collections are slowed down due to the missing option being turned ON. To verify if this is the case you can take a look at the # Gen0 GC counter in the Metrics view after initialization of the application is finished.
I am glad that you managed to install Debugging Tools. Indeed it is a bit confusing to download it this way, but I it seems that Microsoft does not provide a direct download link.
What is missing in attach mode:
the Telerik team
Regardless of the fact that you call GC.Collect only once the garbage collector can trigger numerous collections on its own. Even Gen0 collections are slowed down due to the missing option being turned ON. To verify if this is the case you can take a look at the # Gen0 GC counter in the Metrics view after initialization of the application is finished.
I am glad that you managed to install Debugging Tools. Indeed it is a bit confusing to download it this way, but I it seems that Microsoft does not provide a direct download link.
What is missing in attach mode:
- Static variable names and field names in Paths to GC Roots diagrams
- Object tracking information: object age and objects status in comparisons (new, survived, collected)
- Allocation call trees
- The snapshots will not be saved for later
Yes, indeed JustTrace can use a lot more memory for the snapshot information than is the working set of the profiled application. This depends on the complexity of the memory object graph.
All the best,
the Telerik team
0
Stephan
Top achievements
Rank 1
Rank 1
answered on 20 Mar 2013, 09:18 AM
I do have plenty of Gen 0 GC. Will there be an additional update where that hidden option becomes accessible again?
I think there's an issue saving the debugger paths but I just opened a ticket.
Is there a way I can see the contents of an object? I have a large number (about 50 MB worth) of strings - I know using WCF webservice stubs creates a lot of those but seeing the content might help me determine where those strings come from.
Regards
Stephan
I think there's an issue saving the debugger paths but I just opened a ticket.
Is there a way I can see the contents of an object? I have a large number (about 50 MB worth) of strings - I know using WCF webservice stubs creates a lot of those but seeing the content might help me determine where those strings come from.
Regards
Stephan
0
Hello Stephan,
The internal build with the Accureate object age option has been released on March 18. To download it you can check for updates from inside JustTrace. Just go to the Help & Support page and click the KEEP UP TO DATE button.
Currently JustTrace cannot show you the contents of objects. We have this feature in our backlog but it has not been given high priority for now.
What you can do is check the Paths to GC Roots diagrams of individual objects and see what keeps them alive -- this can give you a hint where those objects come from. If you suspect a memory leak you can compare two snapshots (from before and after the action which causes the leak) and examine only the objects with status New in the Instances Diff view.
I hope this helps you resolve your issues. If you need further assistance, please do not hesitate to contact us again!
Kind regards,
Martin
the Telerik team
The internal build with the Accureate object age option has been released on March 18. To download it you can check for updates from inside JustTrace. Just go to the Help & Support page and click the KEEP UP TO DATE button.
Currently JustTrace cannot show you the contents of objects. We have this feature in our backlog but it has not been given high priority for now.
What you can do is check the Paths to GC Roots diagrams of individual objects and see what keeps them alive -- this can give you a hint where those objects come from. If you suspect a memory leak you can compare two snapshots (from before and after the action which causes the leak) and examine only the objects with status New in the Instances Diff view.
I hope this helps you resolve your issues. If you need further assistance, please do not hesitate to contact us again!
Kind regards,
Martin
the Telerik team