Bug 235494 - Excessive OOM killing
Summary: Excessive OOM killing
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: stress2
Depends on:
Blocks:
 
Reported: 2019-02-04 14:23 UTC by Peter Holm
Modified: 2019-02-04 19:26 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Holm freebsd_committer 2019-02-04 14:23:53 UTC
Small test program using ports/devel/libmill triggers OOM.
Original report: https://lists.freebsd.org/pipermail/freebsd-stable/2017-December/088113.html

Latest test: https://people.freebsd.org/~pho/stress/log/chain.txt
Comment 1 Mark Millard 2019-02-04 19:13:15 UTC
FreeBSD does OOM killing based on its own criteria for being unable to
achieve sufficient free RAM after enough tries to gain more free RAM,
even when there is lots of swap space available. (Trying to buildworld
with -j4 on 1 GByte 4-core armv7/aarch64 systems tend to have this issue
show up when configured with sufficient swap.)

The number of tries is configurable via increasing vm.pageout_oom_seq
(default 12 last I knew). Such has been sufficient for those small arm
systems doing such builds, using figures like 120 or 1024 or even more.

But it looks like you are also running out of swap as well: the messages

swap_pager_getswapspace(32): failed

indicate that. (Some messages mentioning "out of swap" can be misnomers for
some contexts, with the lack of free RAM actually driving the messages to
show up independent of the swap space available.)

Can you do something to monitor your free RAM availability and swap space
availability as things progress? It might suggest some sort of leaking
resource(s).
Comment 2 Peter Holm freebsd_committer 2019-02-04 19:26:23 UTC
(In reply to Mark Millard from comment #1)
Sorry, I should have mentioned that this just a reminder for a problem found with a broken test program (which leaks). That is, this is a stress test program.