[Discuss] memory management

[Jerry Natowitz]

My advise on Firefox is to close it down completely whenever you have 
finished using it.  There seems to be a lot of memory leaking, I've seen 
Firefox grow into multi-gigabyte virtual size in a matter of hours.

I have not experimented with shutting down Firefox with multiple windows 
and tabs, and then restarted it, using the Restore Previous Session 
option on the History pull-down.  It would be interesting to see how 
much memory was saved, and for how long.

	Jerry Natowitz
===>    j.natowitz (at) rcn.com
if rcn.com bounces, try gmail.com

On 06/19/15 11:02, Steve Litt wrote:
> On Fri, 19 Jun 2015 10:01:57 -0400
> Matthew Gillen <me at mattgillen.net> wrote:
>
>> I'm looking for some advice on tuning my linux box's memory
>> management. I've got an older workstation that has merely 4GB of
>> memory.  If I try to run Firefox, and a few java apps (e.g.,
>> Eclipse), my machine thrashes about and effectively locks up because
>> of out-of-memory issues.
>>
>> For example: the mouse will continue to move, but won't change it's
>> icon contextually.  If I hit cntl-alt-f2 and try to log in to a
>> virtual console, mgetty will eventually ask for the username, but
>> after I hit enter, it just hangs, not popping up the password prompt,
>> and after 60 seconds the login times out.  Trying to ssh into the
>> machine from somewhere else ends up timing out.
>>
>> After going on like this for literally 10 minutes, OOM-killer
>> sometimes kills the right thing (one of the two processes hogging the
>> most memory: firefox or eclipse), and the machine becomes usable
>> again sometime later.
>>
>> I have heftier workstations I can use, but this behavior is really
>> frustrating to me, because I'd like to think linux does good memory
>> management.  I've tried using huge swap (2x physical memory).  I've
>> tried with virtually no swap (on the theory that without swap, there
>> would be no thrashing and at least oom-killer would have to do its
>> thing without locking up the machine for 10 minutes first).  The
>> problem there was oom-killer making bad decisions about what to kill
>> (e.g., the window manager, and then whatever out-of-control process
>> is sucking up memory just sucks up whatever got freed, and nothing
>> gets better).  At least with some swap oom-killer seems to make
>> better guesses about who to murder.
>>
>> Does anyone have any tips on how to prevent linux from thrashing like
>> that?  The behavior when low on memory seems atrociously bad.
>>
>> Thanks,
>> Matt
>
> Hi Matt,
>
> I haven't seen any stats quoted in your email, from the  "top" program,
> that indicate it's a RAM problem. Firefox and its pet
> "plugin-container" use a heck of a lot of CPU. Until very recently I
> was using a 4GB machine, and when things got crawly, the top program
> indicated that both my cores were near 100%, but there was plenty more
> RAM.
>
> Today I have a 16GB RAM box, with dual core CPU (I wanted things to
> stay cool), and things still get crawly. When they do, I run the top
> command to see what's taking all the CPU, and kill it if necessary.
> It's usually one or more instances of Firefox and plugin-container. I
> typically killall plugin-container, and then start closing
> no-longer-needed tabs on the various Firefox windows. I'll often drag
> all the tags to *one* Firefox window, and kill the others.
>
> I like Firefox, but it's no doubt a pig. My recommendation when using
> Firefox is to close any tabs you're finished with. Often, good
> housekeeping with Firefox is the key to avoiding the crawlies.
>
> When the crawlies rear their ugly head, my first step on the path
> is the top command, to see who is consuming what resource, and what
> resource is becoming a choke point. Then I take care of the choke
> point, and if it involves Firefox at all, I'm ruthless in closing tabs
> I'm finished with.
>
> SteveT
>
> Steve Litt
> June 2015 featured book: The Key to Everyday Excellence
> http://www.troubleshooters.com/key
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>