Performance Tuning
| In its default, out-of-the-box configuration, FreeBSD is optimized to work with low-end hardware and to be extremely safe and reliable. This means that under heavy demand load, the system in its default state will perform more poorly than similarly equipped Linux or Windows servers. FreeBSD isn't an inferior platform; quite the contrary. Rather, it simply needs to be tuned for high-performance operation. The other platforms to which it's compared tend to be optimized for high performance by default, to the exclusion of low-end hardware. Very few sites that run FreeBSD servers do so without tuning the system for higher performance. Performance tuning involves several different areas of the system, some of which require kernel reconfiguration (as you saw in Chapter 18). The following sections look at how to tune the kernel as well as components such as the disk. Kernel SettingsYou will need to tune your kernel to support high levels of traffic if your machine will be handling extreme loads. The GENERIC kernel is tuned for workstation or low-load server use so that its hardware requirements can be as low as possible. High demand for kernel resources can overload a system that hasn't been optimized to support it. To optimize the kernel for handling high levels of traffic, change the MAXUSERS option setting, which is set by default to 0 (which tells the kernel to auto-tune this value). Despite its name, this setting doesn't actually set a limit on the number of users who can access the system at once. Rather, it sets a figure from which other tuning values are derived; these values include the number of concurrent processes per user and the network memory buffers (or NMBCLUSTERS). The maximum number of processes each user can execute at once is derived from the following formula: (MAXUSERS * 16) + 20 If you find that you're unable to run certain programs or perform certain tasks without getting "proc table full" error messages, tune the number according to this formula. Similarly, you will want to set MAXUSERS to 128 or 256 (or higher) for extremely heavily loaded systems or servers that have to maintain large numbers of processes or NMBCLUSTERS. Tip The NMBCLUSTERS setting, derived from the formula (MAXUSERS * 16) + 512, controls the number of available "mbufs," which you can view with netstat m. Watch to see whether the mbufs are being used up. If they are, and raising MAXUSERS doesn't help, you can tune NMBCLUSTERS independently from its derivation from MAXUSERS. Set it in the kernel to 32768 or 65536 (or higher) for heavily loaded systems. Alternatively, you can set it as a runtime kernel variable without rebuilding the kernel. Add the line kern.ipc.nmbclusters="65536" to /boot/loader.conf to set it at boot time. Soft Updates and Asynchronous WritesOne of the features that allows FreeBSD to operate so safely on low-load systems is synchronous writes, meaning that the system has to wait while any write operations of filesystem metadata take place. This delay minimizes the potential harm to the filesystem due to a crash or power failure. This safeguard also makes the system run noticeably slower than comparable platforms, however, and it introduces artificial performance ceilings. You can remove these performance limitations if you so desire. "Journaling Filesystems and Soft Updates" in Chapter 12, "The FreeBSD Filesystem," discusses Soft Updates. This is a technique by which disk write operations can be done in a software-controlled, orderly manner that speeds up disk input/output (I/O) and ensures that the filesystem remains safe should the system crash. It also allows disks to be "preened" in a non-intrusive background process while the system is running (instead of as part of fsck), allowing you to boot the system quickly even if the system was not shut down cleanly. The Soft Updates mechanism is built into the GENERIC kernel and is available for use at any time. It's the default scheme for newly created filesystems in modern versions of FreeBSD. The Sysinstall utility integrates the ability to toggle Soft Updates on and off per filesystem, in the Disk Label Editor (as covered in Chapter 20). Another, more flexible, way to enable Soft Updates on a filesystem where it is not already running is to use the tunefs utility. FreeBSD uses this support program for the Fast Filesystem (FFS) natively. Run the tunefs program in single-user mode, in order for its changes to take effect, because filesystems on which it operates (such as /usr and /var) cannot be mounted at the time you run it. Because tunefs is in /sbin, it is available in single-user mode without any additional filesystems needing to be mounted. Reboot the system into single-user mode (enter boot s at the loader prompt). At the shell prompt, enter the following commands: # tunefs -n enable / # tunefs -n enable /usr # tunefs -n enable /var # tunefs -n enable /tmp Repeat the command for any other regular filesystems on your disk. Note that you might have to substitute /sbin/tunefs for tunefs in these command lines. If Soft Updates isn't an option, an alternative way to get around the problem of synchronous writes is to force the filesystems to be mounted asynchronously, or in such a way that write operations do not hold up system functions. This option gives you the advantage of greatly enhanced speed, but it lacks the safety of synchronous writes. If the system should suddenly shut down while a write operation is pending, the filesystem could be damaged or even rendered irreparable. To assume the inherent risk and mount a filesystem asynchronously, use the async option in the appropriate mount command or in /etc/fstab. A manual asynchronous mount would look like this: # mount o async /usr /dev/ad0s1fTo do asynchronous mounts automatically, add the async option to the fourth column in /etc/fstab: /dev/ad0s1f /usr ufs rw,async 2 2Disk Geometry ConcernsIf you're really interested in optimizing your system's disk access performance, you can squeeze some extra horsepower from FreeBSD by arranging your partitions according to their physical placement on the disk. Because data can be transferred more quickly from the edge of a spinning disk than from the center, you can gain some speed benefits by placing your more active filesystems toward the edge. The order in which you specify partitions in the partition table (in the Disklabel Editor in Sysinstall) matters. The first entry in the table begins at the edge of the disk, and subsequent entries are placed further and further inward (the opposite of how data is arranged on a CD, which, incidentally, spins at different rates according to where the read head isconstant linear velocity, or CLV, as opposed to a hard disk's constant angular velocity, or CAV). The root and swap partitions are accessed the most, so place them as far outward as possible. Smaller filesystems also work better toward the edge than toward the center. With this in mind, the best layout is usually to start with a fairly small root partition, followed by a swap partition about twice the size of your physical RAM. Following this are your /var, /usr, and /home partitions, which generally tend to increase in size respectively. Tip In UNIX, the algorithms that control virtual memory are optimized to work best when the swap partition is about twice the size of your onboard memory. For instance, if you have 512MB of RAM, use a 1GB swap partition. A smaller swap volume can result in speed penalties as virtual memory paging operations start to overlap each other. A Few sysctl Tune-UpsThe sysctl program controls numerous kernel state variables, such as the kern.ipc.nmbclusters variable you saw earlier. The defaults for these variables are such that a low-end system can operate smoothly and safely, but not with great top-end performance. You can tune a number of these to higher-performance values by adding them to /etc/sysctl.conf, which is evaluated by init at boot time, during the ordered execution of all the scripts in /etc/rc.d. Edit the /etc/sysctl.conf file and add any or all of the variables listed in Table 21.3, according to your needs.
Before you reboot with the new /etc/sysctl.conf, you can use sysctl to view the default value of those of these variables which are already set in the base system (some of them are not): # sysctl net.local.stream.sendspace net.local.stream.sendspace: 8192You can then manually set any value with the w flag: # sysctl w net.local.stream.sendspace=65536 net.local.stream.sendspace: 8192 -> 65536Similarly, you may want to set two or three variables in /boot/loader.conf, which is read by the kernel even earlier than init reads /etc/sysctl.conf. If you need your kernel tuning variables to be set as early in the boot process as possible, put them into /boot/loader.conf instead of /etc/sysctl.conf. Helpful Manual PagesA wealth of information is available in the man tuning page. This document is an essay describing some of the ideas we've covered here, such as disk geometry issues and how to optimize a filesystem according to the read and write demand on it. It also covers each of the previously discussed kernel tuning variables and how exactly each one affects the system. Similarly, read man tunefs for a fuller discussion of how the tunefs command can be used to take advantage not only of Soft Updates but also of many other performance enhancements that are a part of FFS. Finally, man sysctl offers a good description of the kernel state variable mechanism and how to use it to its full potential by tweaking the system's variables during runtime. |
