Table of Contents
Now that monitoring and analysis tools have been addressed, it is time to look into some actual methods. In this section, tools and methods that can affect how the system performs that are applied without recompiling the kernel are addressed, the next section examines kernel tuning by recompiling.
The sysctl utility can be used to look at and in some cases alter system parameters. There are so many parameters that can be viewed and changed they cannot all be shown here, however, for the first example here is a simple usage of sysctl to look at the system PATH environment variable:
mail% sysctl user.cs_path user.cs_path = /usr/bin:/bin:/usr/sbin:/sbin:/usr/pkg/bin:/usr/pkg/sbin:/usr/local/bin:/usr/local/sbin
Fairly simple. Now something that is actually related to performance. As an example, lets say a system with many users is having file open issues, by examining and perhaps raising the kern.maxfiles parameter the problem may be fixed, but first, a look:
mail% sysctl kern.maxfiles kern.maxfiles = 1772
Now, to change it, as root with the -w option specified:
mail# sysctl -w kern.maxfiles=1972 kern.maxfiles: 1772 -> 1972
Note, when the system is rebooted, the old value will return, there are two cures for this, first, modify that parameter in the kernel and recompile, second (and simpler) add this line to /etc/sysctl.conf:
kern.maxfiles=1972
From what I have gathered on a variety of lists, the most commonly “tweaked” part of the system via sysctl is the Unified Buffer Cache (UBC). In a really great email a developer made some excellent recommendations for tuning a system with UBC, this section will peruse that for the example.
Following along with the maxfiles example above, even though there can now be a larger amount of open files, there still may be more that can be done to make the system run faster. Since more files can be opened, it stands to reason that it would be good if the caching were optimized as well. In the case of this machine, there is a decent amount of RAM (256MB) that despite a lot of low level activity (such as editing and small compiles) is not being utilized to its full potential. This means that the buffer cache could probably be expanded, thereby making performance better since more would be in the cache versus rereading from disk. Now, a word of warning, it is of course possible to raise the size to a point where getting a cache hit is taking too long, but as has been well documented, that number seems to be fairly high. So what is the parameter? It is kern.maxvnodes and in the case of this machine, 38k was used which gave a pretty decent performance boost. In general, it has been seen that a kern.maxvnodes operates well when the size is set to between 1/6 to 1/4 of the amount of RAM (depending on what the system is being used for).
You can also improve performance by tuning vm.anonmax, which sets the amount of physical memory that can be reclaimed for anonymous application data. Simon Burge wrote a very good post to tech-kern discussing this; it is highly recommended that you read his entire e-mail before setting values for your system. For the lazy amongst us, though, sysctl -w vm.anonmax=95 seems to work well for him on his pc532 with 8MB of RAM; it might work well for your system too.
An operating system can often benefit from a few configuration changes (along the same lines, it can also be of great detriment). Two particular cases where system performance can be changed are by using memory based filesystems and/or soft updates.
When to use and not to use the memory based filesystem can be hard on large multi user systems. In some cases, however, it makes pretty good sense, for example, on a development machine used by only one developer at a time, the obj directory might be a good place, or some of the tmp directories for builds. In a case like that, it makes sense on machines that have a fair amount of RAM on them. On the other side of the coin, if a system only has 16MB of RAM and /var/tmp is memfs based, there could be severe applications issues that occur.
The GENERIC kernel has memfs enabled by default. To use it on a particular directory first determine where the swap space is that you wish to use, in the example case, a quick look in /etc/fstab indicates that /dev/wd0b is the swap partition:
mail% cat /etc/fstab /dev/wd0a / ffs rw 1 1 /dev/wd0b none swap sw 0 0 /kern /kern kernfs rw
This system is a mail server so I only want to use /tmp with memfs, also on this particular system I have linked /tmp to /var/tmp to save space (they are on the same drive). All I need to do is add the following entry:
/dev/wd0b /var/tmp mfs rw 0 0
Now, a word of warning, make sure said directories are empty and nothing is using them when you mount the memory file system! At this point I can either mount -a or reboot the system.
The Soft Updates feature is not enabled by default due to license issues, and because it is still considered to be experimental. However, many people found that it runs quite well. Softdep makes the filesystem appear to run much faster. As an example, on a large directory when rm -f is run, it might take awhile. With softdeps in use, it appears to be instant. A great deal more information about softdep capabilities can be found on the author's page. There is also a section in the NetBSD Documentation about soft updates.
In a nutshell, to get softdeps running, just change the entry in /etc/fstab for the filesystem on which it will be used, and reboot. For example, to enable Soft Updates for /usr, this file:
/dev/wd0a / ffs rw 1 1 /dev/wd0b none swap sw 0 0 /dev/wd0e /usr ffs rw 1 2 /kern /kern kernfs rw
becomes:
/dev/wd0a / ffs rw 1 1 /dev/wd0b none swap sw 0 0 /dev/wd0e /usr ffs rw,softdep 1 2 /kern /kern kernfs rw