| 1 |
Bruno Lustosa wrote: |
| 2 |
|
| 3 |
> Yes, but what caught my eyes was not the virtual address space. The |
| 4 |
> resident portion (i.e., what is really allocated on real memory) is |
| 5 |
> huge for that first instance. 204mb is way too much for a firefox with |
| 6 |
> 4 tabs open. |
| 7 |
|
| 8 |
|
| 9 |
I'm not so sure that the resident memory number can be trusted. For |
| 10 |
example, consider: |
| 11 |
|
| 12 |
PID %MEM VIRT RES CODE DATA SWAP SHR COMMAND |
| 13 |
7749 25.6 642m 518m 3020 61m 123m 514m vmware-vmx |
| 14 |
12487 3.7 176m 75m 228 73m 101m 48m soffice.bin |
| 15 |
793 2.1 100m 42m 64 72m 58m 17m thunderbird-bin |
| 16 |
12056 1.8 63228 37m 1292 25m 24m 11m X |
| 17 |
7730 1.3 34412 25m 6180 11m 8376 13m vmware |
| 18 |
25627 1.2 77328 24m 60 48m 51m 15m firefox-bin |
| 19 |
12444 0.9 30352 17m 36 2156 12m 14m konqueror |
| 20 |
12460 0.9 30440 17m 36 2244 12m 14m konqueror |
| 21 |
12429 0.8 26896 16m 36 2732 9844 13m kicker |
| 22 |
12427 0.8 24580 15m 36 2304 8332 12m kdesktop |
| 23 |
10067 0.8 28116 15m 4 2364 11m 12m kate |
| 24 |
12407 0.7 26192 14m 36 2032 10m 12m kded |
| 25 |
12436 0.7 23976 14m 528 2872 8736 11m superkaramba |
| 26 |
8482 0.7 25004 14m 36 2172 10m 11m konsole |
| 27 |
9112 0.7 24932 14m 36 2100 10m 11m konsole |
| 28 |
12438 0.7 24900 14m 60 1812 10m 11m korgac |
| 29 |
12461 0.7 27752 13m 36 1316 13m 11m knotify |
| 30 |
12425 0.7 22820 13m 36 1872 9036 10m kwin |
| 31 |
12433 0.6 21548 11m 36 1172 9472 9m klipper |
| 32 |
12424 0.5 21388 10m 36 1172 9m 9336 ksmserver |
| 33 |
12421 0.5 21064 10m 36 1028 9.9m 9216 kaccess |
| 34 |
|
| 35 |
If you sum the RES column of just these programs, you get 928M. Even if |
| 36 |
you exclude vmware (which is a bit of a special case), you get 410M. |
| 37 |
But now look at what free reports: |
| 38 |
|
| 39 |
total used free shared buffers cached |
| 40 |
Mem: 2075856 1923320 152536 0 76552 1552256 |
| 41 |
-/+ buffers/cache: 294512 1781344 |
| 42 |
Swap: 3145720 184 3145536 |
| 43 |
|
| 44 |
Free claims only 294MB is actually in use on the entire system, and is |
| 45 |
accurate. Everything else is backed by disk, so could be discarded and |
| 46 |
re-read from disk if necessary. |
| 47 |
|
| 48 |
As far as I know, the only reliable way to determine the actual amount |
| 49 |
of memory used by a program is to close it, and look at the difference |
| 50 |
reported by free. When I do that test with firefox, the system reclaims |
| 51 |
approximately 9.5MB of memory. With openoffice, I get back about 24MB. |
| 52 |
It might be that RES - SHR could give you the actual amount, but I'm not |
| 53 |
sure of that. |
| 54 |
|
| 55 |
> From top output, isn't the SHR the shared memory between them? It's at |
| 56 |
> 16mb for the first, and 17mb for the second. This is still too little |
| 57 |
> compared to 204mb or 511mb. |
| 58 |
|
| 59 |
|
| 60 |
SHR is both shared memory (rare), and memory-mapped files (shared |
| 61 |
libraries fall here). Notice my vmware output claims 514MB of shared |
| 62 |
memory. This is because the guest OS is allocated 512MB of memory, |
| 63 |
which exists as a memory-mapped file. Only part of that file may be |
| 64 |
physically located in memory at any one time. |
| 65 |
|
| 66 |
-Richard |
| 67 |
|
| 68 |
-- |
| 69 |
gentoo-user@g.o mailing list |
Archives