On 20/06/2018 02:59, Jeremy Chadwick wrote:
> In short (and nebulous as hell; sorry, I cannot be more specific given
> the nature of the problem): there have been changes about ZFS's memory
> allocation/releasing decision-making scheme compared to ZFS on
"older"
> FreeBSD (i.e. earlier 11.x, and definitely 10.x and 9.x).
I would say the issues started with 10.x, I never had memory issues
using 9.x with ZFS. I first had all ram marked wired when testing 10.1.
> Recommendations like "limit your ARC" are nothing new in FreeBSD,
but
> are still ridiculous kludges: tech-lists' system clearly has 105GB MRU
> (MRU = most recently used) in ARC, meaning there is memory that can be
> released back to the rest of the OS for general use (re: memory
> contention/pressure situation), but the OS is choosing to use swap
> instead, eventually exhausting it. That logic sounds broken, IMO. (And
> yes I did notice the size of bhyve process)
This review is aiming to fix this -
https://reviews.freebsd.org/D7538
I have been running the patch on stable/11 and after eight days uptime I
still have zero swap in use, I can't recall a time in the last few years
that I have had no swap usage past the first hour or two uptime.
As I have commented in that review, the issue I am seeing is that
arc_max is not counted when testing max_wired, the two together can add
up to more than the physical ram and wiring all physical ram can push
ram used by processes out to swap. I know with 8G physical ram having
over 7G wired is not recoverable.
max_wired seems to default to 30% ram (5G with 16G ram) I have never
seen this mentioned in any zfs tuning, it should be subtracted from
physical ram when calculating arc_max.
arc_max should never be greater than (kmem_size - max_wired - padding)
--
FreeBSD - the place to B...Storing Data
Shane Ambler