Date: Mon, 18 Mar 2019 04:57:43 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Karl Denninger <karl@denninger.net>, freebsd-stable@freebsd.org Subject: Re: Observations from a ZFS reorganization on 12-STABLE Message-ID: <e5c648b4-ba73-5d3a-2924-be4d52e4c267@grosbein.net> In-Reply-To: <58eb1994-41bd-cd22-be66-0024bcbc36e6@denninger.net> References: <58eb1994-41bd-cd22-be66-0024bcbc36e6@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
17.03.2019 21:58, Karl Denninger wrote: > Huh? A simple *filesystem copy* managed to force a 16Gb system into > requiring page file backing store? > > I was able to complete the copy by temporarily adding the swap space > back on (where it would be when the move was complete) but that > requirement is pure insanity and it appears, from what I was able to > determine, that it came about from the same root cause that's been > plaguing VM/ZFS interaction since 2014 when I started work this issue -- > specifically, when RAM gets low rather than evict ARC (or clean up UMA > that is allocated but unused) the system will attempt to page out > working set. In this case since it couldn't page out working set since > there was nowhere to page it to the process involved got an OOM error > and was terminated. > > *I continue to argue that this decision is ALWAYS wrong.* I agree. Recently I've found kind-of-workaround for this problem: increase vm.v_free_min so when "FREE" memory goes low, page daemon wakes earlier and shrinks UMA (and ZFS ARC too) moving some memory from WIRED to FREE quick enough so it can be re-used before bad things happen. But avoid increasing vm.v_free_min too much (e.g. over 1/4 of total RAM) because kernel may start behaving strange. For 16Gb system it should be enough to raise vm.v_free_min upto 262144 (1GB) or 131072 (512M). This is not permanent solution in any way but it really helps.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e5c648b4-ba73-5d3a-2924-be4d52e4c267>