>You can limit the process with cgroups In this case the process will be killed by OOM killer. Note that OOM killer exists by default. Limiting cgroup means the OOM killer will be invoked in the cgroup. With earlyoom you database server will get SIGTERM and maybe will gracefully shutdown.
пт, 10 июл. 2020 г. в 00:10, John M. Harris Jr <joh...@splentity.com>: > On Thursday, July 9, 2020 7:57:25 AM MST Reindl Harald (privat) wrote: > > Am 09.07.20 um 16:53 schrieb John M. Harris Jr: > > > On Thursday, July 9, 2020 6:24:41 AM MST Sergio Belkin wrote: > > >> +1 This would be a genuine improvement for end users! > > > > > > In what way do you believe this will be an improvement for end users? > By > > > killing their software, while it's legitimately using RAM, as expected? > > > How > > > exactly is that beneficial? If anything, this is actively working > against > > > the best interests of the end user. > > > > could you just shutup about topics you don't understand? > > I understand exactly what EarlyOOM does, which is precisely why I take > issue > with enabling this by default. > > > my co-developer had a recursion in his code and after a few seconds the > > machine was completly unresponsible due debugging the root cause > > That doesn't sound like anything to do with recursion, but either a memory > leak, or unchecked allocation. It may help to limit the amount of memory > that > specific program can use, in order to help debug the issue. > > > even power-key took *15 minutes* for a clean shutdown while he was > > tempted to hard power off the machine which is not much fun witch 32 GB > > RAM and all sort of database services > > Yeah, OOM situations are never fun. However, with all sorts of database > services, you wouldn't want something killing processes all willy nilly. > > > guess what was the solution: kill the fucking httpd worker before it > > kills the system > > You can limit the process with cgroups, so that only the software you > actually > intend to limit is affected, and the rest works as you'd expect. > > -- > John M. Harris, Jr. > Splentity > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
