Rob Winchester wrote:
[ This does not apply to Windows at all where the "Mem Usage" column means physical memory used, and "VM Size" seems to account for swap space allocated for that process. The puzzling thing is seeing a process with a smaller "VM Size" than "Mem Usage". Anyone with links to more detailed information on the Windows VM architecture, please post them. ]Nothing odd there is there? But soffice.bin is currently hogging 303MB of memoryYes one thing you can do is to run top and tell us the VIRT, RES and SHR
ideas ? Duncan
values that are reported. On my system,
$HOME/OpenOffice.1.1.4/program/soffice.bin is just under 400Kb and I
would expect memory usage to be similar. For example I get:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3372 gerry 16 0 292m 155m 51m S 2.3 20.5 35:45.60 soffice.bin
and that looks reasonable to me.
virt is short for virtual memory and that means swap space on the drive. If
you have lots of real memory then this # can get big like this and its no big
deal. Note the %MEM entry. this one is more important. also if %CPU gets
higher VIRT generally tend to get higher depending on what is being done as
using virtual memory takes much more processing power than physical (real)
memory.
Linux uses an over-committed memory architecture. That means an app asks for memory and Linux allows the allocation, but doesn't do any work until the memory is actually used. In the above case OOo asked for 292MB of memory, but only used 155MB of memory. The rest has been asked for, but not used.
In Linux, the VIRT number is always the largest number, and a large VIRT number only shows that the program is asking for more memory than it is using. The number you want to watch the most is RES which shows the amount of memory actually in use and not in swap. Additional columns like swap, and page faults will show you how much memory for that process has been swapped out, and how many times a page had to be swapped back in (basically swap thrashing indicators).
That's a very basic overview.
Mike
