0

The amount of memory used by my program reported by top is more than twice the amount reported in /proc/[pid]/statm. What explains this difference?

JPi
  • 127
  • 6

1 Answers1

3

From the "man" page:

https://man7.org/linux/man-pages/man5/proc.5.html

/proc/[pid]/statm
Provides information about memory usage, measured in pages.  
The columns are:

        size       (1) total program size
                   (same as VmSize in /proc/[pid]/status)
        resident   (2) resident set size
                   (inaccurate; same as VmRSS in /proc/[pid]/status)
        shared     (3) number of resident shared pages
                   (i.e., backed by a file)
                   (inaccurate; same as RssFile+RssShmem in
                   /proc/[pid]/status)
        text       (4) text (code)
        lib        (5) library (unused since Linux 2.6; always 0)
        data       (6) data + stack
        dt         (7) dirty pages (unused since Linux 2.6; always 0)

Some of these values are inaccurate because of a kernel-
internal scalability optimization.  If accurate values are
required, use /proc/[pid]/smaps or
/proc/[pid]/smaps_rollup instead, which are much slower
but provide accurate, detailed information.

ALSO: VMsize is the "address space" that the process has in use: the number of available adresses. These addresses do not have to have any physical memory attached to them. Attached physical memory is the RSS figure.

Q: So what specific values did you have questions about?


Please see my comments below, and please refer to these links:

Short answer:

  • RES in top (RSS is ps), this is the sum of memory that is mapped to physical pages of memory.
  • VMsize is the "address space" that the process has in use: the number of available adresses.
  • "VMSize" addresses do not (necessarily) have any physical memory attached to them.
  • Attached physical memory ("Resident memory") is the RSS figure.

It would also be helpful to see your actual values from top, /proc/nnn/stat and from ps.


Here's a great article (one of many):

Process Memory Management in Linux - Baeldung.com

  • VSZ Memory

    VSZ is short for Virtual Memory Size. It’s the total amount of memory a process may hypothetically access.

    It accounts for the size of the binary itself, any linked libraries, and any stack or heap allocations.

    When a process is started, VSZ memory becomes RSS memory...

  • RSS Memory

    As opposed to VSZ, RSS, also short for Resident Set Size, is a measurement that shows how much RAM has been allocated to a process during its execution

    But, it isn’t actually an accurate measurement for RAM usage for a process since it doesn’t take into account libraries already loaded in memory...

    Because RSS shows the whole memory output, even for information that has already been preloaded, if we add up everything in the processes list, we’d get more memory than the total memory allocated.

I hope that all helps ... at least a little.

If you've still got questions, please copy/paste some actual values from your system, so we can discuss specific examples.

paulsm4
  • 114,292
  • 17
  • 138
  • 190
  • Sorry for being incomplete. I was referring to the "size" column of statm versus the RES column of top. – JPi Feb 21 '22 at 21:19
  • BASIC PROBLEM: it sounds like you're comparing apples to oranges. "/proc/xxx/statm" reports multiple different statistics (including "size", which refers to "VMSize"); "top" reports different (related, but different) "memory" statistics. The different numbers refer to different things. SUGGESTIONS: 1) Look here: https://man7.org/linux/man-pages/man1/top.1.html, here: https://man7.org/linux/man-pages/man5/proc.5.html and here: https://stackoverflow.com/a/13309395/421195. 2) [Edit] your post, copy/paste the top and statm values, 3) Specify which values you're unclear about. – paulsm4 Feb 21 '22 at 22:05
  • I don't know if your question is answered or not. If not, please see my latest update, pertaining to this article: https://www.baeldung.com/linux/process-memory-management – paulsm4 Feb 23 '22 at 20:32