os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add a "Configuration and Tuning" chapter to the System Administration

Browse source 
section of the Handbook.

Submitted by:	Chern Lee <chern.lee@windriver.com>
Obtained from:	Mike Smith's configuration tutorial, and
	        tuning(7) by Matt Dillon
This commit is contained in:
Murray Stokely 2001-07-10 02:33:49 +00:00
parent ec901c396a
commit 7852280b49
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=9819
5 changed files with 860 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
en_US.ISO8859-1/books/handbook/Makefile
View file

@ -1,5 +1,5 @@
#
# $FreeBSD: doc/en_US.ISO8859-1/books/handbook/Makefile,v 1.34 2001/06/23 22:46:14 murray Exp $
# $FreeBSD: doc/en_US.ISO8859-1/books/handbook/Makefile,v 1.35 2001/06/30 14:46:48 nik Exp $
#
# Build the FreeBSD Handbook.
#
@ -26,6 +26,7 @@ SRCS+= advanced-networking/chapter.sgml
SRCS+= backups/chapter.sgml
SRCS+= basics/chapter.sgml
SRCS+= bibliography/chapter.sgml
SRCS+= config/chapter.sgml
SRCS+= boot/chapter.sgml
SRCS+= contrib/chapter.sgml
SRCS+= cutting-edge/chapter.sgml

4
en_US.ISO8859-1/books/handbook/book.sgml
View file

@ -1,7 +1,7 @@
<!--
The FreeBSD Documentation Project
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/book.sgml,v 1.101 2001/06/21 03:38:14 chris Exp $
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/book.sgml,v 1.102 2001/06/30 14:46:48 nik Exp $
-->
<!DOCTYPE BOOK PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
@ -30,6 +30,7 @@
<!ENTITY % chap.install "IGNORE">
<!ENTITY % chap.basics "IGNORE">
<!ENTITY % chap.ports "IGNORE">
<!ENTITY % chap.config "IGNORE">
<!ENTITY % chap.boot "IGNORE">
<!ENTITY % chap.users "IGNORE">
<!ENTITY % chap.kernelconfig "IGNORE">
@ -114,6 +115,7 @@
<part>
<title>System Administration</title>
<![ %chap.config; [ &chap.config; ]]>
<![ %chap.boot; [ &chap.boot; ]]>
<![ %chap.users; [ &chap.users; ]]>
<![ %chap.kernelconfig; [ &chap.kernelconfig; ]]>

3
en_US.ISO8859-1/books/handbook/chapters.ent
View file

@ -6,7 +6,7 @@
Chapters should be listed in the order in which they are referenced.
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/chapters.ent,v 1.11 2001/05/15 03:42:58 murray Exp $
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/chapters.ent,v 1.12 2001/06/29 18:25:58 murray Exp $
-->
<!-- Part one -->
@ -16,6 +16,7 @@
<!ENTITY chap.ports SYSTEM "ports/chapter.sgml">
<!-- Part two -->
<!ENTITY chap.config SYSTEM "config/chapter.sgml">
<!ENTITY chap.boot SYSTEM "boot/chapter.sgml">
<!ENTITY chap.users SYSTEM "users/chapter.sgml">
<!ENTITY chap.kernelconfig SYSTEM "kernelconfig/chapter.sgml">

15
en_US.ISO8859-1/books/handbook/config/Makefile Normal file
View file

@ -0,0 +1,15 @@
#
# Build the Handbook with just the content from this chapter.
#
# $FreeBSD$
#
CHAPTERS= config/chapter.sgml
VPATH= ..
MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX}
DOC_PREFIX?= ${.CURDIR}/../../../..
.include "../Makefile"

838
en_US.ISO8859-1/books/handbook/config/chapter.sgml Normal file
View file

@ -0,0 +1,838 @@
<!--
The FreeBSD Documentation Project
$FreeBSD$
-->
<chapter id="config-tuning">
<title>Configuration and Tuning</title>
<para>This chapter was written by &a.chern; and &a.murray using
information originally written by &a.msmith; and &a.dillon;</para>
<sect1>
<title>Synopsis</title>
<indexterm><primary>System configuration</primary></indexterm>
<indexterm><primary>System optimization</primary></indexterm>
<para>Configuring a system correctly can substantially reduce the
amount of work and hassle involved in maintaining and upgrading it
in the future. This chapter describes some of the aspects of
administrative configuration of FreeBSD systems.</para>
<para>This chapter will also describe some of the parameters that
can be set to tune a FreeBSD system for optimum
performance.</para>
</sect1>
<sect1 id="configtuning-initial">
<title>Initial Configuration</title>
<sect2>
<title>Partition layout</title>
<indexterm><primary>Partition layout</primary></indexterm>
<indexterm><primary>/etc</primary></indexterm>
<indexterm><primary>/var</primary></indexterm>
<indexterm><primary>/usr</primary></indexterm>
<sect3>
<title>Base Partitions</title>
<para>When laying out your filesystem with &man.disklabel.8;
or &man.sysinstall.8;, it is important to remember that hard
drives can transfer data at a faster rate from the outer
tracks than the inner. Knowing this, you should place your
smaller, heavily-accessed filesystems, such as root and swap,
closer to the outside of the drive, while placing larger
partitions, such as /usr, towards the inner. To do so, it is
a good idea to create partitions in a similar order: root,
swap, <filename>/var</filename>,
<filename>/usr</filename>.</para>
<para>The size of your <filename>/var</filename> partition
reflects the intended use of your machine.
<filename>/var</filename> is primarily used to hold:
mailboxes, print spool and log files. Mail boxes and log
files, in particular, can grow to unexpected sizes based upon
how many users are on your system and how long your log files
are kept. If you intend to run a mailserver, a
<filename>/var</filename> partition of over a gig can be
suitable. Additionally, <filename>/var/tmp</filename> must be
large enough to contain any packages you may wish to
add.</para>
<para>The <filename>/usr</filename> partition holds the bulk
of the files required to support the system and a subdirectory
within it called <filename>/usr/local</filename> holds the
bulk of the files installed from the &man.ports.7; hierarchy.
If you do not use ports all that much and do not intend to
keep system source (/usr/src) on the machine, you can get away
with a 1 gigabyte /usr partition. However, if you install a
lot of ports (especially window managers and Linux-emulated
binaries), we recommend at least a two gigabyte /usr and if
you also intend to keep system source on the machine, we
recommend a three gigabyte <filename>/usr</filename>. Do not
underestimate the amount of space you will need in this
partition, it can creep up and surprise you!</para>
<para>When sizing your partitions, keep in mind the space
requirements for your system to grow. Running out of space in
one partition while having plenty in another can lead to much
frustration.</para>
<note><para>Some users who have used &man.sysinstall.8;'s
<literal>Auto-defaults</literal> partition sizer have found
either their root or <filename>/var</filename> partitions too
small later on. Partition wisely and
generously.</para></note>
</sect3>
<sect3>
<title>Swap Partition</title>
<indexterm><primary>swap sizing</primary></indexterm>
<indexterm><primary>swap partition</primary></indexterm>
<para>As a rule of thumb, your swap space should typically be
double the amount of main memory. For example, if the machine
has 128 megabytes of memory, the swap file should be 256
megabytes. Systems with lesser memory may perform better with
a lot more swap. It is not recommended that you configure any
less than 256 megabytes of swap on a system and you should
keep in mind future memory expansion when sizing the swap
partition. The kernel's VM paging algorithms are tuned to
perform best when the swap partition is at least two times the
size of 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.</para>
<para>Finally, on larger systems with multiple SCSI disks (or
multiple IDE disks operating on different controllers), it is
strongly 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. Keeping the swap partitions near the
same size will allow the kernel to optimally stripe swap space
across the disks. Do not worry about overdoing it a little,
swap space is the saving grace of UNIX. Even if you don't
normally use much swap, it can give you more time to recover
from a runaway program before being forced to reboot.</para>
</sect3>
<sect3>
<title>Why Partition?</title>
<para> Why partition at all? Why not create one big root
partition and be done with it? Then I don't have to worry
about undersizing things!</para>
<para>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 <filename>/usr</filename> partitions are read-mostly, with
very little writing, while a lot of reading and writing could
occur in <filename>/var</filename> and
<filename>/var/tmp</filename>.</para>
<para>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, for example before the really big
partition 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
<filename>/var</filename> 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.</para>
</sect3>
</sect2>
</sect1>
<sect1 id="configtuning-core-configuration">
<title>Core Configuration</title>
<indexterm><primary>rc.conf</primary></indexterm>
<para>The principal location for system configuration information
is within <filename>/etc/rc.conf</filename>. This file
contains a wide range of configuration information, principally
used at system startup to configure the system. Its name
directly implies this; it is configuration information for the
<filename>rc*</filename> files.</para>
<para>An administrator should make entries in the rc.conf file to
override the default settings from
<filename>/etc/defaults/rc.conf</filename>. The defaults file
should not be copied verbatim to <filename>/etc</filename> - it
contains default values, not examples. All system-specific
changes should be made in the rc.conf file itself.</para>
<para>A number of strategies may be applied in clustered
applications to separate site-wide configuration from
system-specific configuration in order to keep administration
overheads down. The recommended approach is to place site-wide
configuration into another file,
eg. <filename>/etc/rc.conf.site</filename>, and then include
this file into <filename>/etc/rc.conf</filename>, which will
contain only system-specific information.</para>
<para>As <filename>rc.conf</filename> is read by &man.sh.1; it is
trivial to achieve this. For example:</para>
<itemizedlist>
<listitem><para>rc.conf:</para>
<programlisting> . rc.conf.site
hostname="node15.webcompany.com"
network_interfaces="fxp0 lo0"
ifconfig_fxp0="inet 10.1.1.1"</programlisting></listitem>
<listitem><para>rc.conf.site:</para>
<programlisting> defaultrouter="10.1.1.254"
saver="daemon"
blanktime="100"</programlisting></listitem>
</itemizedlist>
<para>The <filename>rc.conf.site</filename> file can then be
distributed to every system using eg. <command>rsync</command>,
whilst the <filename>rc.conf</filename> file remains unique.</para>
<para>Upgrading the system eg. via &man.sysinstall.8;
or 'make world' will not overwrite the rc.conf file, so system
configuration information will not be lost.</para>
</sect1>
<sect1 id="configtuning-appconfig">
<title>Application Configuration</title>
<para>Typically, installed applications have their own
configuration files, with their own syntax, etc. It is
important that these files be kept separate from the base
system, so that they may be easily located and managed by the
package management tools.</para>
<indexterm><primary>/usr/local/etc</primary></indexterm>
<para>Typically, these files are installed in
<filename>/usr/local/etc</filename>. In the case where an
application has a large number of configuration files, a
subdirectory will be created to hold them.</para>
<para>Normally, when a port or package is installed, sample
configuration files are also installed. These are usually
identified with a ".default" suffix. If there are no existing
configuration files for the application, they will be created by
copying the .default files.</para>
<para>For example, here is
<filename>/usr/local/etc/apache</filename>:</para>
<literallayout>-rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf
-rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf.default
-rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf
-rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf.default
-rw-r--r-- 1 root wheel 12205 May 20 1998 magic
-rw-r--r-- 1 root wheel 12205 May 20 1998 magic.default
-rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types
-rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types.default
-rw-r--r-- 1 root wheel 7980 May 20 1998 srm.conf
-rw-r--r-- 1 root wheel 7933 May 20 1998 srm.conf.default</literallayout>
<para>It can be quickly seen that only the srm.conf file has been
changed. A later update of the apache port would not overwrite
this changed file.</para>
</sect1>
<sect1 id="configtuning-starting-services">
<title>Starting Services</title>
<indexterm><primary>services</primary></indexterm>
<para>It is common for a system to host a number of services.
These may be started in several different fashions, each having
different advantages.</para>
<indexterm><primary>/usr/local/etc/rc.d</primary></indexterm>
<para>Software installed from a port or the packages collection
will often place a script in
<filename>/usr/local/etc/rc.d</filename> which is invoked at
system startup with a 'start' argument, and at system shutdown
with a 'stop' argument. This is the recommended way for
starting systemwide services that are to be run as root, or that
expect to be started as root. These scripts are registered as
part of the installation of the package, and will be removed
when the package is removed.</para>
<para>A generic startup script in
<filename>/usr/local/etc/rc.d</filename> looks like:</para>
<programlisting>#!/bin/sh
echo -n ' FooBar'
case "$1" in
start)
/usr/local/bin/foobar
;;
stop)
kill -9 `cat /var/run/foobar.pid`
;;
*)
echo "Usage: `basename $0` {start|stop}" >&2
exit 64
;;
esac
exit 0
</programlisting>
<para>This script is called with <option>start</option>
at startup, and the <option>stop</option> at shutdown to allow
it to carry out its purpose.</para>
<para>Some services expect to be invoked by &man.inetd.8; when a
connection is received on a suitable port. This is common for
mail reader servers (POP and IMAP, etc.). These services are
enabled by editing the file <filename>/etc/inetd.conf</filename>.
See &man.inetd.8; for details on editing this file.</para>
<para>Some additional system services may not be covered by the
toggles in <filename>/etc/rc.conf</filename>. These are
traditionally enabled by placing the command(s) to invoke them
in <filename>/etc/rc.local</filename>. As of FreeBSD 3.1 there
is no default <filename>/etc/rc.local</filename>; if it is
created by the administrator it will however be honored in the
normal fashion. Note that <filename>rc.local</filename> is
generally regarded as the location of last resort; if there is a
better place to start a service, do it there.</para>
<note><para>Do <emphasis>not</emphasis> place any commands in
<filename>/etc/rc.conf</filename>. To start daemons, or
run any commands at boot time, place a script in
<filename>/usr/local/etc/rc.d</filename> instead.</para>
</note>
<para>It is also possible to use the &man.cron.8; daemon to start
system services. This approach has a number of advantages, not
least being that because cron runs these processes as the owner
of the crontab, services may be started and maintained by
non-root users.</para>
<para>This takes advantage of an undocumented feature of cron; the
time specification may be replaced by '@reboot', which will
cause the job to be run when cron is started shortly after
system boot.</para>
</sect1>
<sect1 id="configtuning-virtual-hosts">
<title>Virtual Hosts</title>
<indexterm><primary>virtual hosts</primary></indexterm>
<indexterm><primary>ip aliases</primary></indexterm>
<para>A very common use of FreeBSD is virtual site hosting, where
one server appears to the network as many servers. This is
achieved by assigning multiple network addresses to a single
interface.</para>
<para>A given network interface has one "real" address, and may
have any number of "alias" addresses. These aliases are
normally added by placing alias entries in
<filename>/etc/rc.conf</filename>.</para>
<para>An alias entry for the interface 'fxp0' looks like:</para>
<programlisting>ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx"</programlisting>
<para>Note that alias entries must start with alias0 and proceed
upwards in order, eg. _alias1, _alias2, etc. The configuration
process will stop at the first missing number.</para>
<para>The calculation of alias netmasks is important, but
fortunately quite simple. For a given interface, there must be
one address which correctly represents the network's netmask.
Any other addresses which fall within this network must have a
netmask of all 1's.</para>
<para>For example, consider the case where the fxp0 interface is
connected to two networks, the 10.1.1.0 network with a netmask
of 255.255.255.0 and the 202.0.75.16 network with a netmask of
255.255.255.240. We want the system to appear at 10.1.1.1
through 10.1.1.5 and at 202.0.75.17 through 202.0.75.20.</para>
<para>The following entries configure the adapter correctly for
this arrangement:</para>
<programlisting> ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0"
ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255"
ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255"
ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255"
ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255"
ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240"
ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255"
ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255"
ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255"</programlisting>
</sect1>
<sect1 id="configtuning-configfiles">
<title>Configuration Files</title>
<sect2>
<title>/etc Layout</title>
<para>There are a number of directories in which configuration
information is kept. These include:</para>
<informaltable frame="none">
<tgroup cols="2">
<tbody>
<row>
<entry>/etc</entry>
<entry>Generic system configuration information; data here is
system-specific.</entry>
</row>
<row>
<entry>/etc/defaults</entry>
<entry>Default versions of system configuration files.</entry>
</row>
<row>
<entry>/etc/mail</entry>
<entry>Extra sendmail configuration, other MTA configuration
files.
</entry>
</row>
<row>
<entry>/etc/ppp</entry>
<entry>Configuration for both user- and kernel-ppp programs.
</entry>
</row>
<row>
<entry>/etc/namedb</entry>
<entry>Default location for bind(8) data. Normally the
boot file is located here, and contains a directive to
refer to other data in /var/db.</entry>
</row>
<row>
<entry>/usr/local/etc</entry>
<entry>Configuration files for installed applications.
May contain per-application subdirectories.</entry>
</row>
<row>
<entry>/usr/local/etc/rc.d</entry>
<entry>Start/stop scripts for installed applications.</entry>
</row>
<row>
<entry>/var/db</entry>
<entry>Persistent system-specific data files, eg. bind(8) zone
files, database files, and so on.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</sect2>
<sect2>
<title>Hostnames</title>
<indexterm><primary>hostnames</primary></indexterm>
<indexterm><primary>DNS</primary></indexterm>
<sect3>
<title>/etc/resolv.conf</title>
<indexterm><primary>resolv.conf</primary></indexterm>
<para><filename>/etc/resolv.conf</filename> dictates how FreeBSD's
resolver accesses the Internet Domain Name System (DNS).</para>
<para>The most common entries to <filename>resolv.conf</filename> are:
</para>
<informaltable frame="none">
<tgroup cols="2">
<tbody>
<row>
<entry>nameserver</entry>
<entry>The IP address of a nameserver the resolver
should query. The servers are queried in the order
listed with a maximum of three.</entry>
</row>
<row>
<entry>search</entry>
<entry>Search list hostname lookup. This is normally
determined by the domain of the local hostname.</entry>
</row>
<row>
<entry>domain</entry>
<entry>The local domain name.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>A typical <filename>resolv.conf</filename>:</para>
<programlisting>search foobar.com
nameserver 147.11.1.11
nameserver 147.11.100.30
</programlisting>
<para>&man.dhclient.8; usually rewrites
<filename>resolv.conf</filename> with information received from the
DHCP server.</para>
</sect3>
<sect3>
<title>/etc/hosts</title>
<indexterm><primary>hosts</primary></indexterm>
<para><filename>/etc/hosts</filename> is a simple text database
reminescent of the old Internet. It works in conjunction with DNS
and NIS providing name to IP address mappings. Local computers
connected via a LAN can be placed in here for simplistic naming
purposes instead of setting up a &man.named.8; server.
Additionally, <filename>/etc/hosts</filename> can be used to provide
a local record of Internet names, reducing the need to query
externally for commonly accessed names.</para>
<programlisting># $FreeBSD: src/etc/hosts,v 1.13 2000/09/06 18:16:32 nectar Exp $
#
# Host Database
# This file should contain the addresses and aliases
# for local hosts that share this file.
# In the presence of the domain name service or NIS, this file may
# not be consulted at all; see /etc/nsswitch.conf for the resolution order.
#
#
::1 localhost localhost.my.domain myname.my.domain
127.0.0.1 localhost localhost.my.domain myname.my.domain
#
# Imaginary network.
#10.0.0.2 myname.my.domain myname
#10.0.0.3 myfriend.my.domain myfriend
#
# According to RFC 1918, you can use the following IP networks for
# private nets which will never be connected to the Internet:
#
# 10.0.0.0 - 10.255.255.255
# 172.16.0.0 - 172.31.255.255
# 192.168.0.0 - 192.168.255.255
#
# In case you want to be able to connect to the Internet, you need
# real official assigned numbers. PLEASE PLEASE PLEASE do not try
# to invent your own network numbers but instead get one from your
# network provider (if any) or from the Internet Registry (ftp to
# rs.internic.net, directory `/templates').
#
</programlisting>
<para><filename>/etc/hosts</filename> takes on the simple format of:</para>
<programlisting>[Internet address] [offical hostname] [alias1] [alias2] ...
</programlisting>
<para>For example:</para>
<programlisting>10.0.0.1 myRealHostname.foobar.com myRealHostname foobar1 foobar2
</programlisting>
<para>Consult &man.hosts.5; for more information.</para>
</sect3>
</sect2>
<sect2>
<title>Log File Configuration</title>
<indexterm><primary>log files</primary></indexterm>
<sect3>
<title>syslog.conf</title>
<indexterm><primary>syslog.conf</primary></indexterm>
<para><filename>syslog.conf</filename> is the configuration file
for the &man.syslogd.8; program. It indicates which types
of syslog messages are logged to particular log files.</para>
<programlisting># $FreeBSD: src/etc/syslog.conf,v 1.16 2001/03/31 04:41:24 murray Exp $
#
# Spaces ARE valid field separators in this file. However,
# other *nix-like systems still insist on using tabs as field
# separators. If you are sharing this file between systems, you
# may want to use only tabs as field separators here.
# Consult the syslog.conf(5) manpage.
*.err;kern.debug;auth.notice;mail.crit /dev/console
*.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages
security.* /var/log/security
mail.info /var/log/maillog
lpr.info /var/log/lpd-errs
cron.* /var/log/cron
*.err root
*.notice;news.err root
*.alert root
*.emerg *
# uncomment this to log all writes to /dev/console to /var/log/console.log
#console.info /var/log/console.log
# uncomment this to enable logging of all log messages to /var/log/all.log
#*.* /var/log/all.log
# uncomment this to enable logging to a remote loghost named loghost
#*.* @loghost
# uncomment these if you're running inn
# news.crit /var/log/news/news.crit
# news.err /var/log/news/news.err
# news.notice /var/log/news/news.notice
!startslip
*.* /var/log/slip.log
!ppp
*.* /var/log/ppp.log
</programlisting>
<para>Consult the &man.syslog.conf.5; manpage for more
information.</para>
</sect3>
<sect3>
<title>newsyslog.conf</title>
<indexterm><primary>newsyslog.conf</primary></indexterm>
<para><filename>newsyslog.conf</filename> is the configuration
file for &man.newsyslog.8;, a program that is scheduled to run
normally by &man.cron.8; &man.newsyslog.8; determines when log
files require archiving or rearranging.
<filename>logfile</filename> is moved to
<filename>logfile.1</filename>, <filename>logfile.1</filename>
is moved to <filename>logfile.2</filename>, and so on.
Additionally, the log files may be archived in gzip format
causing them to be named: logfile.0.gz, logfile.1.gz, and so
on.</para>
<para><filename>newsyslog.conf</filename> indicates which log
files are to be managed, how many are to be kept, and when
they are to be touched. Log files can be rearranged and/or
archived when they have either reached a certain size, or at a
certain periodic time/date.</para>
<programlisting># configuration file for newsyslog
# $FreeBSD: src/etc/newsyslog.conf,v 1.29 2001/02/17 20:27:58 phk Exp $
#
# logfilename [owner:group] mode count size when [ZB] [/pid_file] [sig_num]
/var/log/cron 600 3 100 * Z
/var/log/amd.log 644 7 100 * Z
/var/log/kerberos.log 644 7 100 * Z
/var/log/lpd-errs 644 7 100 * Z
/var/log/maillog 644 7 * @T00 Z
/var/log/sendmail.st 644 10 * 168 B
/var/log/messages 644 5 100 * Z
/var/log/all.log 600 7 * @T00 Z
/var/log/slip.log 600 3 100 * Z
/var/log/ppp.log 600 3 100 * Z
/var/log/security 600 10 100 * Z
/var/log/wtmp 644 3 * @01T05 B
/var/log/daily.log 640 7 * @T00 Z
/var/log/weekly.log 640 5 1 $W6D0 Z
/var/log/monthly.log 640 12 * $M1D0 Z
/var/log/console.log 640 5 100 * Z
</programlisting>
<para>Consult the &man.newsyslog.8; manpage for more
information.</para>
</sect3>
</sect2>
<sect2>
<title>sysctl.conf</title>
<indexterm><primary>sysctl.conf</primary></indexterm>
<indexterm><primary>sysctl</primary></indexterm>
<para><filename>sysctl.conf</filename> looks much like
<filename>rc.conf</filename>. Values are set in a variable=value
form. The specified values are set after the system goes into
multi-user mode. Not all variables are settable in this mode.</para>
<para>A sample <filename>sysctl.conf</filename> turning off logging
of fatal signal exits and letting Linux programs know they are really
running under FreeBSD.</para>
<programlisting>kern.logsigexit=0 # Do not log fatal signal exits (e.g. sig 11)
compat.linux.osname=FreeBSD
compat.linux.osrelease=4.3-STABLE
</programlisting>
</sect2>
</sect1>
<sect1 id="configtuning-sysctl">
<title>Tuning with sysctl</title>
<indexterm><primary>sysctl</primary></indexterm>
<indexterm><primary>Tuning with sysctl</primary></indexterm>
<para>&man.sysctl.8; is an interface that allows you to make changes
to a running FreeBSD system. This includes many advanced
options of the TCP/IP stack and virtual memory system that can
dramatically improve performance for an experienced system
administrator. Over five hundred system variables can be read
and set using &man.sysctl.8;</para>
<para>At its core, &man.sysctl.8; serves to do two functions: read and
modify system settings.</para>
<para>To view all readable variables:</para>
<programlisting>&prompt.user; <userinput>sysctl -a</userinput>
</programlisting>
<para>To read a particular variable, for example,
<literal>kern.maxproc</literal>:</para>
<programlisting>&prompt.user; <userinput>sysctl kern.maxproc</userinput>
kern.maxproc: 1044</programlisting>
<para>To set a particular variable, use the <literal>=</literal>
option:</para>
<programlisting>&prompt.root; <userinput>sysctl kern.maxfiles=5000</userinput>
kern.maxfiles: 2088 -> 5000</programlisting>
<para>Settings of sysctl variables are usually either strings, numbers,
or booleans. A boolean being 1 for yes or a 0 for no.</para>
</sect1>
<sect1 id="configtuning-disk">
<title>Tuning disks</title>
<sect2>
<title>Sysctl Variables</title>
<sect3>
<title>vfs.vmiodirenable</title>
<indexterm><primary>vfs.vmiodirenable</primary></indexterm>
<para>The <varname>vfs.vmiodirenable</varname> sysctl variable
defaults to 0 (off) (though soon it will default to 1) and may
be set to 0 (off) or 1 (on). This parameter controls how
directories are cached by the system. Most directories are
small and use but a single fragment (typically 1K) in the
filesystem and even less (typically 512 bytes) in the buffer
cache. However, when operating in the default mode the buffer
cache will only cache a fixed number of directories even if
you have a huge amount of memory. Turning on this sysctl
allows the buffer cache to use the VM Page Cache to cache the
directories. The advantage is that all of memory is now
available for caching directories. The disadvantage is that
the minimum in-core memory used to cache a directory is the
physical page size (typically 4K) rather than 512 bytes. We
recommend turning this option on if you are running any
services which manipulate large numbers of files. Such
services can include web caches, large mail systems, and news
systems. Turning on this option will generally not reduce
performance even with the wasted memory but you should
experiment to find out.</para>
</sect3>
<sect3>
<title>hw.ata.wc</title>
<indexterm><primary>hw.ata.wc</primary></indexterm>
<para>FreeBSD 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 when under heavy disk loads. 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 hw.ata.wc sysctl
variable. If IDE write caching is turned off, you can turn it
back on by setting the kernel variable back to 1. This must
be done from the boot loader at boot time. Attempting to do
it after the kernel boots will have no effect.</para>
<para>Please see &man.ata.4;.</para>
</sect3>
</sect2>
<sect2>
<title>SoftUpdates</title>
<indexterm><primary>SoftUpdates</primary></indexterm>
<indexterm><primary>tunefs</primary></indexterm>
<para>The &man.tunefs.8; can be used to fine-tune a filesystem. In this
situation, we are only concerned with its ability to toggle softupdates
on and off, which is done so by:</para>
<screen>&prompt.root; tunefs -n enable /filesystem
&prompt.root; tunefs -n disable /filesystem</screen>
<para>A filesystem cannot be modified with &man.tunefs.8; while
it is mounted. A good time to enable SoftUpdates is before any
partitions have been mounted, in single-user mode.</para>
<para>SoftUpdates drastically improves meta-data performance, mainly
file creation and deletion, through the use of a memory cache. We
recommend turning SoftUpdates on on all of your filesystems. There
are two downsides to SoftUpdates that you should be aware of: First,
softupdates guarantees filesystem consistency in the case of a crash
but could very easily be several
seconds (even a minute!) behind updating 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. make installworld, can run it out of space and
cause the update to fail.</para>
</sect2>
</sect1>
<sect1 id="configtuning-kernel-limits">
<title>Tuning kernel limits</title>
<indexterm><primary>Tuning kernel limits</primary></indexterm>
<sect2>
<title>File/process limits</title>
<sect3>
<title>kern.maxfiles</title>
<indexterm><primary>kern.maxfiles</primary></indexterm>
<para><varname>kern.maxfiles</varname> can be raised or
lowered based upon your system requirements. This variable
indicates the maximum number of file descriptors on your
system. When the file descriptor table is full,
<literal>file: table is full</literal> will show up repeatedly
in dmesg.</para>
<para>Each open file, socket, or fifo uses one file
descriptor. A large-scale production server may easily
require many thousands of file descriptors, depending on the
kind and number of services running concurrently.</para>
<para><varname>kern.maxfile</varname>'s default value is
dictated by the maxusers option in your kernel config.
<varname>kern.maxfiles</varname> grows proportionally to the
value of maxusers.</para>
</sect3>
</sect2>
</sect1>
</chapter>