kern.maxfiles 可以根据系统的需要适当增减。 这个变量用于指定在系统中允许的文件描述符的最大数量。 当文件描述符表满的时候， file: table is full 会在系统消息缓冲区中反复出现， 您可以使用 dmesg 命令来观察这一现象。

每个打开的文件、 套接字和管道， 都会占用一个文件描述符。 在大型生产服务器上， 可能会轻易地用掉数千个文件描述符， 具体用量取决于服务的类型和并行启动的服务数量。

在早期版本的 FreeBSD 中， kern.maxfiles 的默认值， 是根据您内核配置文件中的 maxusers 选项计算的。 kern.maxfiles 这个数值， 会随 maxusers 成比例地增减。 当编译定制的内核时， 按照您系统的用途来修改这个值是个好主意。 这个数字同时还决定内核的许多预设的限制值。 有时， 尽管并不会真的有 256 个用户同时连接一台生产服务器， 但对于高负载的 web 服务器而言， 却可能需要与之类似的资源。

变量 kern.maxusers 会在系统启动时， 根据可用内存的尺寸进行计算， 在内核开始运行之后， 可以通过只读的 kern.maxusers sysctl 变量值来进行观察。 有些情况下， 可能会希望使用更大或更小一些的 kern.maxusers， 它可以以加载器变量的形式进行配置； 类似 64、 128 和 256 这样的值都并不罕见。 我们不推荐使用超过 256 的值， 除非您需要巨量的文件描述符； 根据 kern.maxusers 推算默认值的那些变量， 一般都可以在引导甚至运行时通过 /boot/loader.conf (请参见 loader.conf(5) 联机手册或 /boot/defaults/loader.conf 文件来获得相关的指导) 或这篇文档的其余部分所介绍的方式来调整。

在较早的版本中， 如果您明确地将 maxusers 设置为 0， 则系统会自动地根据硬件配置来确定这个值。^[5]。 在 FreeBSD 5.X 和更高版本中， maxusers 如果不指定的话， 就会取默认值 0。 如果希望自行管理 maxusers， 则应配置一个不低于 4 的值， 特别是使用 X Window System 或编译软件的时候。 这样做的原因是， maxusers 所决定的一个最为重要的表的尺寸会影响最大进程数， 这个数值将是 20 + 16 * maxusers。 因此如果将 maxusers 设置为 1， 您就只能同时运行 36 个进程， 这还包括了 18 个左右的系统引导时启动的进程， 以及 15 个左右的， 在您启动 X Window System 时所引发的进程。 即使是简单的任务， 如阅读联机手册， 也需要启动多至九个的进程， 用以过滤、 解压缩， 并显示它。 将 maxusers 设为 64 将允许您同时执行最多 1044 个进程， 这几乎足以满足任何需要了。 不过， 如果您看在启动其它程序， 或运行用以支持大量用户的服务 (例如 ftp.FreeBSD.org) 时， 看到令人担忧的 proc table full 错误， 就应该提高这一数值， 并重新联编内核。

kern.ipc.somaxconn sysctl 变量 限制了接收新 TCP 连接侦听队列的大小。对于一个经常处理新连接的高负载 web服务环境来说，默认的 128 太小了。 大多数环境这个值建议增加到 1024 或者更多。 服务进程会自己限制侦听队列的大小(例如 sendmail(8) 或者 Apache)， 常常在它们的配置文件中有设置队列大小的选项。 大的侦听队列对防止拒绝服务 DoS 攻击也会有所帮助。

net.inet.ip.portrange.* sysctl 变量自动的控制绑定在 TCP 和 UDP 套接字上的端口范围。 这里有三个范围：一个低端范围，一个默认范围和一个高端范围。 大多数网络程序分别使用由 net.inet.ip.portrange.first 和 net.inet.ip.portrange.last 控制的从 1024 到 5000 的默认范围。端口范围用作对外连接，并且某些情况可能用完系统的端口， 这经常发生在运行一个高负荷 web 代理服务器的时候。 这个端口范围不是用来限制主要的例如 web 服务器进入连接或者有固定端口例如邮件传递对外连接的。 有时您可能用完了端口，那就建议适当的增加 net.inet.ip.portrange.last。 10000、20000 或者 30000 可能是适当的值。 更改端口范围的时候也要考虑到防火墙。 一些防火墙会阻止端口的大部分范围 (通常是低范围的端口)并且用高端口进行对外连接(──)。 基于这个问题建议不要把 net.inet.ip.portrange.first 设的太小。

限制 TCP 带宽延迟积和 NetBSD 的 TCP/Vegas 类似。 它可以通过将 sysctl 变量 net.inet.tcp.inflight.enable 设置成 1 来启用。 系统将尝试计算每一个连接的带宽延迟积， 并将排队的数据量限制在恰好能保持最优吞吐量的水平上。

这一特性在您的服务器同时向使用普通调制解调器， 千兆以太网， 乃至更高速度的光与网络连接 (或其他带宽延迟积很大的连接) 的时候尤为重要， 特别是当您同时使用滑动窗缩放， 或使用了大的发送窗口的时候。 如果启用了这个选项， 您还应该把 net.inet.tcp.inflight.debug 设置为 0 (禁用调试)， 对于生产环境而言， 将 net.inet.tcp.inflight.min 设置成至少 6144 会很有好处。 然而， 需要注意的是， 这个值设置过大事实上相当于禁用了连接带宽延迟积限制功能。 这个限制特性减少了在路由和交换包队列的堵塞数据数量， 也减少了在本地主机接口队列阻塞的数据的数量。在少数的等候队列中、 交互式连接，尤其是通过慢速的调制解调器，也能用低的 往返时间操作。但是，注意这只影响到数据发送 (上载/服务端)。对数据接收(下载)没有效果。

调整 net.inet.tcp.inflight.stab 是 不 推荐的。 这个参数的默认值是 20， 表示把 2 个最大包加入到带宽延迟积窗口的计算中。 额外的窗口似的算法更为稳定， 并改善对于多变网络环境的相应能力， 但也会导致慢速连接下的 ping 时间增长 (尽管还是会比没有使用 inflight 算法低许多)。 对于这些情形， 您可能会希望把这个参数减少到 15， 10， 或 5； 并可能因此而不得不减少 net.inet.tcp.inflight.min (比如说， 3500) 来得到希望的效果。 减少这些参数的值， 只应作为最后不得已时的手段来使用。

vnode 是对文件或目录的一种内部表达。 因此， 增加可以被操作系统利用的 vnode 数量将降低磁盘的 I/O。 一般而言， 这是由操作系统自行完成的， 也不需要加以修改。 但在某些时候磁盘 I/O 会成为瓶颈， 而系统的 vnode 不足， 则这一配置应被增加。 此时需要考虑是非活跃和空闲内存的数量。

要查看当前在用的 vnode 数量：

要查看最大可用的 vnode 数量：

如果当前的 vnode 用量接近最大值， 则将 kern.maxvnodes 值增大 1,000 可能是个好主意。 您应继续查看 vfs.numvnodes 的数值， 如果它再次攀升到接近最大值的程度， 仍需继续提高 kern.maxvnodes。 在 top(1) 中显示的内存用量应有显著变化， 更多内存会处于活跃 (active) 状态。