Thus this will under-report the amount of memory a process uses, but it is helpful when you want to ignore shared memory. This is the amount of unshared memory unique to that process (think of it as U for unique memory). Use smem, which is an alternative to ps which calculates the USS and PSS per process. Ps -eo size,pid,user,command -sort -size | \Īwk ' To find memory leaks, use the (default) memcheck tool of valgrind. But I found ms_print, a simple text-based tool shipped with Valgrind, to be of great help already. A great graphical tool for analyzing these files is massif-visualizer. These provide, (1) a timeline of memory usage, (2) for each snapshot, a record of where in your program memory was allocated. Massif writes a dump of memory usage snapshots (e.g. Massif runs programs about 20x slower than normal.Īs explained in the Valgrind documentation, you need to run the program through Valgrind: valgrind -tool=massif The graph is supplemented by a text or HTML file that includes more information for determining where the most memory is being allocated.
It produces a graph showing heap usage over time, including information about which parts of the program are responsible for the most memory allocations.
It performs detailed heap profiling by taking regular snapshots of a program's heap. The heap profiler tool of Valgrind is called 'massif': For example, Valgrind can give you insights about the amount of memory used, and, more importantly, about possible memory leaks in your program. If you really want to know what amount of memory your application actually uses, you need to run it within a profiler. This number is correct, but:ĭoes not reflect the actual amount of memory used by the application, only the amount of memory reserved for itĬan be misleading if pages are shared, for example by several threads or by using dynamically linked libraries With ps or similar tools you will only get the amount of memory pages allocated by that process.
0 kommentar(er)
