[Discuss] memory management

[gaf at blu.org (Jerry Feldman)]

[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