ASP.Net Worker Process Memory Profile Tools

James picture James · Jun 12, 2009 · Viewed 12.5k times · Source

We have a fairly high volume ASP.Net site written in c# using MS commerce server, running in a 32-bit environment. I see the worker process up to 980 megabytes quite often. I would like to profile this process and determine where any gains could be made in code to reduce the memory foot print of this site. My question what tools have worked well for you doing this sort of thing on ASP.Net web applications?

I am looking for tools that will give me very specific feedback, that will really help to clearly see what needs to change in the code. It would be best if this tool could profile our production environment worker process for a more concrete set of data to compare.

[edit]

So far it seems the consensus is that it's a toss up between Ants and JetBrains. Has anyone used both? If so which one was superior, or what are the pros and cons of each?

Answer

Alex from Jitbit picture Alex from Jitbit · Jun 6, 2017

There's a free way.

  • launch the task manager
  • right-click the w3wp process
  • select "create dump" (I'm amazed how few people know about this feature - including myself at some point!)
  • copy the dump file to your local machine (so we don't bother the production server)
  • open the file in Visual Studio
  • enjoy
  • select "Debug Managed memory" for advanced view which class uses memory etc.

AFAIK, the above requires Visual Studio "Ultimate" edition (I guess its called "Enterprise" now?). If you don't have one, then follow these steps (very simple too)

  • launch WinDbg (free tool, part of Windows SDK, there are tons of answers here on StackOverflow on how to download WinDbg without all the SDK bloatware)
  • Press Ctrl + D and load the dump file into WinDbg
  • type .loadby sos clr (this will load SOS.dll that allows WinDbg to analyze .NET processes, SOS.dll is a part of NET Framework so you probably already have it)
  • type !dumpheap -stat (this will output the class names, sorted by memory usage, ascending order. Skip system.string and system.byte[] classes cause these are side-effects, not the cause...)

UPDATE FROM 2019: WinDbg is now available via MS Store, just search for "WinDbg", then couple of clicks and its there.