cloud January 2020

cloud@lists.fedoraproject.org

2 participants
6 discussions

[Fedocal] Reminder meeting : Fedora Cloud Workgroup
by dusty＠dustymabe.com 27 Jan '20

27 Jan '20

Dear all, You are kindly invited to the meeting: Fedora Cloud Workgroup on 2020-01-29 from 17:00:00 to 18:00:00 UTC At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Standing meeting for the Fedora Cloud Workgroup Source: https://apps.fedoraproject.org/calendar/meeting/1999/

1 0

OOM managers, resource control
by Chris Murphy 21 Jan '20

21 Jan '20

Hi, Workstation working group continues to evaluate oom managers and seek input from domain experts on the subject. I've come across this video from the All Systems Go conference, on the larger subject of resource control. Its server+cloud+container oriented. So I think it speaks directly to your use cases. Resource Control (2019) Dan Schatzberg https://www.youtube.com/watch?v=30i7SamZxRU I'm looking into setting up a discussion session with Dan, and do some Q&A. I'll report back when I know more about that. -- Chris Murphy

1 0

[Fedocal] Reminder meeting : Fedora Cloud Workgroup
by dusty＠dustymabe.com 20 Jan '20

20 Jan '20

Dear all, You are kindly invited to the meeting: Fedora Cloud Workgroup on 2020-01-22 from 17:00:00 to 18:00:00 UTC At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Standing meeting for the Fedora Cloud Workgroup Source: https://apps.fedoraproject.org/calendar/meeting/1999/

1 0

earlyoom by default
by Chris Murphy 13 Jan '20

13 Jan '20

Hi server@ and cloud@ folks, There is a system-wide change to enable earlyoom by default on Fedora Workstation. It came up in today's Workstation working group meeting that I should give you folks a heads up about opting into this change. Proposal https://fedoraproject.org/wiki/Changes/EnableEarlyoom Devel@ discussion https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… The main issue on a workstation, heavy swap leading to an unresponsive system, is perhaps not as immediately frustrating on a server. But the consequences of indefinite hang or the kernel oom-killer triggering, which is a SIGKILL, are perhaps worse. On the plus side, earlyoom is easy to understand, and its first attempt is a SIGTERM rather than SIGKILL. It uses oom_score, same as kernel oom-killer, to determine the victim. The SIGTERM is issued to the process with the highest oom_score only if both memory and swap reach 10% free. And SIGKILL is issued to the process with the highest oom_score once memory and swap reach 5% free. Those percentages can be tweaked, but the KILL percentage is always 1/2 of the TERM percentage, so it's a bit rudimentary. One small concern I have is, what if there's no swap? That's probably uncommon for servers, but I'm not sure about cloud. But in this case, SIGTERM happens at 10% of RAM, which leaves a lot of memory on the table, and for a server with significant resources it's probably too high. What about 4%? Maybe still too high? One option I'm thinking of is a systemd conditional that would not run earlyoom on systems without a swap device, which would leave these systems no worse off than they are right now. [i.e. they eventually recover (?), indefinitely hang (likely), or oom-killer finally kills something (less likely).] I've been testing earlyoom, nohang, and the kernel oom-killer for > 6 months now, and I think it would be completely sane for Server and Cloud products to enable earlyoom by default for fc32, while evaluating other solutions that can be more server oriented (e.g. nohang, oomd, possibly others) for fc33/fc34. What is clear: this isn't going to be solved by kernel folks, the kernel oom-killer only cares about keeping the kernel alive, it doesn't care about user space at all. In the cases where this becomes a problem, either the kernel hangs indefinitely or does SIGKILL for your database or whatever is eating up resources. Whereas at least earlyoom's first attempt is a SIGTERM so it has a chance of gracefully quitting. There are some concerns, those are in the devel@ thread, and I expect they'll be adequately addressed or the feature will not pass the FESCo vote. But as a short term solution while evaluating more sophisticated solutions, I think this is a good call so I thought I'd just mention it, in case you folks want to be included in the change. -- Chris Murphy

2 4

[Fedocal] Reminder meeting : Fedora Cloud Workgroup
by dusty＠dustymabe.com 13 Jan '20

13 Jan '20

Dear all, You are kindly invited to the meeting: Fedora Cloud Workgroup on 2020-01-15 from 17:00:00 to 18:00:00 UTC At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Standing meeting for the Fedora Cloud Workgroup Source: https://apps.fedoraproject.org/calendar/meeting/1999/

1 0

[Fedocal] Reminder meeting : Fedora Cloud Workgroup
by dusty＠dustymabe.com 06 Jan '20

06 Jan '20

Dear all, You are kindly invited to the meeting: Fedora Cloud Workgroup on 2020-01-08 from 17:00:00 to 18:00:00 UTC At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Standing meeting for the Fedora Cloud Workgroup Source: https://apps.fedoraproject.org/calendar/meeting/1999/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud January 2020