kern.maxfileskern.maxfiles 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, “file: table is full” will show up repeatedly in the system
message buffer, which can be viewed with the dmesg
command.
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.
In older FreeBSD releases, kern.maxfile's default
value is derived from the maxusers option in your
dictated by the maxusers option in your kernel configuration
file. kern.maxfiles grows proportionally to the value of
maxusers. When compiling a custom kernel, it is a good idea
to set this kernel configuration option according to the uses of your system. From this
number, the kernel is given most of its pre-defined limits. Even though a production
machine may not actually have 256 users connected at once, the resources needed may be
similar to a high-scale web server.
As of FreeBSD 4.5, kern.maxusers is automatically
sized at boot based on the amount of memory available in the system, and may be
determined at run-time by inspecting the value of the read-only kern.maxusers sysctl. Some sites will require larger or
smaller values of kern.maxusers and may set it as a
loader tunable; values of 64, 128, and 256 are not uncommon. We do not recommend
going above 256 unless you need a huge number of file descriptors; many of
the tunable values set to their defaults by kern.maxusers may be individually overridden at boot-time or
run-time in /boot/loader.conf (see the loader.conf(5) man
page or the /boot/defaults/loader.conf file for some
hints) or as described elsewhere in this document. Systems older than
FreeBSD 4.4 must set this value via the kernel config(8) option
maxusers instead.
The system will auto-tune maxusers for you if you explicitly set it to 0[1]. When setting this option, you will want to set maxusers to at least 4, especially if you are using the X Window System or compiling software. The reason is that the most important table set by maxusers is the maximum number of processes, which is set to 20 + 16 * maxusers, so if you set maxusers to 1, then you can only have 36 simultaneous processes, including the 18 or so that the system starts up at boot time and the 15 or so you will probably create when you start the X Window System. Even a simple task like reading a manual page will start up nine processes to filter, decompress, and view it. Setting maxusers to 64 will allow you to have up to 1044 simultaneous processes, which should be enough for nearly all uses. If, however, you see the dreaded proc table full error when trying to start another program, or are running a server with a large number of simultaneous users (like ftp.FreeBSD.org), you can always increase the number and rebuild.
注: maxusers does not limit the number of users which can log into your machine. It simply sets various table sizes to reasonable values considering the maximum number of users you will likely have on your system and how many processes each of them will be running. One keyword which does limit the number of simultaneous remote logins and X terminal windows is pseudo-device pty 16. With FreeBSD 5.X, you do not have to worry about this number since the pty(4) driver is “auto-cloning”; you simply use the line device pty in your configuration file.
kern.ipc.somaxconnThe kern.ipc.somaxconn sysctl variable limits the
size of the listen queue for accepting new TCP connections. The default value of
128 is typically too low for robust handling of new
connections in a heavily loaded web server environment. For such environments, it
is recommended to increase this value to 1024 or
higher. The service daemon may itself limit the listen queue size (e.g. sendmail(8), or Apache) but will often have a directive in its
configuration file to adjust the queue size. Large listen queues also do a better
job of avoiding Denial of Service (DoS) attacks.
The NMBCLUSTERS kernel configuration option dictates the
amount of network Mbufs available to the system. A heavily-trafficked server with a
low number of Mbufs will hinder FreeBSD's ability. Each cluster represents
approximately 2 K of memory, so a value of 1024 represents 2 megabytes of
kernel memory reserved for network buffers. A simple calculation can be done to
figure out how many are needed. If you have a web server which maxes out at 1000
simultaneous connections, and each connection eats a 16 K receive and
16 K send buffer, you need approximately 32 MB worth of network buffers to
cover the web server. A good rule of thumb is to multiply by 2, so
2x32 MB / 2 KB = 64 MB / 2 kB =
32768. We recommend values between 4096 and 32768 for machines with greater amounts
of memory. Under no circumstances should you specify an arbitrarily high value
for this parameter as it could lead to a boot time crash. The -m option to netstat(1) may be used
to observe network cluster use.
kern.ipc.nmbclusters loader tunable should be used to
tune this at boot time. Only older versions of FreeBSD will require you to use the NMBCLUSTERS kernel config(8) option.
For busy servers that make extensive use of the sendfile(2) system
call, it may be necessary to increase the number of sendfile(2) buffers
via the NSFBUFS kernel configuration option or by
setting its value in /boot/loader.conf (see loader(8) for
details). A common indicator that this parameter needs to be adjusted is when
processes are seen in the sfbufa state. The sysctl
variable kern.ipc.nsfbufs is a read-only glimpse
at the kernel configured variable. This parameter nominally scales with kern.maxusers, however it may be necessary to tune
accordingly.
重要: Even though a socket has been marked as non-blocking, calling sendfile(2) on the non-blocking socket may result in the sendfile(2) call blocking until enough struct sf_buf's are made available.
net.inet.ip.portrange.*The net.inet.ip.portrange.* sysctl variables
control the port number ranges automatically bound to TCP and UDP sockets. There
are three ranges: a low range, a default range, and a high range. Most network
programs use the default range which is controlled by the net.inet.ip.portrange.first and net.inet.ip.portrange.last, which default to 1024 and 5000,
respectively. Bound port ranges are used for outgoing connections, and it is
possible to run the system out of ports under certain circumstances. This most
commonly occurs when you are running a heavily loaded web proxy. The port range
is not an issue when running servers which handle mainly incoming
connections, such as a normal web server, or has a limited number of outgoing
connections, such as a mail relay. For situations where you may run yourself out of
ports, it is recommended to increase net.inet.ip.portrange.last modestly. A value of 10000, 20000 or 30000 may be reasonable. You should also consider firewall
effects when changing the port range. Some firewalls may block large ranges of
ports (usually low-numbered ports) and expect systems to use higher ranges of ports
for outgoing connections —— for this reason it is not recommended that
net.inet.ip.portrange.first be lowered.
The TCP Bandwidth Delay Product Limiting is similar to TCP/Vegas in NetBSD. It
can be enabled by setting net.inet.tcp.inflight.enable
sysctl variable to 1. The system will attempt to
calculate the bandwidth delay product for each connection and limit the amount of
data queued to the network to just the amount required to maintain optimum
throughput.
This feature is useful if you are serving data over modems, Gigabit Ethernet, or
even high speed WAN links (or any other link with a high bandwidth delay product),
especially if you are also using window scaling or have configured a large send
window. If you enable this option, you should also be sure to set net.inet.tcp.inflight.debug to 0
(disable debugging), and for production use setting net.inet.tcp.inflight.min to at least 6144 may be beneficial. However, note that setting high
minimums may effectively disable bandwidth limiting depending on the link. The
limiting feature reduces the amount of data built up in intermediate route and
switch packet queues as well as reduces the amount of data built up in the local
host's interface queue. With fewer packets queued up, interactive
connections, especially over slow modems, will also be able to operate with lower
Round Trip Times. However,
note that this feature only effects data transmission (uploading / server side). It
has no effect on data reception (downloading).
Adjusting net.inet.tcp.inflight.stab is not recommended. This parameter defaults
to 20, representing 2 maximal packets added to the bandwidth delay product
window calculation. The additional window is required to stabilize the algorithm
and improve responsiveness to changing conditions, but it can also result in higher
ping times over slow links (though still much lower than you would get without the
inflight algorithm). In such cases, you may wish to try reducing this
parameter to 15, 10, or 5; and may also have to reduce net.inet.tcp.inflight.min (for example, to 3500) to get the
desired effect. Reducing these parameters should be done as a last resort only.
kern.maxvnodesA vnode is the internal representation of a file or directory. So increasing the number of vnodes available to the operating system cuts down on disk I/O. Normally this is handled by the operating system and does not need to be changed. In some cases where disk I/O is a bottleneck and the system is running out of vnodes, this setting will need to be increased. The amount of inactive and free RAM will need to be taken into account.
To see the current number of vnodes in use:
# sysctl vfs.numvnodes vfs.numvnodes: 91349
To see the maximum vnodes:
# sysctl kern.maxvnodes kern.maxvnodes: 100000
If the current vnode usage is near the maximum, increasing kern.maxvnodes by a value of 1,000 is probably a good idea. Keep
an eye on the number of vfs.numvnodes. If it climbs up to
the maximum again, kern.maxvnodes will need to be increased
further. A shift in your memory usage as reported by top(1) should be
visible. More memory should be active.
| [1] |
The auto-tuning algorithm sets maxusers equal to the amount of memory in the system, with a minimum of 32, and a maximum of 384. |
本文及其他文件，可由此下載：ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/。
若有 FreeBSD 方面疑問，請先閱讀 FreeBSD 相關文件，如不能解決的話，再洽詢
<questions@FreeBSD.org>。
關於本文件的問題，請洽詢 <doc@FreeBSD.org>。