Re: Tracking down memory leaks

From	Marc Shapiro <marcnshap@gmail.com>
Newsgroups	linux.debian.user
Subject	Re: Tracking down memory leaks
Date	2015-10-17 18:10 +0200
Message-ID	<qkCds-2rT-29@gated-at.bofh.it> (permalink)
References	<qj8Ku-KS-19@gated-at.bofh.it> <qj9dv-1jL-7@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On 10/13/2015 07:32 AM, The Wanderer wrote:
> On 2015-10-13 at 10:26, Marc Shapiro wrote:
>
>> Is there a way to determine what is using up my memory?  I have an
>> 8GB system and every few days the memory usage rises to over 7 GB and
>> up to a GB, or more of swap is used.  Granted, I have 3 X sessions
>> running, along with 2 instances of Firefox and one of Chrome, not to
>> mention up to 3 instances of Libre Office, but... When I first added
>> the 8 GB (I used to do this on 2.25 GB!) I could run for months
>> without having a memory problem.  Now it's every few days.
>>
>> When this happens, I exit all programs and shut down all three X
>> sessions.  I also log out the other two users.  This leaves me with
>> only a single login and nothing but bash running.  When I run 'free'
>> it usually shows over 2 GB in use!  When I reboot, the memory usage
>> is back down at about 250 MB.  Much more reasonable.
>>
>> So how do I tell what is using up the memory and not freeing it up?
> My usual first stop is top. Launch it, then press 'M' (capitalized) to
> sort by memory usage; that will tell you what process(es) is(/are) using
> up the largest share(s) of the RAM.
>
> What the next steps are depends on what those processes are. In my case,
> with the last significant memory leak I found, the process was X, and
> further digging revealed that the X heap size was growing without limit;
> it turned out to be a problem with fglrx, and went away when I switched
> to the radeon drivers.
>
> In your case, since it apparently happens without X running, the only
> candidates I can think of are background (daemon-like) processes or the
> kernel itself.
>
>> Is there a way to free that memory without having to reboot?
> Depends what process(es) is/are using it.
>
> If it's a background daemon, restart that daemon.
>
> If it's the kernel, probably not, but it would be worth reporting the
> problem as a bug against the kernel.
>
On 10/13/2015 07:51 AM, Don Armstrong wrote:
> What is the precise output of free? Odds are a huge amount of what is 
> in "use" is actually cached or in buffers. Furthermore, it's pretty 
> normal for the OS to swap out memory pages which aren't actively being 
> changed to make room for more buffers and cache. The output of top or 
> htop sorted by memory will also be informative. 

Well,  it was doing it again this morning after I had done a restart 
just yesterday.  Conveniently, free and top were the first things that I 
ran.  The output of free and the relevant line from top is below.  It's 
fFrefox.  Usually, it is my wife's instance of Firefox, as she keeps 
about thirty open tabs, or it is my daughters instance of Chrome.  This 
time it was my Firefox and I believe that was the case the last time, as 
well.  I don't keep a lot of open tabs.  At the moment, I have ten tabs 
open, including pinned tabs.  I am beginning to think that it is Kahn 
Academy (which accounts for four of those ten tabs open on different 
courses) which is causing the problem.  Simply closing down all browsers 
and restarting them gets back a lot of the memory (several GB at 
least).  It's just getting that last one to two GB that I have to reboot 
for.

When I do have to do a reboot I close down everything to a single 
console running.  I then run top and it only shows bash and top. Next 
time I will run top and include root and daemon processes and see if 
anything shows up.  I am guessing that this is memory that Firefox was 
using, but has forgotten about.  If that is the case, is there a way to 
free it up without doing a reboot?


:~$ free
              total       used       free     shared    buffers cached
Mem:       8176892    8072660     104232          0       1588 454736
-/+ buffers/cache:    7616336     560556
Swap:      8388604    1566652    6821952


~$ top

top - 08:22:28 up 17:42,  4 users,  load average: 7.71, 3.31, 1.74
Tasks: 298 total,   1 running, 295 sleeping,   0 stopped,   2 zombie
%Cpu(s): 14.5 us,  1.8 sy,  0.0 ni, 82.1 id,  1.5 wa,  0.0 hi,  0.0 si,  
0.0 st
KiB Mem:   8176892 total,  8071388 used,   105504 free,     3480 buffers
KiB Swap:  8388604 total,  3260756 used,  5127848 free,   466560 cached

   PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+ COMMAND
  5062 marc      20   0 7622m 5.3g  12m D   1.6 68.1 210:02.01 firefox

Thread

Tracking down memory leaks Marc Shapiro <marcnshap@gmail.com> - 2015-10-13 16:30 +0200
  Re: Tracking down memory leaks The Wanderer <wanderer@fastmail.fm> - 2015-10-13 16:40 +0200
  Re: Tracking down memory leaks Don Armstrong <don@debian.org> - 2015-10-13 17:00 +0200
    Re: Tracking down memory leaks Marc Shapiro <marcnshap@gmail.com> - 2015-10-17 18:10 +0200
      Re: Tracking down memory leaks Don Armstrong <don@debian.org> - 2015-10-18 22:00 +0200
        Re: Tracking down memory leaks Marc Shapiro <marcnshap@gmail.com> - 2015-10-21 07:00 +0200
          Re: Tracking down memory leaks Jörg-Volker Peetz <jvpeetz@web.de> - 2015-10-21 08:40 +0200
            Re: Tracking down memory leaks (SOLVED) Marc Shapiro <marcnshap@gmail.com> - 2015-10-22 16:30 +0200
              Re: Tracking down memory leaks (SOLVED) Nicolas George <george@nsup.org> - 2015-10-22 16:40 +0200
                Re: Tracking down memory leaks (SOLVED) Cindy-Sue Causey <butterflybytes@gmail.com> - 2015-10-23 19:30 +0200
                Re: Tracking down memory leaks (SOLVED) Nicolas George <george@nsup.org> - 2015-10-23 19:40 +0200
                Re: Tracking down memory leaks (SOLVED) Lisi Reisz <lisi.reisz@gmail.com> - 2015-10-23 20:10 +0200
                Re: Tracking down memory leaks (SOLVED) The Wanderer <wanderer@fastmail.fm> - 2015-10-23 20:40 +0200
                Re: Tracking down memory leaks (SOLVED) Reco <recoverym4n@gmail.com> - 2015-10-23 20:20 +0200
                Browser tabs, was Re: Tracking down memory leaks David Wright <deblis@lionunicorn.co.uk> - 2015-10-23 21:00 +0200
              Re: Tracking down memory leaks David Wright <deblis@lionunicorn.co.uk> - 2015-10-22 17:30 +0200
                Re: Tracking down memory leaks Marc Shapiro <marcnshap@gmail.com> - 2015-10-24 08:30 +0200
              Re: Tracking down memory leaks (SOLVED) <tomas@tuxteam.de> - 2015-10-23 09:40 +0200
        Re: Tracking down memory leaks Michael Jones <mj@mikejonesey.co.uk> - 2015-10-21 23:40 +0200
  Re: Tracking down memory leaks Michael Jones <mj@mikejonesey.co.uk> - 2015-10-21 23:30 +0200
  Re: Tracking down memory leaks Michael Jones <mj@mikejonesey.co.uk> - 2015-10-21 23:40 +0200

csiph-web