Sotiris Lamprinidis<[email protected]> writes: > Hi, > > I looked into exposing ZFS tunables through sysctl and it seems > straightforward. Despite being under "dist" I am not sure if this is true > upstream, so the patch is directly on arc.c (and I think it'd be tricky to > implement otherwise). > > I tested arc_min and arc_max, and it seems like changes do have an effect > (e.g. on c, c_max). Additionally tested arc_free_target and it does have > an effect also. > > Here are the new sysctl values on boot on a 8G system: > > vfs.zfs.arc_min = 392903680 > vfs.zfs.arc_max = 3143229440 > vfs.zfs.arc_average_blocksize = 8192 > vfs.zfs.arc_shrink_shift = 7 > vfs.zfs.compressed_arc_enable = 1 > vfs.zfs.arc_meta_limit = 785807360 > vfs.zfs.arc_meta_min = 0 > vfs.zfs.arc_free_target = 682 > > > Cc'ing kre and martin because you worked on the ZFS source last. Hope > somebody finds this useful and I'd appreciate any feedback! > > S. > > > Index: external/cddl/osnet/dist/uts/common/fs/zfs/arc.c > =================================================================== > RCS file: /cvsroot/src/external/cddl/osnet/dist/uts/common/fs/zfs/arc.c,v
[snip diff] Thank you very much for this patch. I have been struggling with ZFS on a 8 to 16GB DOMU build system for quite a while and with this patch and setting the values to what you have listed I was able to perform my abuse builds without any problems at all. 100% workable with 4 parallel builds all using the 2 CPUs I give to the DOMU. Before this I could do one or two full system builds before I would have to reboot the build box and I was pretty much unable to do more than 2 parallel builds at a time without locking the system up. Clamping the size of the ARC seems to be the key. One work around I was trying to use was setting the maxvnodes to a very low value and that work around could be removed as well. I am running this on a -current as of 2026-07-15. This find is very much appreciated. Thanks again. -- Brad Spencer - [email protected]
