Re: Suggest changing dirhash defaults for FreeBSD 9.2.
On 8/27/2013 9:40 AM, Sergey Kandaurov wrote: On 27 August 2013 16:41, Robert Burmeister wrote: I have been experimenting with dirhash settings, and have scoured the internet for other peoples' experience with it. (I found the performance improvement in compiling has forestalled the need to add an SSD drive. ;-) I believe that increasing the following values by 10 would benefit most FreeBSD users without disadvantage. vfs.ufs.dirhash_maxmem: 2097152 to 20971520 vfs.ufs.dirhash_reclaimage: 5 to 50 or 60 vfs.ufs.dirhash_maxmem is further autotuned based on available physical memory. See r214359 for details. [Spock Eyebrow of Thought] I'm running FreeBSD i386 9.2, that allows a max of 4 Gigs of RAM. I think the algorithm is still overly conservative for 32 bit systems, which are more likely to be using UFS. As 64 bit platforms tend to have more RAM and use ZFS, is the same tuning algorithm appropriate for both? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Suggest changing dirhash defaults for FreeBSD 9.2.
On 8/27/2013 9:40 AM, Sergey Kandaurov wrote: On 27 August 2013 16:41, Robert Burmeister wrote: I have been experimenting with dirhash settings, and have scoured the internet for other peoples' experience with it. (I found the performance improvement in compiling has forestalled the need to add an SSD drive. ;-) I believe that increasing the following values by 10 would benefit most FreeBSD users without disadvantage. vfs.ufs.dirhash_maxmem: 2097152 to 20971520 vfs.ufs.dirhash_reclaimage: 5 to 50 or 60 vfs.ufs.dirhash_maxmem is further autotuned based on available physical memory. See r214359 for details. Sorry, the documentation has not been updated since 2008. https://wiki.freebsd.org/DirhashDynamicMemory What about bumping up vfs.ufs.dirhash_reclaimage all hashes older than 5 seconds (tunable via a sysctl, vfs.ufs.dirhash_reclaimage) will always be deleted when a vm_lowmem event occurs, and if that doesn't free up at least 10% of the memory currently being used by dirhash, more hashes will be destroyed from the head of the TAILQ until we do free up at least 10% of the memory initially used. As the memory scavenger will keep nibbling until at least 10% of the cache is free, eradicating all entries older than 5 seconds for the first chop seems overly aggressive. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Suggest changing dirhash defaults for FreeBSD 9.2.
I have been experimenting with dirhash settings, and have scoured the internet for other peoples' experience with it. (I found the performance improvement in compiling has forestalled the need to add an SSD drive. ;-) I believe that increasing the following values by 10 would benefit most FreeBSD users without disadvantage. vfs.ufs.dirhash_maxmem: 2097152 to 20971520 vfs.ufs.dirhash_reclaimage: 5 to 50 or 60 FreeBSD administrators who have adjusted vfs.ufs.dirhash_maxmem for file server use have found 8 megs to be about minimum to satisfy vfs.ufs.dirhash_mem usage, while I have found compiling larger packages such as Firefox brings vfs.ufs.dirhash_mem up to about 13 megs. Setting vfs.ufs.dirhash_maxmem much larger than 20 megs results in vfs.ufs.dirhash_lowmemcount events scavenging excessive amounts of the directory cache, at 10% per event. I believe vfs.ufs.dirhash_reclaimage of about a minute is sufficient to reclaim memory without losing active directory cache, particularly when compiling; however my experience in operations leads me to believe this is also an optimal default for file servers. As the worst case scenario is that the directory cache will be over cleansed and the memory returned to the kernel, I would like to suggest that these defaults be raised by a factor of 10 for FreeBSD 9.2 or 10.0. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
