docs - update tuning(7)
authorMatthew Dillon <dillon@apollo.backplane.com>
Mon, 25 Oct 2010 01:23:45 +0000 (18:23 -0700)
committerMatthew Dillon <dillon@apollo.backplane.com>
Mon, 25 Oct 2010 01:23:45 +0000 (18:23 -0700)
* Get rid of a ton of old cruft that no longer applies and replace with
  more applicable information.

nrelease/root/etc/sysctl.conf [deleted file]
share/man/man7/tuning.7

diff --git a/nrelease/root/etc/sysctl.conf b/nrelease/root/etc/sysctl.conf
deleted file mode 100644 (file)
index 3cca237..0000000
+++ /dev/null
@@ -1,7 +0,0 @@
-# To help get kernels up and running on new installs we poll
-# all interrupt functions at a slow rate in addition to attempting
-# to route interrupts.
-#
-# This line is usually removed once you've got a working build.
-#
-kern.emergency_intr_enable=1
index c36eabc..a7dba99 100644 (file)
 .Nm tuning
 .Nd performance tuning under DragonFly
 .Sh SYSTEM SETUP - DISKLABEL, NEWFS, TUNEFS, SWAP
-When using
-.Xr disklabel 8
-or the
-.Dx
-installer
-to lay out your filesystems on a hard disk it is important to remember
-that hard drives can transfer data much more quickly from outer tracks
-than they can from inner tracks.
-To take advantage of this you should
-try to pack your smaller filesystems and swap closer to the outer tracks,
-follow with the larger filesystems, and end with the largest filesystems.
-It is also important to size system standard filesystems such that you
-will not be forced to resize them later as you scale the machine up.
-I usually create, in order, a 128M root, 1G swap, 128M
-.Pa /var ,
-128M
-.Pa /var/tmp ,
-3G
-.Pa /usr ,
-and use any remaining space for
-.Pa /home .
-.Pp
-You should typically size your swap space to approximately 2x main memory.
-If you do not have a lot of RAM, though, you will generally want a lot
-more swap.
-It is not recommended that you configure any less than
-256M of swap on a system and you should keep in mind future memory
-expansion when sizing the swap partition.
+Modern DragonFly systems typically have just three partitions on the main drive.
+In order, a UFS
+.Pa /boot ,
+.Pa swap ,
+and a HAMMER
+.Pa / .
+The installer usually creates a multitude of PFSs (pseudo filesystems) on
+the HAMMER partition for /var, /tmp, and numerous other sub-trees.
+These PFSs exist to ease the management of snapshots and backups.
+.Pp
+Generally speaking the
+.Pa /boot
+partition should be around 768MB in size.  The minimum recommended
+is around 350MB, giving you room for backup kernels and alternative
+boot schemes.
+.Pp
+In the old days we recommended that swap be sized to at least 2x main
+memory.  These days swap is often used for other activities, including
+.Xr tmpfs 5 .
+We recommend that swap be sized to the larger of 2x main memory or
+1GB if you have a fairly small disk and up to 16GB if you have a
+moderately endowed system and a large drive.
+If you are on a minimally configured machine you may, of course,
+configure far less swap or no swap at all but we recommend at least
+some swap.
 The kernel's VM paging algorithms are tuned to perform best when there is
 at least 2x swap versus main memory.
-Configuring too little swap can lead
-to inefficiencies in the VM page scanning code as well as create issues
-later on if you add more memory to your machine.
-Finally, on larger systems
-with multiple SCSI disks (or multiple IDE disks operating on different
-controllers), we strongly recommend that you configure swap on each drive
-(up to four drives).
+Configuring too little swap can lead to inefficiencies in the VM
+page scanning code as well as create issues later on if you add
+more memory to your machine.
+Swap is a good idea even if you don't think you will ever need it as it allows the
+machine to page out completely unused data from idle programs (like getty),
+maximizing the ram available for your activities.
+.Pp
+If you intend to use the
+.Xr swapcache 8
+facility with a SSD we recommend the SSD be configured with at
+least a 32G swap partition (the maximum default for i386).
+If you are on a moderately well configured 64-bit system you can
+size swap even larger.
+.Pp
+Finally, on larger systems with multiple drives, if the use
+of SSD swap is not in the cards, we recommend that you
+configure swap on each drive (up to four drives).
 The swap partitions on the drives should be approximately the same size.
 The kernel can handle arbitrary sizes but
 internal data structures scale to 4 times the largest swap partition.
@@ -60,236 +67,33 @@ little, swap space is the saving grace of
 and even if you do not normally use much swap, it can give you more time to
 recover from a runaway program before being forced to reboot.
 .Pp
-How you size your
-.Pa /var
-partition depends heavily on what you intend to use the machine for.
-This
-partition is primarily used to hold mailboxes, the print spool, and log
-files.
-Some people even make
-.Pa /var/log
-its own partition (but except for extreme cases it is not worth the waste
-of a partition ID).
-If your machine is intended to act as a mail
-or print server,
-or you are running a heavily visited web server, you should consider
-creating a much larger partition \(en perhaps a gig or more.
-It is very easy
-to underestimate log file storage requirements.
-.Pp
-Sizing
-.Pa /var/tmp
-depends on the kind of temporary file usage you think you will need.
-128M is
-the minimum we recommend.
-Also note that the
+Most
 .Dx
-installer will create a
+systems have a single HAMMER root and use PFSs to break it up into
+various administrative domains.
+All the PFSs share the same allocation layer so there is no longer a need
+to size each individual mount.
+Instead you should review the
+.Xr hammer 8
+manual page and use the 'hammer viconfig' facility to adjust snapshot
+retention and other parameters.
+By default
+HAMMER keeps 60 days worth of snapshots.
+Usually snapshots are not desired on PFSs such as
+.Pa /usr/obj
+or
 .Pa /tmp
-directory.
-Dedicating a partition for temporary file storage is important for
-two reasons: first, it reduces the possibility of filesystem corruption
-in a crash, and second it reduces the chance of a runaway process that
-fills up
-.Oo Pa /var Oc Ns Pa /tmp
-from blowing up more critical subsystems (mail,
-logging, etc).
-Filling up
-.Oo Pa /var Oc Ns Pa /tmp
-is a very common problem to have.
-.Pp
-In the old days there were differences between
-.Pa /tmp
-and
-.Pa /var/tmp ,
-but the introduction of
-.Pa /var
-(and
-.Pa /var/tmp )
-led to massive confusion
-by program writers so today programs haphazardly use one or the
-other and thus no real distinction can be made between the two.
-So it makes sense to have just one temporary directory and
-softlink to it from the other tmp directory locations.
-However you handle
-.Pa /tmp ,
-the one thing you do not want to do is leave it sitting
-on the root partition where it might cause root to fill up or possibly
-corrupt root in a crash/reboot situation.
-.Pp
-The
-.Pa /usr
-partition holds the bulk of the files required to support the system and
-a subdirectory within it called
-.Pa /usr/pkg
-holds the bulk of the files installed from the
-.Xr pkgsrc 7
-collection.
-If you do not use
-.Xr pkgsrc 7
-all that much and do not intend to keep system source
-.Pq Pa /usr/src
-on the machine, you can get away with
-a 1 gigabyte
-.Pa /usr
-partition.
-However, if you install a lot of packages
-(especially window managers and Linux-emulated binaries), we recommend
-at least a 2 gigabyte
-.Pa /usr
-and if you also intend to keep system source
-on the machine, we recommend a 3 gigabyte
-.Pa /usr .
-Do not underestimate the
-amount of space you will need in this partition, it can creep up and
-surprise you!
-.Pp
-The
+since data on these partitions cycles a lot.
+.Pp
+If a very large work area is desired it is often beneficial to
+configure it as a separate HAMMER mount.  If it is integrated into
+the root mount it should at least be its own HAMMER PFS.
+We recommend naming the large work area
+.Pa /build .
+Similarly if a machine is going to have a large number of users
+you might want to separate your
 .Pa /home
-partition is typically used to hold user-specific data.
-I usually size it to the remainder of the disk.
-.Pp
-Why partition at all?
-Why not create one big
-.Pa /
-partition and be done with it?
-Then I do not have to worry about undersizing things!
-Well, there are several reasons this is not a good idea.
-First,
-each partition has different operational characteristics and separating them
-allows the filesystem to tune itself to those characteristics.
-For example,
-the root and
-.Pa /usr
-partitions are read-mostly, with very little writing, while
-a lot of reading and writing could occur in
-.Pa /var
-and
-.Pa /var/tmp .
-By properly
-partitioning your system fragmentation introduced in the smaller more
-heavily write-loaded partitions will not bleed over into the mostly-read
-partitions.
-Additionally, keeping the write-loaded partitions closer to
-the edge of the disk (i.e. before the really big partitions instead of after
-in the partition table) will increase I/O performance in the partitions
-where you need it the most.
-Now it is true that you might also need I/O
-performance in the larger partitions, but they are so large that shifting
-them more towards the edge of the disk will not lead to a significant
-performance improvement whereas moving
-.Pa /var
-to the edge can have a huge impact.
-Finally, there are safety concerns.
-Having a small neat root partition that
-is essentially read-only gives it a greater chance of surviving a bad crash
-intact.
-.Pp
-Properly partitioning your system also allows you to tune
-.Xr newfs 8 ,
-and
-.Xr tunefs 8
-parameters.
-Tuning
-.Xr newfs 8
-requires more experience but can lead to significant improvements in
-performance.
-There are three parameters that are relatively safe to tune:
-.Em blocksize , bytes/i-node ,
-and
-.Em cylinders/group .
-.Pp
-.Dx
-performs best when using 8K or 16K filesystem block sizes.
-The default filesystem block size is 16K,
-which provides best performance for most applications,
-with the exception of those that perform random access on large files
-(such as database server software).
-Such applications tend to perform better with a smaller block size,
-although modern disk characteristics are such that the performance
-gain from using a smaller block size may not be worth consideration.
-Using a block size larger than 16K
-can cause fragmentation of the buffer cache and
-lead to lower performance.
-.Pp
-The defaults may be unsuitable
-for a filesystem that requires a very large number of i-nodes
-or is intended to hold a large number of very small files.
-Such a filesystem should be created with an 8K or 4K block size.
-This also requires you to specify a smaller
-fragment size.
-We recommend always using a fragment size that is \(18
-the block size (less testing has been done on other fragment size factors).
-The
-.Xr newfs 8
-options for this would be
-.Dq Li "newfs -f 1024 -b 8192 ..." .
-.Pp
-If a large partition is intended to be used to hold fewer, larger files, such
-as database files, you can increase the
-.Em bytes/i-node
-ratio which reduces the number of i-nodes (maximum number of files and
-directories that can be created) for that partition.
-Decreasing the number
-of i-nodes in a filesystem can greatly reduce
-.Xr fsck 8
-recovery times after a crash.
-Do not use this option
-unless you are actually storing large files on the partition, because if you
-overcompensate you can wind up with a filesystem that has lots of free
-space remaining but cannot accommodate any more files.
-Using 32768, 65536, or 262144 bytes/i-node is recommended.
-You can go higher but
-it will have only incremental effects on
-.Xr fsck 8
-recovery times.
-For example,
-.Dq Li "newfs -i 32768 ..." .
-.Pp
-.Xr tunefs 8
-may be used to further tune a filesystem.
-This command can be run in
-single-user mode without having to reformat the filesystem.
-However, this is possibly the most abused program in the system.
-Many people attempt to
-increase available filesystem space by setting the min-free percentage to 0.
-This can lead to severe filesystem fragmentation and we do not recommend
-that you do this.
-Really the only
-.Xr tunefs 8
-option worthwhile here is turning on
-.Em softupdates
-with
-.Dq Li "tunefs -n enable /filesystem" .
-(Note: in
-.Dx ,
-softupdates can be turned on using the
-.Fl U
-option to
-.Xr newfs 8 ,
-and
-.Dx
-installer will typically enable softupdates automatically for
-non-root filesystems).
-Softupdates drastically improves meta-data performance, mainly file
-creation and deletion.
-We recommend enabling softupdates on most filesystems; however, there
-are two limitations to softupdates that you should be aware of when
-determining whether to use it on a filesystem.
-First, softupdates guarantees filesystem consistency in the
-case of a crash but could very easily be several seconds (even a minute!)
-behind on pending writes to the physical disk.
-If you crash you may lose more work
-than otherwise.
-Secondly, softupdates delays the freeing of filesystem
-blocks.
-If you have a filesystem (such as the root filesystem) which is
-close to full, doing a major update of it, e.g.\&
-.Dq Li "make installworld" ,
-can run it out of space and cause the update to fail.
-For this reason, softupdates will not be enabled on the root filesystem
-during a typical install.  There is no loss of performance since the root
-filesystem is rarely written to.
+out as well.
 .Pp
 A number of run-time
 .Xr mount 8
@@ -316,23 +120,12 @@ loaded web site, or a news server with lots of readers, you might want to
 consider turning off atime updates on your larger partitions with this
 .Xr mount 8
 option.
-However, you should not gratuitously turn off atime
-updates everywhere.
+You should not gratuitously turn off atime updates everywhere.
 For example, the
 .Pa /var
 filesystem customarily
 holds mailboxes, and atime (in combination with mtime) is used to
 determine whether a mailbox has new mail.
-You might as well leave
-atime turned on for mostly read-only partitions such as
-.Pa /
-and
-.Pa /usr
-as well.
-This is especially useful for
-.Pa /
-since some system utilities
-use the atime field for reporting.
 .Sh STRIPING DISKS
 In larger systems you can stripe partitions from several drives together
 to create a much larger overall partition.
@@ -340,33 +133,44 @@ Striping can also improve
 the performance of a filesystem by splitting I/O operations across two
 or more disks.
 The
-.Xr vinum 8
+.Xr vinum 8 ,
+.Xr lvm 8 ,
 and
-.Xr ccdconfig 8
-utilities may be used to create simple striped filesystems.
+.Xr dm 8
+subsystems may be used to create simple striped filesystems.
+We have deprecated
+.Xr ccd 4 .
 Generally
 speaking, striping smaller partitions such as the root and
 .Pa /var/tmp ,
 or essentially read-only partitions such as
 .Pa /usr
 is a complete waste of time.
-You should only stripe partitions that require serious I/O performance,
-typically
-.Pa /var , /home ,
-or custom partitions used to hold databases and web pages.
-Choosing the proper stripe size is also
-important.
-Filesystems tend to store meta-data on power-of-2 boundaries
-and you usually want to reduce seeking rather than increase seeking.
-This
-means you want to use a large off-center stripe size such as 1152 sectors
-so sequential I/O does not seek both disks and so meta-data is distributed
-across both disks rather than concentrated on a single disk.
-If
-you really need to get sophisticated, we recommend using a real hardware
-RAID controller from the list of
+You should only stripe partitions that require serious I/O performance.
+We recommend that such partitions be completely separate mounts
+and not use the same storage media as your root mount.
+.Pp
+I should reiterate that last comment.  Do not stripe your boot+root.
+Just about everything in there will be cached in system memory anyway.
+Neither would I recommend RAIDing your root.
+If robustness is needed placing your boot, swap, and root on a SSD
+which has about the same MTBF as your motherboard, then RAIDing everything
+which requires significant amounts of storage, should be sufficient.
+There isn't much point making the boot/swap/root storage even more redundant
+when the motherboard itself has no redundancy.
+When a high level of total system redundancy is required you need to be
+thinking more about having multiple physical machines that back each
+other up.
+.Pp
+When striping multiple disks always partition in multiples of at
+least 8 megabytes and use at least a 128KB stripe.
+A 256KB stripe is probably even better.
+This will avoid mis-aligning HAMMER big-blocks (which are 8MB)
+or causing a single I/O cluster from crossing a stripe boundary.
 .Dx
-supported controllers.
+will issue a significant amount of read-ahead, upwards of a megabyte
+or more if it determines accesses are linear enough, which is
+sufficient to issue concurrent I/O across multiple stripes.
 .Sh SYSCTL TUNING
 .Xr sysctl 8
 variables permit system behavior to be monitored and controlled at
@@ -720,74 +524,8 @@ Removing things like
 and drivers you do not have will reduce the size of your kernel, sometimes
 by a megabyte or more, leaving more memory available for applications.
 .Pp
-.Dv SCSI_DELAY
-may be used to reduce system boot times.
-The default is fairly high and
-can be responsible for 15+ seconds of delay in the boot process.
-Reducing
-.Dv SCSI_DELAY
-to 5 seconds usually works (especially with modern drives).
-.Pp
-There are a number of
-.Dv *_CPU
-options that can be commented out.
-If you only want the kernel to run
-on a Pentium class CPU, you can easily remove
-.Dv I486_CPU ,
-but only remove
-.Dv I586_CPU
-if you are sure your CPU is being recognized as a Pentium II or better.
-Some clones may be recognized as a Pentium and not be able to boot
-without those options.
-If it works, great!
-The operating system
-will be able to better-use higher-end CPU features for MMU, task switching,
-timebase, and even device operations.
-Additionally, higher-end CPUs support
-4MB MMU pages, which the kernel uses to map the kernel itself into memory,
-increasing its efficiency under heavy syscall loads.
-.Sh IDE WRITE CACHING
-.Fx 4.3
-flirted with turning off IDE write caching.
-This reduced write bandwidth
-to IDE disks but was considered necessary due to serious data consistency
-issues introduced by hard drive vendors.
-Basically the problem is that
-IDE drives lie about when a write completes.
-With IDE write caching turned
-on, IDE hard drives will not only write data to disk out of order, they
-will sometimes delay some of the blocks indefinitely under heavy disk
-load.
-A crash or power failure can result in serious filesystem
-corruption.
-So our default was changed to be safe.
-Unfortunately, the
-result was such a huge loss in performance that we caved in and changed the
-default back to on after the release.
-You should check the default on
-your system by observing the
-.Va hw.ata.wc
-sysctl variable.
-If IDE write caching is turned off, you can turn it back
-on by setting the
-.Va hw.ata.wc
-loader tunable to 1.
-More information on tuning the ATA driver system may be found in the
-.Xr nata 4
-man page.
-.Pp
-There is a new experimental feature for IDE hard drives called
-.Va hw.ata.tags
-(you also set this in the boot loader) which allows write caching to be safely
-turned on.
-This brings SCSI tagging features to IDE drives.
-As of this
-writing only IBM DPTA and DTLA drives support the feature.
-Warning!
-These
-drives apparently have quality control problems and I do not recommend
-purchasing them at this time.
-If you need performance, go with SCSI.
+If your motherboard is AHCI-capable then we strongly recommend turning
+on AHCI mode.
 .Sh CPU, MEMORY, DISK, NETWORK
 The type of tuning you do depends heavily on where your system begins to
 bottleneck as load increases.