>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 <johnmh@xxxxxxxxxxxxx>:
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@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
_______________________________________________ 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
