Date: Tue, 21 May 2013 11:40:30 -0700 From: Charles Swiger <cswiger@mac.com> To: Dmitry Sivachenko <trtrmitya@gmail.com> Cc: questions@freebsd.org Subject: Re: RES column in top(1) output Message-ID: <B12E243B-4D87-4EC5-950D-B78C82B9BE45@mac.com> In-Reply-To: <24044FD7-4E2A-493F-B0CE-701C3A73169F@gmail.com> References: <24044FD7-4E2A-493F-B0CE-701C3A73169F@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 21, 2013, at 11:03 AM, Dmitry Sivachenko <trtrmitya@gmail.com> = wrote: > Hello, >=20 > Can you please explain me the meaning of RES column in top(1) output: > as far as I understand from man-page, it is resident portion of the = process, that is the amount of memory process takes from RAM. Yes, that's the definition. > But I get: >=20 > Mem: 55G Active, 23G Inact, 11G Wired, 3729M Cache, 9838M Buf, 97M = Free > Swap: 49G Total, 14M Used, 49G Free >=20 >=20 > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU = COMMAND > 93273 username 103 52 0 141G 115G uwait 22 25:37 = 19.82% XXX >=20 > So I have a machine with 96GB of RAM, no swap is used and my process's = resident size is 115G (more than physical memory). Memory that has been allocated but not written to is associated with the = process address space in terms of accounting, but does not actually = consume physical memory. There's also copy-on-write memory (used for = the program executable code itself, which is also typically also marked = read-only), mmap()ing big sparse files or device special files like a = video framebuffer (ie, an X11 server), and probably a few other things = which can reserve lots of resident memory without actually consuming = physical memory. Regards, --=20 -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B12E243B-4D87-4EC5-950D-B78C82B9BE45>