On Saturday, January 4, 2020, Neal Gompa <ngompa13@gmail.com> wrote:
On Sat, Jan 4, 2020 at 2:33 AM Vitaly Zaitsev via devel
<devel@lists.fedoraproject.org> wrote:
>
> On 03.01.2020 22:27, Neal Gompa wrote:
> > and servers...
>
> Admins will be very happy when such user-space killer will kill for
> example PgSQL database server and cause DB corruption or loss of banking
> transactions.
>

This is already happening anyway. The idea is that earlyoom will just
do it slightly earlier so we have a responsive system when the
failures happen. Unlike a lot of the other options, earlyoom is just
doing what the kernel does, just slightly earlier so that the system
doesn't become unresponsive. 


That is *hugely* valuable for sysadmins
to be able to recover the systems without power cycling. As a sysadmin
myself, I *hate* power cycling servers because it takes forever and
its a lot bigger loss of productivity (and potentially money!

Except that slightly earlier is way to early on systems which have lots of memory (see mails from before).

And if a server runs into a oom situation your software is either broken (leaking) or you didn't allocate enough resources for your use case.

So the fix is not oom killing nor power cycling but to either allocate more memory of it is a VM or buy more if it is a hardware server (or fix the memory leak in your software).

As for the desktop case the running web browers in a cgroup to keep them in check would solve most real world problems - other common desktop apps don't use enough memory to cause such issues (unless your system is really memory constrained but then the "buy more memory" solution is the better fix). 

And btw we should really update the minimum memory requirements in our documentation, the current ones have nothing to do with reality (if you want a pleasant user experience).