processes are killed because of out of swap space
Mark Millard
marklmi at yahoo.com
Sun Jan 5 19:58:54 UTC 2020
On 2020-Jan-5, at 05:08, Wojciech Puchar <wojtek at puchar.net> wrote:
>
>>> If you are not seeing such swap_pager_getswapspace messages, then
>>> it is likely that the mount of swap space still available is not the
>>> actual thing driving the kills.
>>> Another thing that can lead to kills is paging I/O that is
>>> slow.
>>
>> paging device is nvd so it's fast. And system isn't even paging heavily. but is doing geom_raid5 rebuild right now+copying lots of files to this raid (new RAID5 just created).
>>
>>
>> but still - there is A LOT of memory to be reclaimed. inactive is many gigabytes on my server.
>>
>>> # Delay when persisstent low free RAM leads to
>>> # Out Of Memory killing of processes:
>>> vm.pageout_oom_seq=120
>> set to 300.
A good question is if changing this figure significantly
changes how long before the OOM kills significantly.
If it does not take significantly different time to
start OOM kills, then vm.pageout_oom_seq criteria
is not what is leading to the kills.
As far as I know, that is the only way to test for if
vm.pageout_oom_seq criteria are the criteria leading to
the kills vs. it being something else. (Short of source
code changes, anyway.)
>>> some free RAM.)
>>> #
>>> # For plunty of swap/paging space (will not
>>> # run out), avoid pageout delays leading to
>>> # Out Of Memory killing of processes:
>>> vm.pfault_oom_attempts=-1
>>
>> i don't have such sysctl. is it in FreeBSD 12?
>> i have 11.3
vm.pfault_oom_attempts is in head (13). I've not
checked on any potential the MFC status but forgot
to mention that. Sorry for the confusion.
> after changes - no effect
If going from vm.pageout_oom_seq=12 to
vm.pageout_oom_seq=300 did not change the
time frame for the OOM kills starting to
happen, then vm.pageout_oom_seq criteria
are not what is driving the kills.
Unfortunately, I'm not aware of another
(non-source-code) ways to discover what
crieria are leading to the OOM kills.
Changing source code would require first
analyzing it --or someone already familiar
would need to provide the source code
changes.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-hackers
mailing list