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



[gaf at gaf ~]$ ps -ef | grep firefox
gaf       2734  2259  8 06:31 tty2     00:03:27 /usr/lib64/firefox/firefox
gaf       3143  2734  0 06:32 tty2     00:00:01 
/usr/lib64/firefox/plugin-container 
/opt/google/talkplugin/libnpgoogletalk.so -greomni 
/usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja 
-appdir /usr/lib64/firefox/browser 2734 true plugin



On 06/23/2015 08:48 PM, John Abreau wrote:
> 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
>>
>
>

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




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