[Discuss] memory management

[gaf at blu.org (Jerry Feldman)]

I don't agree with shutting firefox down every time you are finished. 
Virtual memory should mitigate this if you focus on another task, but.....
Many web sites are very active so they keep requiring system resources 
even if firefox is not actively being used. Maybe just closing some tabs 
of some of the more active web sites will help.

On 06/19/2015 11:30 AM, Jerry Natowitz wrote:
> 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
>>
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>
>

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:B7F14F2F
PGP Key fingerprint: D937 A424 4836 E052 2E1B  8DC6 24D7 000F B7F1 4F2F