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



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



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