Date: Mon, 29 Jun 2020 06:17:31 -0700 From: Donald Wilde <dwilde1@gmail.com> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-stable@freebsd.org, ericbsd <ericbsd@freebsd.org>, bdrewery@freebsd.org Subject: Re: swap space issues Message-ID: <CAEC7393eRE9DaUq1P_KoEPBtUQoi%2BsQa6QtbNyNFS-nv04sX3g@mail.gmail.com> In-Reply-To: <EEE87A3D-5E15-4D88-AF7D-E48F9440CF54@yahoo.com> References: <EEE87A3D-5E15-4D88-AF7D-E48F9440CF54.ref@yahoo.com> <EEE87A3D-5E15-4D88-AF7D-E48F9440CF54@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] [adding maintainers of synth and ccache] On 6/29/20, Mark Millard <marklmi@yahoo.com> wrote: > Based on "small arm system" context experiments > mostly . . . > > If your console messasges do not include > messages about "swap_pager_getswapspace(...): failed", > then it is unlikely that being out of swap space > is the actual issue even when it reports: "was killed: > out of swap space" messages. For such contexts, making > the swap area bigger does not help. > It did not show those getswapspace messages. > In other words, "was killed: out of swap space" > is frequently a misnomer and not to be believed > for "why" the kill happened or what should be > done about it --without other evidence also being > present anyway. > > Other causes include: > > Sustained low free RAM (via stays-runnable processes). > A sufficiently delayed pageout. > The swap blk uma zone was exhausted. > The swap pctrie uma zone was exhausted. > > (stays-runnable processes are not swapped out > [kernel stacks are not swapped out] but do actively > compete for RAM via paging activity. In such a > context, free RAM can stay low.) > > The below material does not deal with the > the "exhausted" causes but does deal with > the other 2. > > Presuming that you are getting "was killed: out > of swap space" notices but are not getting > "swap_pager_getswapspace failed" notices and > that kern.maxswzone vs. system load has not > been adjusted in a way that leads to bad > memory tradeoffs . . . > > I recommend attempting use of, say, (from > my /etc/sysctl.conf ): > Attached is what I tried, but when I ran synth again, I got a corrupted HDD that fsck refuses to fix, whether in 1U mode or with fs mounted. It just will not SALVAGE even when I add the -y flag. What got corrupted was one of the /usr/.ccache directories, but 'ccache -C' doesn't clear it. I restored the original /etc/sysctl.conf, but I can't add packages or ports any more, so I'm afraid I'm going to have to dd if=/dev/zero the disk and reload from 12.1R and start over again. I can't even 'rm -Rf /usr/.ccache'. It says 'Directory not empty'. I don't need this system up and running, so I'm not going to make any more changes until I see if any of you have suggestions to try first. -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** [-- Attachment #2 --] # $FreeBSD: stable/12/sbin/sysctl/sysctl.conf 337624 2018-08-11 13:28:03Z brd $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 security.bsd.see_other_uids=0 security.bsd.see_other_gids=0 security.bsd.see_jail_proc=0 # # Delay when persistent low free RAM leads to # Out Of Memory killing of processes. The # delay is a count of kernel-attempts to gain # free RAM (so not time units). #vm.pageout_oom_seq=12 # default #vm.pageout_oom_seq=-1 # infinite (not sure exists ???) vm.pageout_oom_seq=120 # # 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 # infinite # # For possibly insufficient swap/paging space # (might run out), increase the pageout delay # that leads to Out Of Memory killing of # processes: vm.pfault_oom_attempts= 10 vm.pfault_oom_wait= 1 # (The multiplication is the total but there # are other potential tradoffs in the factors # multiplied for the same total.) #Note: As of stable/12 -r351776 , stable got #support for vm.pfault_oom_attempts and #vm.vm.pfault_oom_wait via an MFC. Stable has #had support for vm.pageout_oom_seq for #much longer than that. # #Note: Larger values of vm.pageout_oom_seq #will wait even longer. The default value is #12 (last I checked). No figure turns off #the specific mechanism as far as I know. #
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAEC7393eRE9DaUq1P_KoEPBtUQoi%2BsQa6QtbNyNFS-nv04sX3g>