[Discuss] memory management

[jabr at blu.org (John Abreau)]

Also tried the following bash script on MacOS Snow Leopard desktop, and the
system is running much better now, after I killed the running instance of
firefox and then ran the script from an xterm to relaunch firefox.


    #! /bin/bash
    ulimit -d 3500000 ; ulimit -v 3500000 ; ulimit -m 3000000
    exec /Applications/Firefox.app/Contents/MacOS/firefox "$@"



On Tue, Jun 23, 2015 at 10:18 AM, John Abreau <abreauj at gmail.com> wrote:

> A bit of googling turned up a page about using cgroups to limit firefox's
> memory usage.
>
>
> http://jlebar.com/2011/6/15/Limiting_the_amount_of_RAM_a_program_can_use.html
>
>
> On Fri, Jun 19, 2015 at 10:01 AM, 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
> > _______________________________________________
> > Discuss mailing list
> > Discuss at blu.org
> > http://lists.blu.org/mailman/listinfo/discuss
> >
>
>
>
> --
> John Abreau / Executive Director, Boston Linux & Unix
> Email: abreauj at gmail.com / WWW http://www.abreau.net / PGP-Key-ID
> 0x920063C6
> PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23  C2D0 E885 E17C 9200 63C6
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>



-- 
John Abreau / Executive Director, Boston Linux & Unix
Email jabr at blu.org / WWW http://www.abreau.net / PGP-Key-ID 0x920063C6
PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23  C2D0 E885 E17C 9200 63C6