linux - [Solved-6 Solutions] How to measure actual memory usage of an application or process ? - ubuntu - red hat - debian - linux server - linux pc

Linux - Problem :

How to measure actual memory usage of an application or process ?

Linux - Solution 1 :

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>

click below button to copy the code. By - Linux tutorial - team

Linux - Solution 2 :

Try the pmap command:

sudo pmap -x <process pid>

click below button to copy the code. By - Linux tutorial - team

Linux - Solution 3:

$ ps aux

click below button to copy the code. By - Linux tutorial - team

It will give you Virtual Size (VSZ)

You can also get detailed stats from /proc file-system by going to /proc/$pid/status

The most important is the VmSize, which should be close to what ps aux gives.

/proc/19420$ cat status
Name:   firefox
State:  S (sleeping)
Tgid:   19420
Pid:    19420
PPid:   1
TracerPid:  0
Uid:    1000    1000    1000    1000
Gid:    1000    1000    1000    1000
FDSize: 256
Groups: 4 6 20 24 25 29 30 44 46 107 109 115 124 1000 
VmPeak:   222956 kB
VmSize:   212520 kB
VmLck:         0 kB
VmHWM:    127912 kB
VmRSS:    118768 kB
VmData:   170180 kB
VmStk:       228 kB
VmExe:        28 kB
VmLib:     35424 kB
VmPTE:       184 kB
Threads:    8
SigQ:   0/16382
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000020001000
SigCgt: 000000018000442f
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
Cpus_allowed:   03
Mems_allowed:   1
voluntary_ctxt_switches:    63422
nonvoluntary_ctxt_switches: 7171

click below button to copy the code. By - Linux tutorial - team

Linux - Solution 4:

In recent versions of linux, use the smaps subsystem. For example, for a process with a PID of 1234:

cat /proc/1234/smaps

click below button to copy the code. By - Linux tutorial - team

It will tell you exactly how much memory it is using at that time. More importantly, it will divide the memory into private and shared, so you can tell how much memory your instance of the program is using, without including memory shared between multiple instances of the program.

Linux - Solution 5:

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:

RSS - Resident Set Size. This is the amount of shared memory plus unshared memory used by each process. If any processes share memory, this will over-report the amount of memory actually used, because the same shared memory will be counted more than once - appearing again in each other process that shares the same memory. Thus it is fairly unreliable, especially when high-memory processes have a lot of forks - which is common in a server, with things like Apache or PHP(fastcgi/FPM) processes.

Linux - Solution 6:

$ /usr/bin/time --verbose ls
(...)
Command being timed: "ls"
User time (seconds): 0.00
System time (seconds): 0.00
Percent of CPU this job got: 0%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 2372
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 1
Minor (reclaiming a frame) page faults: 121
Voluntary context switches: 2
Involuntary context switches: 9
Swaps: 0
File system inputs: 256
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0