<p dir="ltr">You can always do some sort of a 'ps ef' compare, run one once you reboot, then run another one when the system reaches the 90s used memory, compare the outputs and it will help you understand which specific processes grew the most in terms of memory consumption. I always found this method to be very useful over time.<br></p>
<p dir="ltr">--<br>
df</p>
<br/><div class="cm_quote" style=" color: #787878">On Fri, Aug 29, 2014 at 10:25 PM, Omer Zak <<a href="mailto:w1@zak.co.il">w1@zak.co.il</a>> wrote:</div><br><div id="oldcontent" style="background-color: rgb(255, 255, 255); background-position: initial initial; background-repeat: initial initial;"><blockquote style=""><p dir="ltr">Hello Shimi and Oleg,
<br>
Thanks for helping me clarify what I mean by "memory leak" in this
<br>
context.
<br>
<br>
I routinely monitor memory usage by means of gnome-system-monitor, and
<br>
it appears to display memory consumption by watching the
<br>
used -/+ buffers/cache number.
<br>
<br>
As the time since last reboot lengthens, the above memory usage number
<br>
creeps upwards. I cannot get it back to the value it had shortly after
<br>
reboot by closing all heavy applications. This is why I am referring to
<br>
it as "memory leak".
<br>
<br>
This kind of memory usage concerns me, because when more than 90% of
<br>
memory is being used, the system slows down. It is not because swap
<br>
memory is used (swap usage remains 0% at all times) but apparently
<br>
because there is not enough free memory to buffer/cache the entire
<br>
working set of frequently-used files.
<br>
<br>
When the system slows down, I reboot it and few more days pass before
<br>
memory usage (-/+ buffers/cache) again nears 90%.
<br>
<br>
So I am interested in finding who is hogging memory at expense of the
<br>
buffer/cache memory. Furthermore, I'd like to find out who is hogging
<br>
more and more memory as time passes on.
<br>
<br>
--- Omer
<br>
<br>
<br>
<br>
On Fri, 2014-08-29 at 20:14 +0300, Oleg Goldshmidt wrote:
<br>
> Omer Zak <w1@zak.co.il> writes:
<br>
>
<br>
> > I have a 8GB PC which runs Linux Debian Jessie with KDE 4.4.
<br>
> > My problem is to find out who is occupying almost 4GB memory some time
<br>
> > after rebooting, even when nothing heavy is running.
<br>
>
<br>
> What is your question? The subject mentions "leaking", while the body of
<br>
> your post seems to indicate (I am guessing a bit) that what bothers you
<br>
> is that most of your memory is reported as "used" rather than as
<br>
> "free" or "available".
<br>
>
<br>
> If an application really leaks memory you should normally be able to
<br>
> observe it by running top or similar and seeing, say, RES increasing
<br>
> with time.
<br>
>
<br>
> If your problem is "too much memory is reported as used" then you should
<br>
> know that most of memory is "used" by something. This does not mean it
<br>
> is not available. The classic case is memory that is - or was - used for
<br>
> buffers or cache.
<br>
>
<br>
> > However, even when they are closed, a lot memory is still reported to
<br>
> > be in use.
<br>
>
<br>
> Operating systems do not free memory until someone requests it - again,
<br>
> your buffers and cached stuff are primary examples, as explained
<br>
> above. If you look at the "Mem" line of your top(1) or free(1) it will
<br>
> *always* report most of your memory as "used". Here is my free(1) output
<br>
> on an old laptop with 4G of RAM:
<br>
>
<br>
> $ free
<br>
> total used free shared buffers cached
<br>
> Mem: 3941664 3522680 418984 0 218636 2208160
<br>
> -/+ buffers/cache: 1095884 2845780
<br>
> Swap: 6029308 113872 5915436
<br>
>
<br>
> How much memory is used? About 1GB, actually, with ~3GB available. See
<br>
> the 2nd line, which takes into account that whatever is listed as
<br>
> buffers+cache are available for applications if/when they request it.
<br>
>
<br>
> Check your free(1), if you see anything suspicious, post it.
<br>
>
<br>
> > My question is: besides top, what tools can be used to find who is using
<br>
> > all this memory?
<br>
>
<br>
> Find out the PIDs of the processes you suspect (make top sort by RES by
<br>
> typing Fq in top?) and do
<br>
>
<br>
> egrep "^Vm" /proc/<pid>/status
<br>
>
<br>
> for each - it will give you a lot of detailed info. If you suspect a
<br>
> leak repeat a few times while the suspect process is running (and doing
<br>
> something).
<br>
>
<br>
> Relevant details have been discussed here before (guilty). Check
<br>
>
<br>
> http://www.mail-archive.com/linux-il@cs.huji.ac.il/msg31797.html
<br>
> http://mailman.cs.huji.ac.il/pipermail/linux-il/2011-December/008322.html
<br>
>
<br>
> - you will either find that useful or it will help you sleep (well).
<br>
>
<br>
> > The next question, of course, is how to get rid of those memory hogs
<br>
> > without destabilizing the system.
<br>
>
<br>
> First, find out if there is a problem, and what the problem is.
<br>
>
<br>
<br>
--
<br>
Your liberty to swing your fist ends just where my nose begins.
<br>
Your freedom of expression ends where my freedom of expression begins.
<br>
Your freedom of religion ends where my rights for equality and
<br>
accessibility begin.
<br>
My own blog is at http://www.zak.co.il/tddpirate/
<br>
<br>
My opinions, as expressed in this E-mail message, are mine alone.
<br>
They do not represent the official policy of any organization with which
<br>
I may be affiliated in any way.
<br>
WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html
<br>
<br>
<br>
_______________________________________________
<br>
Linux-il mailing list
<br>
Linux-il@cs.huji.ac.il
<br>
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
<br>
</p>
</blockquote></div>