Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] memory management

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)
if bounces, try

On 06/19/15 11:02, Steve Litt wrote:
> On Fri, 19 Jun 2015 10:01:57 -0400
> Matthew Gillen <me at> 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
> _______________________________________________
> Discuss mailing list
> Discuss at

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /