On Sat, Jan 4, 2020 at 7:32 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Sat, Jan 4, 2020 at 4:48 AM drago01 <drago01@xxxxxxxxx> wrote: > > > > > > > > On Saturday, January 4, 2020, Neal Gompa <ngompa13@xxxxxxxxx> wrote: > >> > >> On Sat, Jan 4, 2020 at 2:33 AM Vitaly Zaitsev via devel > >> <devel@xxxxxxxxxxxxxxxxxxxxxxx> 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). > > It might be. And it might need to be tweaked. Perhaps 6% for SIGTERM > and 3% for SIGKILL. Or even 5% and 2.5%. For sure using a percentage > of RAM and swap is too simplistic. But it's easy for users to > understand. Something more sophisticated, based on kernel pressure > stall information would likely be better, and folks are working on > that. Yes that would be a way better metric than a percent value which is either to close to full ram or to early if you have lots of ram. 6% of 4GB is 254MB while for 32GB its almost 2GB - killing processes while you have 2GB left is just wasteful. > > > > 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). > > That's not a fix either, it's a work around that papers over the > problem. Same as earlyoom, except RAM costs money, and may not be an > option due to hardware limitations. A modern operating system needs to > know better than to allow unprivileged processes to take down the > whole system. I think you misunderstood me. Yes the OS should behave better than this but if you are running a server you don't want your DB, web server to not be reachable because the system run out of memory - the only way to "fix" that is to provide enough resources. No amount of OOM killing would help you here. The system may be up but not the server process the machine is running for ... > > > 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). > > Can you be more specific? > > On getfedora.org it reads: > Fedora requires a minimum of 20GB disk, 2GB RAM, to install and run > successfully. Double those amounts is recommended. I simply do not think 2GB is sufficient, the "recommended double" i.e 4GB should be the "required" and drop the double part all together. A modern desktop with apps on top will not run well enough on 2GB, lets stop pretending it does. But anyways that's off topic as it is not part of the proposal. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
