Same here using mfsbsd from 11-RELEASE. First attempt I forgot to add swap - it killed the ssh I was using to issue a zfs send on the remote system.
Next attempt I added swap, but ssh got killed too. Third attempt I used mfsbsd from 12-RELEASE. It succeeded. Now I am using mfsbsd 11-RELEASE with added swap and vis.zfs.arc_min and arc_max to 128Mb (it is a 4GB system) and it succeeds > On 18 Mar 2019, at 15:14, Karl Denninger <k...@denninger.net> wrote: > > On 3/18/2019 08:37, Walter Cramer wrote: >> I suggest caution in raising vm.v_free_min, at least on 11.2-RELEASE >> systems with less RAM. I tried "65536" (256MB) on a 4GB mini-server, >> with vfs.zfs.arc_max of 2.5GB. Bad things happened when the cron >> daemon merely tried to run `periodic daily`. >> >> A few more details - ARC was mostly full, and "bad things" was 1: >> `pagedaemon` seemed to be thrashing memory - using 100% of CPU, with >> little disk activity, and 2: many normal processes seemed unable to >> run. The latter is probably explained by `man 3 sysctl` (see entry for >> "VM_V_FREE_MIN"). >> >> >> On Mon, 18 Mar 2019, Pete French wrote: >> >>> On 17/03/2019 21:57, Eugene Grosbein wrote: >>>> 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. >>> >>> Ah, thats very interesting, thankyou for that! I;ve been bitten by >>> this issue too in the past, and it is (as mentioned) much improved on >>> 12, but the act it could still cause issues worries me. >>> > Raising free_target should *not* result in that sort of thrashing. > However, that's not really a fix standing alone either since the > underlying problem is not being addressed by either change. It is > especially dangerous to raise the pager wakeup thresholds if you still > run into UMA allocated-but-not-in-use not being cleared out issues as > there's a risk of severe pathological behavior arising that's worse than > the original problem. > > 11.1 and before (I didn't have enough operational experience with 11.2 > to know, as I went to 12.x from mostly-11.1 installs around here) were > essentially unusable in my workload without either my patch set or the > Phabricator one. > > This is *very* workload-specific however, or nobody would use ZFS on > earlier releases, and many do without significant problems. > > -- > Karl Denninger > k...@denninger.net <mailto:k...@denninger.net> <mailto:k...@denninger.net > <mailto:k...@denninger.net>> > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
