{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.manongdao.com/data/attach/logo/logo.png', '推荐 旧时光的记忆 的问题《How to measure actual memory usage of an applicati》','https://www.manongdao.com/q-4128.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
This question is covered here in great detail.
How do you measure the memory usage of an application or process in Linux?
From the blog article of Understanding memory usage on Linux, ps is not an accurate tool to use for this intent.
Why
psis "wrong"Depending on how you look at it,
psis not reporting the real memory usage of processes. What it is really doing is showing how much real memory each process would take up if it were the only process running. Of course, a typical Linux machine has several dozen processes running at any given time, which means that the VSZ and RSS numbers reported bypsare almost definitely wrong.
With
psor 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,
valgrindcan 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':As explained in the valgrind documentation, you need to run the program through valgrind:
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 foundms_print, a simple text-based tool shipped with valgrind, to be of great help already.To find memory leaks, use the (default)
memchecktool of valgrind.Check shell script to check memory usage by application in linux. Also available on github and in a version without paste and bc.
Use smem, which is an alternative to ps which calculates the USS and PSS per process. What you want is probably the PSS.
USS - Unique Set Size. This is the amount of unshared memory unique to that process (think of it as U for unique memory). It does not include shared memory. Thus this will under-report the amount of memory a process uses, but is helpful when you want to ignore shared memory.
PSS - Proportional Set Size. This is what you want. It adds together the unique memory (USS), along with a proportion of its shared memory divided by the number of other processes sharing that memory. Thus it will give you an accurate representation of how much actual physical memory is being used per process - with shared memory truly represented as shared. Think of the P being for physical memory.
How this compares to RSS as reported by ps and other utilties:
Notice: smem can also (optionally) output graphs such as pie charts and the like. IMO you don't need any of that. If you just want to use it from the command line like you might use ps -A v, then you don't need to install the python-matplotlib recommended dependency.
Use this as root and you can get a clear output for memory usage by each process.
OUTPUT EXAMPLE:
Below command line will give you the total memory used by the various process running on the Linux machine in MB
A good test of the more "real world" usage is to open the application, then run
vmstat -sand check the "active memory" statistic. Close the application, wait a few seconds and runvmstat -sagain. However much active memory was freed was in evidently in use by the app.