Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month, online, via Jitsi Meet.

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