With ps
or similar tools you will only get the amount of memory pages allocated by that process. This number is correct, but:
does not reflect the actual amount of memory used by the application, only the amount of memory reserved for it
can be misleading if pages are shared, for example by several threads or by using dynamically linked libraries
If you really want to know what amount of memory your application actually uses, you need to run it within a profiler. For example, Valgrind can give you insights about the amount of memory used, and, more importantly, about possible memory leaks in your program. The heap profiler tool of Valgrind is called 'massif':
Massif is a heap profiler. It performs detailed heap profiling by taking regular snapshots of a program's heap. It produces a graph showing heap usage over time, including information about which parts of the program are responsible for the most memory allocations. The graph is supplemented by a text or HTML file that includes more information for determining where the most memory is being allocated. Massif runs programs about 20x slower than normal.
As explained in the Valgrind documentation, you need to run the program through Valgrind:
valgrind --tool=massif <executable> <arguments>
Massif writes a dump of memory usage snapshots (e.g. massif.out.12345
). These provide, (1) a timeline of memory usage, (2) for each snapshot, a record of where in your program memory was allocated. A great graphical tool for analyzing these files is massif-visualizer. But I found ms_print
, a simple text-based tool shipped with Valgrind, to be of great help already.
To find memory leaks, use the (default) memcheck
tool of valgrind.
There is a good essay on this by Mark Russinovich.
You can manually reduce your app's working set by using the Win32 API call SetProcessWorkingSetSize(GetCurrentProcess(), -1, -1). This is what Windows will do anyway when the system runs low on memory, but controlling when this happens yourself lets you strip your .NET app's working set to its minimum size for investigation purposes.
Best Answer
My favourite tool has to be DevPartner though at £1,500 a pop it is not cheap. It does a hell of a lot more than Memory leak checking though, but if that's all you need you might be carpet bombing ants.
If you want to see if your app is releasing resources correctly, use this Function I wrote to dump the memory at a given location. I would first cache the addresses of each of your variables then at shutdown you could call the DumpVariableMemory passing in references to those locations to see if they have been deallocated.
If you don't have one already, you'll need to add a declare fopr CopyMemory too :)