BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] memory management
- Subject: [Discuss] memory management
- From: jabr at blu.org (John Abreau)
- Date: Tue, 23 Jun 2015 20:48:40 -0400
- In-reply-to: <20150623121738.45270544@mydesq2.domain.cxm>
- References: <558420D5.6090803@mattgillen.net> <CAFv2jcYkUA8ahyeGUhE8EK_GFYj+WLo6E4WzNtT0fC4OuDTaLw@mail.gmail.com> <55897D76.10104@mattgillen.net> <20150623121738.45270544@mydesq2.domain.cxm>
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
- Follow-Ups:
- [Discuss] memory management
- From: gaf at blu.org (Jerry Feldman)
- [Discuss] memory management
- From: bill.n1vux at gmail.com (Bill Ricker)
- [Discuss] memory management
- References:
- [Discuss] memory management
- From: me at mattgillen.net (Matthew Gillen)
- [Discuss] memory management
- From: abreauj at gmail.com (John Abreau)
- [Discuss] memory management
- From: me at mattgillen.net (Matthew Gillen)
- [Discuss] memory management
- From: slitt at troubleshooters.com (Steve Litt)
- [Discuss] memory management
- Prev by Date: [Discuss] SSD Drives
- Next by Date: [Discuss] memory management
- Previous by thread: [Discuss] memory management
- Next by thread: [Discuss] memory management
- Index(es):