Ubuntu – How to prevent running programs from consuming all RAM and CPU

cpu loadgoogle-chromememory usageresponsiveness

I have an annoying problem with Ubuntu's resource management. Frequently it happens that some programs such as Google Chrome browser consume 100% CPU and most of my laptops memory.

I want to have a responsive OS all the time, it means that I want to be able to switch between programs and move my mouse on the screen or switch to a tty and give commands to the OS. Therefore I look for a way to configure the OS to reserve lets say 10% of system resources for itself. Currently Ubuntu does not behave this way, frequently chrome consumes all my CPU and memory and then the system becomes unresponsive, and of course I can't wait more that a minute or two so I have to long press power button.

Is there any way to make Ubuntu to be always responsive? At least to that extent that I can kill the resource hungry program? ( I know the kernel will eventually kill some programs to free some space but I want to force it to do it either faster or reserve more resources for itself)

Version: UBUNTU 14.04
~$ uname -a
Linux spielplatz 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

CPU: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz

Update (8 October 2017)

The best solution that I have found so far is using cgroups. There is a gist for that.

Best Answer

I've used cpulimit to "throttle" out-of-control CPU hungry programs before (Xfce4 Mailwatch Plugin gets hung up & grabs 100% CPU sometimes). cpulimit is a:

tool for limiting the CPU usage of a process

cpulimit is a simple program that attempts to limit the CPU usage of a process (expressed in percentage, not in CPU time). This is useful to control batch jobs, when you don't want them to eat too much CPU. It does not act on the nice value or other priority stuff, but on the real CPU usage.
Besides it is able to adapt itself to the overall system load, dynamically and quickly.

It works by monitoring the target process, and sending "the SIGSTOP and SIGCONT signals to a process, both to verify that it can control it and to limit the average amount of CPU it consumes." See:

It should make the rest of your OS more responsive, but I've tried it on Firefox and it tends to render it much less responsive, so may not be the best answer for the Chrome browser. Searching for ways to speed up Chrome itself might be more fruitful.

If you just want a good way to see how much CPU & RAM is in use, and what processes are using them, I'd suggest a system monitoring program (like top, htop, I prefer conky), then when you see something eating all your cpu or ram you can close/restart, etc.

If you're interested in knowing what programs get scheduled to run first, look into scheduling priority & "niceness". Perhaps you could make Chrome act "nicer" without crippling it.
Here's a clip from info coreutils 'nice invocation':

'nice' prints a process's "niceness", or runs a command with modified niceness. "niceness" affects how favorably the process is scheduled in the system.

Niceness values range at least from -20 (process has high priority and gets more resources, thus slowing down other processes) through 19 (process has lower priority and runs slowly itself, but has less impact on the speed of other running processes). Some systems may have a wider range of niceness values; conversely, other systems may enforce more restrictive limits. An attempt to set the niceness outside the supported range is treated as an attempt to use the minimum or maximum supported value.

A niceness should not be confused with a scheduling priority, which lets applications determine the order in which threads are scheduled to run. Unlike a priority, a niceness is merely advice to the scheduler, which the scheduler is free to ignore. Also, as a point of terminology, POSIX defines the behavior of 'nice' in terms of a "nice value", which is the nonnegative difference between a niceness and the minimum niceness. Though 'nice' conforms to POSIX, its documentation and diagnostics use the term "niceness" for compatibility with historical practice.

And here are a few useful-looking links about scheduling

And muru's comment/post on Cgroups (on ArchWiki) looks good, about limiting ram, looks like it could limit CPU cores & "shares" too ("By default all groups have 1024 shares. A group with 100 shares will get a ~10% portion of the CPU time").

The first paragraph of the ArchWiki article also mentions this potentially useful option, though I think they're mainly for limiting users/groups, see:man pam_limits & man limits.conf

Related Question