| Both sides previous revision Previous revision Next revision | Previous revision |
| systemtuning [2013/03/08 02:01] – it seems the original version of this comment was correct EitanAdler | systemtuning [2020/10/31 01:58] (current) – Remove hyperlink from 2 unreachable links. SashaVigole |
|---|
| * The vfs.hirunningspace sysctl determines how much outstanding write I/O may be queued to disk controllers system-wide at any given time. It is used by the UFS file system. The default is self-tuned and usually sufficient but on machines with advanced controllers and lots of disks this may be tuned up to match what the controllers buffer. Configuring this setting to match tagged queuing capabilities of controllers or drives with average IO size used in production works best (for example: 16 %%MiB%% will use 128 tags with IO requests of 128 %%KiB%%). Note that setting too high a value (exceeding the buffer cache's write threshold) can lead to extremely bad clustering performance. Do not set this value arbitrarily high! Higher write queueing values may also add latency to reads occurring at the same time. | * The vfs.hirunningspace sysctl determines how much outstanding write I/O may be queued to disk controllers system-wide at any given time. It is used by the UFS file system. The default is self-tuned and usually sufficient but on machines with advanced controllers and lots of disks this may be tuned up to match what the controllers buffer. Configuring this setting to match tagged queuing capabilities of controllers or drives with average IO size used in production works best (for example: 16 %%MiB%% will use 128 tags with IO requests of 128 %%KiB%%). Note that setting too high a value (exceeding the buffer cache's write threshold) can lead to extremely bad clustering performance. Do not set this value arbitrarily high! Higher write queueing values may also add latency to reads occurring at the same time. |
| |
| * The vfs.read_max sysctl governs VFS read-ahead and is expressed as the number of blocks to pre-read if the heuristics algorithm decides that the reads are issued sequentially. It is used by the UFS, ext2fs and msdosfs file systems. With the default UFS block size of 32KiB, a setting of 64 (the default value in 9.x) will allow speculatively reading up to 2048 %%KiB%%. This setting may be increased to get around disk I/O latencies, especially where these latencies are large such as in virtual machine emulated environments. It may be tuned down in specific cases where the I/O load is such that read-ahead adversely affects performance or where system memory is really low. | * The vfs.read_max sysctl governs VFS read-ahead and is expressed as the number of blocks to pre-read if the heuristics algorithm decides that the reads are issued sequentially. It is used by the UFS, ext2fs and msdosfs file systems. With the default UFS block size of 32KiB, a setting of vfs.read_max=64 (the default value in 9.x) will allow speculatively reading up to 2048 %%KiB%%. (The formula is: block size * vfs.read_max). This setting may be increased to get around disk I/O latencies, especially where these latencies are large such as in virtual machine emulated environments. It may be tuned down in specific cases where the I/O load is such that read-ahead adversely affects performance or where system memory is really low. |
| |
| //IIRC mav@ wrote a mail as part of his MAXPHYS work where he explained that a value of 128 was a good value in his FS tests, needs to be looked up in the archives and investigated.// | //IIRC mav@ wrote a mail as part of his MAXPHYS work where he explained that a value of 128 was a good value in his FS tests, needs to be looked up in the archives and investigated.// |
| //http://kb.lsi.com/knowledgebasearticle14852.aspx lists increasing this as a recommended tuning although they use higher numbers, http://www.freebsdwiki.net/index.php/RAID,_performance_tests (found via google, last updated 2007) says "The read-ahead cache was changed from the default value of 8 to 128 for all tests performed, using sysctl -w vfs.read_max=128. Initial testing showed that dramatic performance increases occurred for all tested configurations, including baseline single-drive, with increases of vfs.read_max. The value of 128 was arrived at by continuing to double vfs.read_max until no further significant performance increase was to be seen (at vfs.read_max=256) and backing down to the last value tried." Finally, http://ivoras.sharanet.org/blog/tree/2010-11-19.ufs-read-ahead.html [[IvanVoras]] discusses tuning this here.// | //''%%http://kb.lsi.com/knowledgebasearticle14852.aspx%%'' (link is unreachable) lists increasing this as a recommended tuning although they use higher numbers, http://www.freebsdwiki.net/index.php/RAID,_performance_tests (found via google, last updated 2007) says "The read-ahead cache was changed from the default value of 8 to 128 for all tests performed, using sysctl -w vfs.read_max=128. Initial testing showed that dramatic performance increases occurred for all tested configurations, including baseline single-drive, with increases of vfs.read_max. The value of 128 was arrived at by continuing to double vfs.read_max until no further significant performance increase was to be seen (at vfs.read_max=256) and backing down to the last value tried." Finally, ''%%http://ivoras.sharanet.org/blog/tree/2010-11-19.ufs-read-ahead.html%%'' (link is unreachable) [[IvanVoras]] discusses tuning this here.// |
| |
| * The vfs.ncsizefactor sysctl defines how large VFS namecache may grow. The number of currently allocated entries in namecache is provided by debug.numcache sysctl and the condition debug.numcache < kern.maxvnodes * vfs.ncsizefactor is adhered to. | * The vfs.ncsizefactor sysctl defines how large VFS namecache may grow. The number of currently allocated entries in namecache is provided by debug.numcache sysctl and the condition debug.numcache < kern.maxvnodes * vfs.ncsizefactor is adhered to. |
| |
| /etc/rc.conf: | /etc/rc.conf: |
| | |
| | <code> |
| |
| powerd_flags="-n hadp" | powerd_flags="-n hadp" |
| performance_cpu_freq="HIGH" | performance_cpu_freq="HIGH" |
| |
| More info: http://wiki.freebsd.org/TuningPowerConsumption | </code> |
| | |
| | More info: TuningPowerConsumption |
| |
| ==== Links ==== | ==== Links ==== |