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



I just checked three different machines firefox (Fedora 22, CentOS 6.5, and
MacOS Snow Leopard).

All three have an active firefox browser running, but none show a running
process named "plugin-container", nor any process with a name containing
the string "plug" There are also no processes whose parent PPID is the
firefox process.

All three instances are running a number of plugins.

Shouldn't plugin-container be running if firefox is running?


On Tue, Jun 23, 2015 at 12:17 PM, Steve Litt <slitt at troubleshooters.com>
wrote:

> On Tue, 23 Jun 2015 11:38:30 -0400
> Matthew Gillen <me at mattgillen.net> wrote:
>
> > On 06/23/2015 10:18 AM, John Abreau 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
> >
> >
> > ulimit, and prlimit could do the trick I suppose, but the hard-limits
> > there would be quite a bit of use-case-specific tuning.
> > CGroups are much closer to what I want, but not for the rogue
> > processes: I think making a cgroup for core processes and setting
> > their swappiness to zero actually gets me closer to what I'm looking
> > for.
> >
> > What I really wanted was the rogue process to pay the cost of memory
> > access, instead of spreading that pain throughout the system.  But
> > CGroups gets me close I think:
> >
> > According to this:
> >
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/sec-memory.html
> >
> > you can create a group, and set swappiness and oom-killer eligibility
> > for that group.  So ideally I would put certain critical things needed
> > for recovery (e.g. ssh daemon, agetty, maybe even the window manager;
> > any process that allows me to find and kill what I need to help the
> > system recover) in a group that would effectively exempt them from the
> > thrashing.
> >
> > HOWEVER, there is still a problem. For instance, my current system
> > doesn't actually launch an 'agetty' (login) process on the virtual
> > terminals until you switch to them.  That means you need some
> > 'reserved' memory, which my quick reading of cgroups doesn't seem to
> > allow you to do.  I'd be happy if there were just a small amount of
> > memory reserved, enough to:
> >  - launch agetty and login
> >  - launch root's login shell
> >  - run killall eclipse
>
> Wait a minute. Once upon a time I had a daemon for almost this same use
> case, but it was for rogue dbus-daemons instead of rogue eclipses or
> rogue firefoxes.
>
> It doesn't even need to be a daemon. You could run it every 5 seconds
> with cron, and if twice in a row it shows evidence of a rogue eclipse,
> it killalls eclipse. Same with firefox, etc. With firefox, I'd
> recommend killall plugin-container first, because that's the usual
> subject, and you can keep your windows so you know which to bookmark.
>
> To do this, you need the following:
>
> * A command to define runaway eclipse. Probably some sort of parsed ps
>   command.
>
> * A file to store the last value of Eclipse's "runaway value", so you
>   can tell whether it's two in a row.
>
> * A script to combine the preceding with a killall
>
> * Connecting the preceding script to cron. Every 5 seconds ought to do
>   it.
>
> HTH,
>
> 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
>



-- 
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



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 / webmaster@blu.org