Date: Sun, 5 Jan 2020 11:58:48 -0800 From: Mark Millard <marklmi@yahoo.com> To: Wojciech Puchar <wojtek@puchar.net> Cc: freebsd-hackers@freebsd.org Subject: Re: processes are killed because of out of swap space Message-ID: <9C6B115C-90CC-449D-A29D-429BD97F37C4@yahoo.com> In-Reply-To: <alpine.BSF.2.20.2001051408100.3906@puchar.net> References: <C1C8F724-88B0-49D9-A9DF-DB0AA8AF3164.ref@yahoo.com> <C1C8F724-88B0-49D9-A9DF-DB0AA8AF3164@yahoo.com> <alpine.BSF.2.20.2001051307080.18098@puchar.net> <alpine.BSF.2.20.2001051408100.3906@puchar.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Jan-5, at 05:08, Wojciech Puchar <wojtek@puchar.net> wrote: >=20 >>> 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. >>=20 >> 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). >>=20 >>=20 >> but still - there is A LOT of memory to be reclaimed. inactive is = many gigabytes on my server. >>=20 >>> # Delay when persisstent low free RAM leads to >>> # Out Of Memory killing of processes: >>> vm.pageout_oom_seq=3D120 >> 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=3D-1 >>=20 >> 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=3D12 to vm.pageout_oom_seq=3D300 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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9C6B115C-90CC-449D-A29D-429BD97F37C4>