Who is leaking memory in my Linux Jessie/KDE4 installation?

[Oleg Goldshmidt]

Omer Zak <w1 at zak.co.il> writes:

> This kind of memory usage concerns me, because when more than 90% of
> memory is being used, the system slows down.

Every system I use is at or above 90% memory consumption. Always. It is
normal. The laptop I am typing on is at present at 88.5%, running KDE,
firefox, emacs, a konsole, and nothing else of any significance.

Here is how you investigate it.

Please post the output of your free command, and the top 4-5 lines of
top (excluding the header), sorted by RSS. For the latter, start top,
press F (to select the sort field), then q (to sort by the resident set
size - top knows it as RES). The result will look like

  PID USER PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
24689 oleg 20   0 1745m 450m  37m S  1.7 11.7  99:48.48 firefox            
 1632 oleg 20   0 3324m 143m  31m S  0.0  3.7  16:44.52 plasma-desktop     
 1845 oleg 20   0  706m  70m  13m S  0.3  1.8   9:38.23 emacs              

Then please also post the memory usage details of the top "hog". In my
case above it is firefox, with PID 24689:

$ egrep "^Vm" /proc/24689/status
VmPeak:  1990664 kB
VmSize:  1787052 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:    723388 kB
VmRSS:    464648 kB
VmData:   954040 kB
VmStk:      1048 kB
VmExe:        80 kB
VmLib:     95980 kB
VmPTE:      3324 kB
VmSwap:        0 kB

The RSS (resident set size, this is the memory mapped into the process's
virtual memory space) is ~465kB, close to the 450M that top reports (it
may fluctuate a bit, and there may be 1024/1000 involved in random cases
- I can never remember -> 450*1.024=460.8; NB: this corresponds to 11.7%
of my 4GB RAM, as top reports). The high watermark of RSS, VmHWM, is
~720MB - FF never used more memory than that. This is also a hint that
it does not leak memory - it uses much less now than HWM. Note that the
heap (VmData) is more than twice as large as RSS, but it is not (not all
of it, anyway) mapped into VM. It may be (pre-)allocated but it does not
mean that the memory is not available to other processes on demand. The
stack is ~1MB. 96MB is in shared libs - the part used by FF and mapped
into its process space, so while it is used by FF it does not belng
exclusively to it. I mention this because the shared part may be large
compared to RSS, depending on application. [Use "man 5 proc" for
reference.]

Think of it this way: applications (and the OS) may be smart, and they
may pre-load, pre-map, pre-fetch into RAM all sorts of stuff that is not
really in use but may be used at some point. If there is memory
available, why not do it? On top of it, memory that was allocated and
used and is no longer in use will not be freed unless there is
demand. If no one requests it, why bother? If more processes are started
and demand memory the memory will be re-allocated. This is why most
memory is always marked as used. Only if the sum of the resident sizes of
the running processes exceeds the physical memory size will you run into
trouble, trouble being either performance problems associated with swap
usage or OOM killer springing into action.

I hope the above will help you in your investigations. Frankly, I
suspect you do not have a real problem.
  
-- 
Oleg Goldshmidt | pub at goldshmidt.org