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

That you can't easily do this is odd, because other system resources
have reserves (e.g. filesystems tend to have a small percentage reserved
for root; the system-wide limit for process handles has some set-aside
for root).  For some reason having some mlock()'d memory reserved is
harder...

Thanks,
Matt




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