Re: top(1) and the meaning of columns
On Tue, 2006-10-31 at 07:43 -0600, Ron Johnson wrote:
> PID USER VIRT RES SHR %MEM COMMAND
>
> 19383 me 249m 101m 26m 10.0 firefox-bin
>
> 19068 me 197m 73m 22m 7.3 icedove-bin
>
> 23727 me 172m 58m 40m 5.8 soffice.bin
>
> Does this mean that soffice.bin itself is only using 58 - 40 = 18MB RAM.
>
Kind of. It means the kernel has allocated 172M , 58M of that is
actually being used, and 40 out of 172 is shared, some of which used by
pid 23727 (soffice.bin), and if you did the math against the %MEM column
really fast in your head you'd have a better idea of its use .. (and
note its usage is actually rather low, but its seizing way more memory
than it actually needs).
More clearly put, the application is malloc()'ing much more memory than
it actually needs because its not sure what you are going to ask it to
do and store next. A good example would be calc, to fork and be happy it
needs very little.. but when you paste your 10 MB CSV file into it ..
that changes. It has to have elbow room to remain responsive with
(ideally) clean pages no matter what you throw at it.
The only really useful part of that output is the VIRT column, just so
you know what the kernel allocated to it and its associated threads
(entirely) which tells you what other applications can't touch until its
freed.
I'm not discounting the RES/SHR columns because they are indeed
interesting, but not entirely useful and as someone pointed out .. a bit
cryptic.
These are particularly perplexing with X applications using the vast
shared x11 libs.
If you use lsof, and filter via grep with the pid or app name, you'll
see what I mean about shared libs. (or ldd if not running).
Are you debugging or trying to figure out why contiguous blocks are
getting kind of small?
Hope this helps.
Best,
-Tim
> - --
> Ron Johnson, Jr.
> Jefferson LA USA
>
> Is "common sense" really valid?
> For example, it is "common sense" to white-power racists that
> whites are superior to blacks, and that those with brown skins
> are mud people.
> However, that "common sense" is obviously wrong.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
>
> iD8DBQFFR1LkS9HxQb37XmcRAjAkAKCECQxhDcp7FgarokCZOcJhm3h7LgCaArMV
> ATZpXCipG269F1RbMfsi1sc=
> =dNl/
> -----END PGP SIGNATURE-----
>
>
Reply to: