LinuxQuestions.org - Why is VSZ more than RSS in ps aux even if I'm not using any swap?

- Linux - Hardware (https://www.linuxquestions.org/questions/linux-hardware-18/)

- - Why is VSZ more than RSS in ps aux even if I'm not using any swap? (https://www.linuxquestions.org/questions/linux-hardware-18/why-is-vsz-more-than-rss-in-ps-aux-even-if-im-not-using-any-swap-663109/)

Why is VSZ more than RSS in ps aux even if I'm not using any swap?

Hi,

Many entries displayed by ps aux show that the virtual memory (VSZ) used higher than the real amount of RAM for many processes. For example:

Code:

USER      PID %CPU %MEM    VSZ  RSS TTY      STAT START  TIME COMMAND

root        1  0.0  0.0  1584  536 ?        Ss  10:43  0:00 init [3]

However, I'm not using any swap:

Code:

            total      used      free    shared    buffers    cached

Mem:          881        527        353          0        19        190

-/+ buffers/cache:        317        564

Swap:          980          0        980

Why is this happening?

Thanks!

Look at this link:
http://www.mozilla.org/projects/foot...int-guide.html

Quote:

RSS:
Resident set size = the non-swapped physical memory that a task has used; Resident Set currently in physical memory including Code, Data, Stack

VSZ:
Virtual memory usage of entire process = VmLib + VmExe + VmData + VmStk

To put it differently:
http://www.memorymanagement.org/glossary/r.html

Quote:

resident set

In a virtual memory(1) system, a process' resident set is that part of a process' address space which is currently in main memory. If this does not include all of the process' working set, the system may thrash.

In other words,
a) VSZ *includes* RSS
b) "ps -aux" alone isn't enough to tell you if a process is thrashing (although, if your system *is* thrashing, "ps -aux" will help you identify the processes experiencing the biggest hits).

'Hope that helps .. PSM

I suspect the OP is aware of basic virtual storage concepts - hence the question.
Most of the (unaccounted) virtual will be for the shared libraries - that is handled via the page cache. Swap is only used for (dirty) anonymous pages. Probably being contained within the swap cache, without need to be actually swapped to disk.
Init is a bad example to look at BTW - have a look at a userspace process - /proc/<pid>/smaps will be helpful.

sorry that I hijack your thread; but I have a similar problem and i do not understand.

weijie90,

from your thread post; i dont know if the data are both in kbs or megs. Top usually display data in kbs, and free typically in kbs. but saying that you have 881 kbs in your system is impossible. So i assume that you have 881megs of ram space total. which makes sense, your application only uses 1.584 meg of virtual memory.

Well, my problem is, my process memory is more than my RAM memory given that I do not use any disk swap memory. Can this be possible. Here is an illustration:

Free mem in Kbs

total used free shared buffers
Mem: 118648 61824 56824 0 3204
Swap: 0 0 0
Total: 118648 61824 56824

------------------------------------------------------------------------------

memory used by application :

Load average: 0.81 0.77 0.71
PID USER STATUS VSZ PPID %CPU %MEM COMMAND
22018 root S 150M 3244 0.1130.1 xpod

-------------------------------------------------------------------------------

Memory status of application:

State: S (sleeping)
SleepAVG: 98%
Tgid: 22018
Pid: 22018
PPid: 3244
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 256
Groups:
VmPeak: 155552 kB
VmSize: 154528 kB
VmLck: 0 kB
VmHWM: 3744 kB
VmRSS: 3744 kB
VmData: 150372 kB
VmStk: 84 kB
VmExe: 664 kB
VmLib: 2844 kB
VmPTE: 88 kB
Threads: 13

Question: Why is my application using 150megs of memory while I only have 128megs of ram on my computer total?

Thank you

Such are the joys of "virtual" - nothing is as it seems. Applications ask for ridiculous amounts of storage, and users expect them to work. It's only when data is actually written to a page that anyone starts to care.
For example, on my latop: /proc/meminfo/
VmallocTotal: 34359738367 kB

I wish ...