vfs.zfs.arc_max has immediate effect

Status
Not open for further replies.

DrKK

FreeNAS Generalissimo
Joined
Oct 15, 2013
Messages
3,630
So, first of all, I apologize if everyone knew this except for me and some of the guys in the Mumble server, but:

I was surprised to learn that manually adjusting the loader (or, what WAS a loader) variable
Code:
vfs.zfs.arc_max
takes immediate effect. The reason this sometimes comes up is that if you have modest RAM on a modest FreeNAS, and you had a few nasty jails (e.g., something with SQL databases, maybe something with openjdk, like the Unifi software, whatever), you could find yourself occasionally swapping out unexpectedly. @m0nkey_ found himself swapped out a few hundred MiB tonight, for example. So what you could do in these cases---if you are sufficiently bothered by swap coming into play, which there's no reason to be in many cases---is you would just hard limit the ARC to leave, say, 4 or so GiB untouchable to the ARC. In the past, you set this as the "loader" tunable mentioned above, and you had to reboot before it had effect. Tonight, as I said, @m0nkey_ had reason to trim his arc_max down by a couple GiB, and as I'm informing him he has to reboot for it to take effect, he notes that instantaneously his ZFS MFU/MRU ARC trimmed itself back to the requested maximums right away. That definitely was not the case even a year ago. Allan confirmed that this is a FreeBSD 11 feature than has been merged back a few months ago into FreeBSD 10, and hence, has been part of the FreeNAS 9.10 train for some period of time spanning at least a few months.

This is voodoo that the majority of FreeNAS users probably don't need to mess with in the course of their day, but I was still surprised by it, so I'm putting it out there for anyone that, like me, isn't as diligent about reading all of the changelogs for the backing OS.

That is all. Carry on.
 

Dice

Wizard
Joined
Dec 11, 2015
Messages
1,410
Status
Not open for further replies.
Top