On Wed 14-08-19 23:06:04, Edward Chron wrote:
> For an OOM event: print oom_score_adj value for the OOM Killed process
> to document what the oom score adjust value was at the time the process
> at the time of the OOM event. The value can be set by the user and it
> effects the resulting oom_score
On Wed 14-08-19 23:24:51, Edward Chron wrote:
> On Mon, Aug 12, 2019 at 4:42 AM Michal Hocko wrote:
> >
> > On Fri 09-08-19 15:15:18, Edward Chron wrote:
> > [...]
> > > So it is optimal if you only have to go and find the correct log and
> > > search
> > > or run your script(s) when you absolute
On Mon, Aug 12, 2019 at 4:42 AM Michal Hocko wrote:
>
> On Fri 09-08-19 15:15:18, Edward Chron wrote:
> [...]
> > So it is optimal if you only have to go and find the correct log and search
> > or run your script(s) when you absolutely need to, not on every OOM event.
>
> OK, understood.
>
> > Tha
For an OOM event: print oom_score_adj value for the OOM Killed process
to document what the oom score adjust value was at the time the process
at the time of the OOM event. The value can be set by the user and it
effects the resulting oom_score so useful to document this value.
Sample message outp
On Fri 09-08-19 15:15:18, Edward Chron wrote:
[...]
> So it is optimal if you only have to go and find the correct log and search
> or run your script(s) when you absolutely need to, not on every OOM event.
OK, understood.
> That is the whole point of triage and triage is easier when you have
> r
Sorry about top posting, responses inline.
On Thu, Aug 8, 2019 at 11:40 PM Michal Hocko wrote:
>
> [Again, please do not top post - it makes a mess of any longer
> discussion]
>
> On Thu 08-08-19 15:15:12, Edward Chron wrote:
> > In our experience far more (99.9%+) OOM events are not kernel issue
[Again, please do not top post - it makes a mess of any longer
discussion]
On Thu 08-08-19 15:15:12, Edward Chron wrote:
> In our experience far more (99.9%+) OOM events are not kernel issues,
> they're user task memory issues.
> Properly maintained Linux kernel only rarely have issues.
> So usefu
In our experience far more (99.9%+) OOM events are not kernel issues,
they're user task memory issues.
Properly maintained Linux kernel only rarely have issues.
So useful information about the killed task, displayed in a manner
that can be quickly digested, is very helpful.
But it turns out the tot
[please do not top-post]
On Thu 08-08-19 12:21:30, Edward Chron wrote:
> It is helpful to the admin that looks at the kill message and records this
> information. OOMs can come in bunches.
> Knowing how much resource the oom selected process was using at the time of
> the OOM event is very useful,
On Thu 08-08-19 11:32:47, Edward Chron wrote:
> For an OOM event: print oomscore, memory pct, oom adjustment of the process
> that OOM kills and the totalpages value in kB (KiB) used in the calculation
> with the OOM killed process message. This is helpful to document why the
> process was selected
For an OOM event: print oomscore, memory pct, oom adjustment of the process
that OOM kills and the totalpages value in kB (KiB) used in the calculation
with the OOM killed process message. This is helpful to document why the
process was selected by OOM at the time of the OOM event.
Sample message
11 matches
Mail list logo
