|
Oct
04
|
VIRT stands for the virtual size of a process, which is the sum of memory it is actually using, memory it has mapped into itself (for instance the video card’s RAM for the X server), files on disk that have been mapped into it (most notably shared libraries), and memory shared with other processes. VIRT represents how much memory the program is able to access at the present moment.
RES stands for the resident size, which is an accurate representation of how much actual physical memory a process is consuming. (This also corresponds directly to the %MEM column.) This will virtually always be less than the VIRT size, since most programs depend on the C library.
SHR indicates how much of the VIRT size is actually sharable (memory or libraries). In the case of libraries, it does not necessarily mean that the entire library is resident. For example, if a program only uses a few functions in a library, the whole library is mapped and will be counted in VIRT and SHR, but only the parts of the library file containing the functions being used will actually be loaded in and be counted under RES.
August 4th, 2010 at 5:11 pm
I’ve been asked this question on many job interviews and have seen it asked many times and have since started asking it when I interview people. Many people don’t have a clear understanding of these differences. Your article summed it up in a very clean, straight forward manner. Thanks!
November 4th, 2010 at 4:34 pm
Thank you! Very useful and clear
January 27th, 2011 at 4:50 am
Hold on so are you saying that this:
22120 apache 15 0 317m 31m 4468 S 0.0 1.8 0:00.69 httpd
means one apache http request is using 317MB of ram total and 31MB allocated to the httpd request?
That seems like alot!
:0
May 16th, 2011 at 3:19 pm
how about DATA and CODE? and why DATA + CODE RES?
September 2nd, 2011 at 3:07 am
thanks a lot! 🙂
September 20th, 2011 at 5:52 pm
Zane Kolnik has an interesting question i’m trying to find the answer to. Those columns, RES, VIRT and SHR sometimes have the ‘m’ character appended to the end of the value; does this mean “million” or “megebytes”? none of those sounds right. the man page says those values are in kb, but 317’million’ kb doesn’t make sense.
September 28th, 2011 at 9:49 am
maxl: The ‘m’ stands for ‘mega’. (Note the ‘a’ at the end.)
If you have a process take up enough memory, it will have a ‘g’ as the suffix, as in ‘giga’.
October 4th, 2011 at 1:24 pm
SHR in fact doesn’t reliably show how much of VIRT is shareable, as it doesn’t account for the IPC mechanism called shared memory (SHM). This gives a huge error for example with “postgres” processes, where most of VIRT is taken by the big chunk of writable shared memory that all “postgres” processes share. So, if you have a connection pool of 4 connections, you will constantly see 4 “postgres” processes, each with, let’s say, 50 MB of VIRT size and only 5M of SHR, and you believe these then eat up (50 VIRT – 5 SHR) * 4 = 180 MB-s, where in fact they only eat up (50 VIRT – 38 SHM – 5 SHR) * 4 + 38 SHM = 66 MB.
(BTW, this reply form is a crap. Not only it doesn’t re-fill the form for you when there’s something to fix, when stepping back after the error message it somehow manages to prevent FireFox from restoring its earlier content…)
January 31st, 2012 at 8:10 pm
Nice review. Does the VIRT column corresponds to the Memory cached and buffer size?
April 5th, 2012 at 7:14 pm
I don’t observe as you said in your brief…
top – 22:17:11 up 3 days, 8:55, 3 users, load average: 3.27, 2.97, 2.73
Tasks: 357 total, 1 running, 356 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3%us, 0.2%sy, 0.0%ni, 99.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32948176k total, 22265536k used, 10682640k free, 444016k buffers
Swap: 0k total, 0k used, 0k free, 15811124k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8184 root 20 0 198m 30m 2668 S 1 0.1 11:20.61 ovldMgr
15 root 20 0 0 0 0 S 0 0.0 0:35.87 softirq-timer/1
4817 mysql 20 0 2066m 443m 7236 S 0 1.4 49:47.21 mysqld
6713 root 20 0 35476 5924 1012 S 0 0.0 73:54.90 mlogd
7294 root 20 0 1436m 1.1g 3492 S 0 3.5 4:26.07 mcmserver
See what I observe for mcmserver (its an app) …so what g represents in 1.1g, gigabytes?? Then your second point is not valid..right. I need to know what does it actually represents as even with this memory usage I dont see any difference in the this app works
May 22nd, 2012 at 7:01 pm
re newer kernels I beleive it still is a problem. Nevertheless it would be good to test yourself if you have access to a many-core box.joe it would be very interesting to see if this is what you’re bumping into. Can you try some of the tests I outlined on that web page?I too thought it was a numa issue but I think it’s more of an issue handling all the locking on the different memory sections one needs to traverse with a lot of cores. While it turns out you can’t have a lot of cores without a lot of sockets and hence NUMA, it’s not really the numa code that is doing this. At least that’s my understanding.-mark
January 28th, 2013 at 10:26 am
Hi all,
I have program, when i run it and check using top command that have some info:
PID USER PR NI VIRT RES SHR S %CPU %MEM
3723 root 20 0 21.8g 316m 13m S 0.0 1.0
I run in: Linux localhost.localdomain 2.6.32-300.3.1.el6uek.x86_64 #1 SMP Fri Dec 9 18:57:35 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
With 32g memory.
Show i think the VIRT so Big, can have any one give me some suggesstion.
Thank & Regards
April 11th, 2013 at 8:16 am
Thanks for the helpful guide, however can you describe more about SHR (shared). At what point a proportion of memory is determined to be shared. If I’m writing a library of my own — is there a way to utilize this shared memory?
November 8th, 2013 at 5:58 am
Hope this helps..
a: PID — Process Id
The task’s unique process ID, which periodically wraps, though
never restarting at zero.
b: PPID — Parent Process Pid
The process ID of a task’s parent.
c: RUSER — Real User Name
The real user name of the task’s owner.
d: UID — User Id
The effective user ID of the task’s owner.
e: USER — User Name
The effective user name of the task’s owner.
f: GROUP — Group Name
The effective group name of the task’s owner.
g: TTY — Controlling Tty
The name of the controlling terminal. This is usually the
device (serial port, pty, etc.) from which the process was
started, and which it uses for input or output. However, a
task need not be associated with a terminal, in which case
you’ll see ‘?’ displayed.
h: PR — Priority
The priority of the task.
i: NI — Nice value
The nice value of the task. A negative nice value means higher
priority, whereas a positive nice value means lower priority.
Zero in this field simply means priority will not be adjusted
in determining a task’s dispatchability.
j: P — Last used CPU (SMP)
A number representing the last used processor. In a true SMP
environment this will likely change frequently since the kernel
intentionally uses weak affinity. Also, the very act of
running top may break this weak affinity and cause more
processes to change CPUs more often (because of the extra
demand for cpu time).
k: %CPU — CPU usage
The task’s share of the elapsed CPU time since the last screen
update, expressed as a percentage of total CPU time. In a true
SMP environment, if ‘Irix mode’ is Off, top will operate in
‘Solaris mode’ where a task’s cpu usage will be divided by the
total number of CPUs. You toggle ‘Irix/Solaris’ modes with the
‘I’ interactive command.
l: TIME — CPU Time
Total CPU time the task has used since it started. When
‘Cumulative mode’ is On, each process is listed with the cpu
time that it and its dead children has used. You toggle
‘Cumulative mode’ with ‘S’, which is a command-line option and
an interactive command. See the ‘S’ interactive command for
additional information regarding this mode.
m: TIME+ — CPU Time, hundredths
The same as ‘TIME’, but reflecting more granularity through
hundredths of a second.
n: %MEM — Memory usage (RES)
A task’s currently used share of available physical memory.
o: VIRT — Virtual Image (kb)
The total amount of virtual memory used by the task. It
includes all code, data and shared libraries plus pages that
have been swapped out and pages that have been mapped but not
used.
p: SWAP — Swapped size (kb)
Memory that is not resident but is present in a task. This is
memory that has been swapped out but could include additional
non-resident memory. This column is calculated by subtracting
physical memory from virtual memory.
q: RES — Resident size (kb)
The non-swapped physical memory a task has used.
r: CODE — Code size (kb)
The amount of virtual memory devoted to executable code, also
known as the ‘text resident set’ size or TRS.
s: DATA — Data+Stack size (kb)
The amount of virtual memory devoted to other than executable
code, also known as the ‘data resident set’ size or DRS.
t: SHR — Shared Mem size (kb)
The amount of shared memory used by a task. It simply reflects
memory that could be potentially shared with other processes.
u: nFLT — Page Fault count
The number of major page faults that have occurred for a task.
A page fault occurs when a process attempts to read from or
write to a virtual page that is not currently present in its
address space. A major page fault is when backing storage
access (such as a disk) is involved in making that page
available.
v: nDRT — Dirty Pages count
The number of pages that have been modified since they were
last written to disk. Dirty pages must be written to disk
before the corresponding physical memory location can be used
for some other virtual page.
w: S — Process Status
The status of the task which can be one of:
‘D’ = uninterruptible sleep
‘R’ = running
‘S’ = sleeping
‘T’ = traced or stopped
‘Z’ = zombie
Tasks shown as running should be more properly thought of as
‘ready to run’ — their task_struct is simply represented on
the Linux run-queue. Even without a true SMP machine, you may
see numerous tasks in this state depending on top’s delay
interval and nice value.
March 14th, 2014 at 9:50 am
Awesome summary man !!! Just the basics but clearly written.
April 1st, 2014 at 10:53 am
@sangvv: if your program has some hundred or thousand of threads, virt will be increased in such way. It doesn’t means that it consume such a big value. The program requested the addresses in memory, but it didn’t consume that much.
I had a situation where I had to make a program with 1000 threads and VIRT was the entire address space(4G), but it consumed only 100MB.
March 19th, 2015 at 5:13 pm
@MG. Very well done post. Also some very informative answers and comments by others. Also the response by Senny added additional clarity. Well done all!
October 9th, 2015 at 9:20 pm
What does this mean then:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5921 dnapoleo 20 0 2499m 2.3g 2.1g S 0.0 4.9 0:30.79 python
I have my process blocking on user input, and this is remaining constant. In truth, 2.1GB is shared, and 240Meg is not. RES is reporting private + shared memory for me. But not always. Sometimes it appears to not represent the SHR portion. Why?
December 2nd, 2015 at 12:23 pm
If I want to check whether a process is leaking memory, then looking at RES and %MEM over a period of time for that process should be sufficient? Please let me know.
I have a case where the RES and %MEM over a 24 period remained the same but the VIRT has grown from 49m to 119m!
January 8th, 2016 at 6:58 pm
Can someone explain how do we evaluate VIRT, g is obviously not Gig.
top
top – 09:58:15 up 38 days, 8:37, 2 users, load average: 1.03, 1.08, 0.97
Tasks: 914 total, 3 running, 911 sleeping, 0 stopped, 0 zombie
Cpu(s): 20.7%us, 8.3%sy, 0.0%ni, 64.2%id, 0.0%wa, 0.0%hi, 6.8%si, 0.0%st
Mem: 264493616k total, 242594532k used, 21899084k free, 145400k buffers
Swap: 33554428k total, 0k used, 33554428k free, 223535976k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4152 aaaaaaaa 20 0 53.9g 5.5g 87m S 919.9 2.2 11742:41 java
14365 aaaaaaaa 20 0 113m 11m 844 R 75.0 0.0 0:02.28 lsof
14138 aaaaaaaa 20 0 3234m 213m 11m S 57.9 0.1 0:13.88 java
14375 aaaaaaaa 20 0 102m 204 76 R 34.9 0.0 0:01.06 lsof
3903 root 20 0 4079m 103m 5100 S 3.6 0.0 1184:17 ds_am
59917 aaaaaaaa 20 0 6691m 841m 5308 S 1.6 0.3 562:07.17 java
8494 aaaaaaaa 20 0 17788 1940 952 R 1.3 0.0 0:08.54 top
January 8th, 2016 at 7:31 pm
Before I comment about my own question.
I have got the answer, but people in this thread may comment.
g is not Gigabyte it is Gigabit
m is not megabyte it is megabeit
M – megabyte
G – Gigabyte
So, 53.9g is 6.7375 Gigabit (Gig)
May 22nd, 2016 at 5:47 pm
No it isn’t bits. It is bytes
May 25th, 2016 at 6:21 pm
I think you are wrong,
VIRT could be physical memory + swap
I do not see in top manual
from where you have got it?
October 3rd, 2016 at 11:36 pm
I guess it’s worth noting you can toggle between top’s mem usage formats by repeatedly pressing E or e, for the summary and task areas respectively.
And W will write your prefs to .toprc.
November 29th, 2016 at 3:50 am
VIRT : Size in memory of the total program size.
RES : The resident set size, i.e the size of the text and data sections, plus stack usage.
SHR : The size of the process’s shared pages.
welcome to my website http://www.z-dig.com
February 3rd, 2017 at 7:51 pm
Note also that VIRT can mean mapped but *not yet used* memory for a process, so isn’t always an awesome way to tell how much “real” RAM a process is using.