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----- > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
