0

(I'm new to Linux)

Say I've 1300 MB memory, on a Ubuntu machine. OS and other default programs consumes 300 MB memory and 1000 MB is free for my own applications.

I installed my application and I could configure it to use 700 MB memory, when the application starts.

However I couldn't verify its actual memory usage. Even I disabled swap space.

The "VIRT" value shows a huge value and "RES", "SHR", "%MEM" shows very less value.

It is difficult to find actual physical memory usage, similar to "Resource monitor" in Windows, which will say my application is using 700 MB memory.

Is there any way to find actual physical memory in Ubuntu/Linux ?

user1102285
  • 13
  • 2
  • Most memory information is available by `cat /proc/meminfo`. Take that with a grain-of-salt. All applications use "virtual" memory, so the amount of "physical" RAM used at any one given point in time is the measure you are after. Virtual memory management is far more sophisticated than a comment can contain, but even at the application level, not all reserved memory is in use. [What does Virtual memory size in top mean?](https://serverfault.com/q/138427/332034) is a good place to start. – David C. Rankin Jul 05 '20 at 03:17

1 Answers1

-1

TL;DR - Virtual memory is complicated.

The best measure of a Linux processes current usage of physical memory is RES.

The RES value represents the sum of all of the processes pages that are currently resident in physical memory. It includes resident code pages and resident data pages. It also includes shared pages (SHR) that are currently RAM resident, though these pages cannot be exclusively ascribed to >>this<< process.

The VIRT value is actually the sum of all notionally allocated pages for the process, and it includes pages that are currently RAM resident, pages that are currently swapped to disk.

See https://stackoverflow.com/a/56351211/1184752 for another explanation.

Note that RES is giving you (roughly) instantaneous RAM usage. That is what you asked about ...

The "actual" memory usage over time is more complicated because the OS's virtual memory subsystem is typically be swapping pages in and out according to demand. So, for example, some of your application's pages may not have been accesses recently, and the OS may then swap them out (to swap space) to free up RAM for other pages required by your application ... or something else.

The VIRT value while actually representing virtual address space, is a good approximation of total (virtual) memory usage. However, it may be an over-estimate:

  • Some pages in a processes address space are shared between multiple processes. This includes read-only code segments, pages shared between parent and child processes between vfork and exec, and shared memory segments created using mmap.

  • Some pages may be set to have illegal access (e.g. for stack red-zones) and may not be backed by either RAM or swap device pages.

  • Some pages of the address space in certain states may not have been committed to either RAM or disk yet ... depending on how the virtual memory system is implemented. (Consider the case where a process requests a huge memory segment and neither reads from it or writes to it. It is possible that the virtual memory implementation will not allocate RAM pages until the first read or write in the page. And if you use lazy swap reservation, swap pages not be committed either. But beware that you can get into trouble with lazy swap reservation.)

VIRT can also be under-estimate because the OS usually reserves swap space for all pages ... whether they are currently swapped in or swapped out. So if you count the RAM and swap versions of a given page as separate units of storage, VIRT usually underestimates the total storage used.

Finally, if your real goal is to limit your application to using at most 700 MB (of virtual address space) then you can use ulimit -v ... to do this. If the application tries to request memory beyond its limit, the request fails.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • `VIRT` is rarely a good measure of total memory usage. This includes the whole reserved virtual address space - here is a good answer from apanging mentioning that: https://stackoverflow.com/a/56351211/1184752 – Juraj Martinka Jul 09 '20 at 06:31
  • It depends on what you mean by memory. If you mean virtual memory, then it is a good measure. The context of this is that the OP talks about the "memory" he has configured the application to use, and the "physical memory" it is actually using. Given that a non-root user cannot control physical memory usage of processes, I am making the reasonable assumption that the OP is using "memory" to mean "virtual memory". – Stephen C Jul 09 '20 at 07:03
  • They mention "actual physical memory usage" which is very different from VIRT in pretty much all cases. Saying otherwise is quite confusing. – Juraj Martinka Jul 09 '20 at 07:30
  • They *also* mention "configure it to use 700 MB memory" which must be virtual memory since it is impossible to configure physical RAM usage. Please read my entire answer and don't cherry pick sentences and take them out of context. – Stephen C Jul 09 '20 at 07:36
  • And note that I have already changed the answer to say *"The VIRT value is the best measure of total (**virtual**) memory usage."* – Stephen C Jul 09 '20 at 07:38
  • I read it before and now read it again. I still think it's misleading. You say VIRT is the best measure of total virtual memory _usage_ which is incorrect - it's the total size of reserved virtual address space (see the link I mentioned - there are lots of other answers mentioning this as well). You also say that you don't know if it includes _virtual address space_ (which it does). You say that it's more complicated because OS can swap pages in/out but VIRT is more than just rss + swap. – Juraj Martinka Jul 09 '20 at 08:00
  • Perhaps you should write your own answer. I would be interested to understand the distinction you are making between "virtual memory usage" and "total size of reserved virtual address space". To me they are the same thing. – Stephen C Jul 09 '20 at 09:24