Is it normal that a user can take down the whole system by using too much memory?

Polytropon freebsd at
Sun Jun 3 19:09:31 UTC 2018

On Sat, 02 Jun 2018 19:25:31 -0400, Brennan Vincent wrote:
> I'm also curious, however, to learn more from an OS design perspective.
> Why isn't it possible for the kernel to realize it should kill `eatmem`
> rather than make the system unusable?
> Is this a hard problem in general, or just a missing feature in FreeBSD
> specifically ?

It's more about what the kernel's basic function is: to control
the interactions of hardware and software. In case of "eatmem"
or any other program that allocates memory, there _might_ be a
totally valid and legitimate (!) reason for a problem program
to do so. If physical RAM has been consumed, swap will be added.
This is still within normal margins of system use. Just consider
today's memory-intensive user applications like web browsers.
At which threshold should the kernel say: "Okay, no more RAM
for you, please go kill yourself, or I will do it in 60 seconds.",
which is (more or less) what you seem to expect?

Resource control mechanisms are present in FreeBSD, but it takes
a system administrator with sufficient knowledge and experience
to decide about the values that will apply - how much RAM can be
consumed, how many child processes can be spawned, how many files
can be held open... and so on. There just is no system default
that can be preconfigured, calculated, assumed, guessed, or
arbitrarily chosen. No "one size fits all" solution is possible.

Just take the following example: A problem program will do some
database lookup, store lots of data in memory, then calculate
something from it, build another set of memory-intensive struc-
tures, and then start heavy disk I/O do write lots of result
files. This might require more RAM than the system has. Let's
say it's 64 GB. The program now needs 80 GB, so swap will be
used. After a period of heavy system activity, memory will be
released again. Load values go back to normal.

For this example, try to imagine at what stage the kernel should
interfere. And _should_ it interfere? From the practical point
of view, everything worked as it was intended and expected.

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

More information about the freebsd-questions mailing list