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.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 03.01.2020 20:18, Ben Cotton wrote:
> Workstation working group has discussed "better interactivity in
> low-memory situations" for some months. In certain use cases,
> typically compiling, if all RAM and swap are completely consumed,
> system responsiveness becomes so abysmal that a reasonable
Den lör 4 jan. 2020 kl 01:53 skrev John M. Harris Jr :
> On Friday, January 3, 2020 4:25:20 PM MST Chris Murphy wrote:
> > in the cases were I could issue syrq+b, responsiveness was so bad
> > it'd take upwards of 15 minutes just to type out the command
>
> In that case, I'd suggest waiting the
On Friday, January 3, 2020 4:25:20 PM MST Chris Murphy wrote:
> in the cases were I could issue syrq+b, responsiveness was so bad
> it'd take upwards of 15 minutes just to type out the command
In that case, I'd suggest waiting the 15 minutes, and then not bogging down
your system that badly the
On Fri, Jan 3, 2020 at 4:13 PM Tom Seewald wrote:
>
> I think this would be a really big improvement for workstation and other
> desktop spins, the handling of out of memory situations have been a
> consistent paint point on Linux. However, may I ask why EarlyOOM was chosen
> over something
On Fri, Jan 3, 2020 at 3:57 PM John M. Harris Jr wrote:
>
> There is NO scenario in which hard shutdowns should occur, except battery
> failure on mobile devices. The state of the system on boot will vary wildly
> from what you may expect when it is hard powered off. I would suggest using
> SysRq
John M. Harris Jr wrote:
> There is NO scenario in which hard shutdowns should occur, except battery
> failure on mobile devices. The state of the system on boot will vary
> wildly from what you may expect when it is hard powered off. I would
> suggest using SysRq in such events.
Unfortunately,
I think this would be a really big improvement for workstation and other
desktop spins, the handling of out of memory situations have been a consistent
paint point on Linux. However, may I ask why EarlyOOM was chosen over
something like NoHang [1]? I am a bit concerned that EarlyOOM's
drago01 wrote:
> The idea might be the implementation is not.
> Using a percentage to decide "almost out of memory" is going to hurt on
> systems with large amounts of memory be it a 32gb desktop or a 2tb server.
> You'd have plenty of memory left and it starts killing processes ...
And it will
On Friday, January 3, 2020 3:48:50 PM MST Chris Murphy wrote:
> On Fri, Jan 3, 2020 at 1:51 PM Robbie Harwood wrote:
>
> >
> >
> > Another thought. Wouldn't some of the pain here be alleviated by
> > setting vm.swappiness=0?
>
>
> My sample size is not scientific. But, in my testing I can't
On Fri, Jan 3, 2020 at 3:41 PM drago01 wrote:
>
>
>
> On Friday, January 3, 2020, Neal Gompa wrote:
>>
>> On Fri, Jan 3, 2020 at 2:19 PM Ben Cotton wrote:
>> >
>> > https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>> >
>> > == Summary ==
>> > Install earlyoom package, and enable it by
On Fri, Jan 3, 2020 at 1:51 PM Robbie Harwood wrote:
>
> Another thought. Wouldn't some of the pain here be alleviated by
> setting vm.swappiness=0?
My sample size is not scientific. But, in my testing I can't tell any
difference for the swap under pressure case we're testing against. The
On Friday, January 3, 2020, Neal Gompa wrote:
> On Fri, Jan 3, 2020 at 2:19 PM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/EnableEarlyoom
> >
> > == Summary ==
> > Install earlyoom package, and enable it by default. This will cause
> > the kernel oomkiller to trigger
On Fri, Jan 3, 2020 at 2:19 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>
> == Summary ==
> Install earlyoom package, and enable it by default. This will cause
> the kernel oomkiller to trigger sooner, but will not affect which
> process it chooses to kill off.
On Fri, Jan 3, 2020 at 10:14 PM John M. Harris Jr
wrote:
> Regardless, if this Change is accepted, it should probably be done on a
> per-
> spin basis. If the GNOME Spin wants this, that's one thing, but I don't
> believe this would be a good idea on servers.
>
Yes, and if you read the change
On Fri, Jan 3, 2020 at 1:35 PM Robbie Harwood wrote:
>
> The OOM killer is a kernel function.
Yes, this is indicated in the summary.
>I have no opinion on this proposal
> as it stands, but I would like it to include an explanation of why this
> requires a service in userspace to fix.
The 2nd
On Friday, January 3, 2020 1:51:00 PM MST Robbie Harwood wrote:
> Robbie Harwood writes:
> > Ben Cotton writes:
> >> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
> >>
> >> == Summary ==
> >> Install earlyoom package, and enable it by default. This will cause
> >> the kernel oomkiller
Robbie Harwood writes:
> Ben Cotton writes:
>
>> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>>
>> == Summary ==
>> Install earlyoom package, and enable it by default. This will cause
>> the kernel oomkiller to trigger sooner, but will not affect which
>> process it chooses to kill
Ben Cotton writes:
> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>
> == Summary ==
> Install earlyoom package, and enable it by default. This will cause
> the kernel oomkiller to trigger sooner, but will not affect which
> process it chooses to kill off. The idea is to recover from out
https://fedoraproject.org/wiki/Changes/EnableEarlyoom
== Summary ==
Install earlyoom package, and enable it by default. This will cause
the kernel oomkiller to trigger sooner, but will not affect which
process it chooses to kill off. The idea is to recover from out of
memory situations sooner,
101 - 120 of 120 matches
Mail list logo
