tuning.7 (rev 1.1.2.9 to 1.1.2.22)

svn path=/head/; revision=11447

ja_JP.eucJP/man/man7/tuning.7

@@ -2,7 +2,7 @@
 .\" the BSD Copyright as specified in the file "/usr/src/COPYRIGHT" in
 .\" the source tree.
 .\"
-.\" %FreeBSD: src/share/man/man7/tuning.7,v 1.1.2.9 2001/11/02 08:01:39 silby Exp %
+.\" %FreeBSD: src/share/man/man7/tuning.7,v 1.1.2.22 2001/12/14 11:38:42 rwatson Exp %
 .\"
 .\" $FreeBSD$
 .Dd May 25, 2001
@@ -22,8 +22,15 @@
 後でマシンを増強した時にシステム標準のファイルシステムの大きさを
 変更しなくて済むような大きさに決めることが重要です。
 私は大抵、順番にルートパーティションに 128M、スワップに 1G、
-/var に 128M、/var/tmp に 128M、/usr に 3G、
-そして残りを /home に割り当てます。
+.Pa /var
+に 128M、
+.Pa /var/tmp
+に 128M、
+.Pa /usr
+に 3G、
+そして残りを
+.Pa /home
+に割り当てます。
 .Pp
 典型的にはメインメモリの約 2 倍のスワップスペースを用意すべきです。
 RAM がそれほど多くない場合は、一般にもっとスワップが必要でしょう。
@@ -52,80 +59,106 @@ VM
 プログラムの暴走で強制的にリブートしてしまう前に、
 回復作業をするための時間稼ぎになります。
 .Pp
-.Em /var
+.Pa /var
 パーティションをどれだけの大きさにするかは、そのマシンを
 何に使うかということに大きく依存します。
 このパーティションは主にメールボックスやプリントスプール、
 ログファイルの保存場所に使われます。
-.Em /var/log
+.Pa /var/log
 を別のパーティションにする人もいます (しかし、パーティション ID を
-消費しないほうがよい極端な場合は例外です)。
+消費しないほうが良い極端な場合は例外です)。
 メールサーバやプリントサーバ、あるいは
 訪問数が非常に多い Web サーバとしてマシンが動作するなら、
-極めて大きいパーティション―おそらく 1 ギガバイト以上―を
+極めて大きいパーティション \(en おそらく 1 ギガバイト以上 \(en を
 作成することを考えるべきでしょう。
 ログファイルの保存に必要な大きさは、小さく見積もられがちです。
 .Pp
-.Em /var/tmp
+.Pa /var/tmp
 の大きさは、テンポラリファイルの類が
 どれだけ使われる必要があるかで決まります。
 最低でも 128M にすることを推奨します。
-sysinstall は /tmp ディレクトリを作成しますが、
-.Em /tmp
+sysinstall は
+.Pa /tmp
+ディレクトリを作成しますが、
+.Pa /tmp
 は後で
-.Em /var/tmp
-へのソフトリンクにしておくのは大抵よい考えです。
-テンポラリファイル領域専用に一つのパーティションを
+.Pa /var/tmp
+へのソフトリンクにしておくのは大抵良い考えです。
+テンポラリファイル領域専用に 1 つのパーティションを
 割り当てることは重要で、2 つの理由があります:
 クラッシュ時のファイルシステムの破壊の可能性を
-減らすのと、[/var]/tmp を一杯にしてしまう
+減らすのと、
+.Oo Pa /var Oc Ns Pa /tmp
+を一杯にしてしまう
 ような暴走プロセスが、さらに重要なサブシステム
 (メールやログ等) に影響を与える可能性を減らすためです。
-[/var]/tmp が一杯になってしまうのはよくある問題です。
+.Oo Pa /var Oc Ns Pa /tmp
+が一杯になってしまうのはよくある問題です。
 .Pp
-かつては /tmp と /var/tmp の間には違いがありましたが、
-/var (と /var/tmp) の導入によってプログラマは大変混乱し、
-今日では両方がでたらめに使われています。つまり
-この二つは実際には区別することができません。
-したがって、一つのテンポラリディレクトリだけにしてしまうことは
+かつては
+.Pa /tmp
+と
+.Pa /var/tmp
+の間には違いがありましたが、
+.Pa /var
+(と
+.Pa /var/tmp )
+の導入によってプログラマは大変混乱し、
+今日では両方がでたらめに使われています。
+つまりこの 2 つは実際には区別することができません。
+したがって、1 つのテンポラリディレクトリだけにしてしまうことは
 意味があります。
-どのように /tmp を扱ったとしても、
+どのように
+.Pa /tmp
+を扱ったとしても、
 それがルートパーティションにあるのは好ましくないですしょう。
 一杯になったり、クラッシュやリブートにより破壊される
 可能性があるからです。
 .Pp
-.Em /usr
+.Pa /usr
 パーティションはシステムをサポートするために
 必要なファイルの大部分を持っており、そのサブディレクトリ
-.Em /usr/local
+.Pa /usr/local
 は
 .Xr ports 7
 階層からインストールされるファイルの大部分が置かれます。
-ports をあまり使わず、システムのソース (/usr/src) を
-保持するつもりがなければ /usr は 1 ギガバイトで十分でしょう。
+ports をあまり使わず、システムのソース
+.Pq Pa /usr/src
+を保持するつもりがなければ
+.Pa /usr
+は 1 ギガバイトで十分でしょう。
 しかし、大量の ports (特にウィンドウマネージャや
 Linux エミュレーションされるバイナリ) をインストールする場合は、
-少なくとも 2 ギガバイトを推奨します。さらに、システムのソースを
-保持するつもりであれば、3 ギガバイトを推奨します。
+少なくとも 2 ギガバイトの
+.Pa /usr
+を推奨します。
+さらに、システムのソースを保持するつもりであれば、3 ギガバイトの
+.Pa /usr
+を推奨します。
 このパーティションに対して必要な領域の大きさを過小評価
 しないでください。これは緩やかに成長し、驚かされることになります !
 .Pp
-.Em /home
+.Pa /home
 パーティションはユーザ固有のデータを保持するのに使われます。
 私は大抵ディスクの残りを使います。
 .Pp
 何故 パーティションを切るのでしょう ?
-一つの大きな
-.Em /
-パーティションを作るだけでいいのではないでしょうか ?
+1 つの大きな
+.Pa /
+パーティションを作るだけで良いのではないでしょうか ?
 そうすれば小さすぎないかどうか気にする必要はないのに !
-はい、その考えがよくないのは、いくつか理由があります。
-一つめは、それぞれのパーティションは運用上の性格が
+はい、その考えが良くないのは、いくつか理由があります。
+1 つめは、それぞれのパーティションは運用上の性格が
 異なるのですが、それらを分離することでファイルシステムに対し
 その性格に適したチューンをすることが可能になるからです。
-例えばルートパーティションや /usr パーティションはほとんど
-読み込みであり、ほとんど書き込みがありません。一方で
-/var や /var/tmp に対しては大量の読み込みや書き込みがあるでしょう。
+例えばルートパーティションや
+.Pa /usr
+パーティションはほとんど読み込みであり、ほとんど書き込みがありません。
+一方で
+.Pa /var
+や
+.Pa /var/tmp
+に対しては大量の読み込みや書き込みがあるでしょう。
 システムをうまく分割することで、書き込みが多いパーティションの破壊に
 よる被害が、ほとんど読み込みのみのパーティションに及ばないようします。
 加えて、書き込みが多いパーティションをディスクの端
@@ -133,10 +166,12 @@ Linux
 本当に大きなパーティションの後ろではなく、前の方)
 の方に置くことで、そのパーティションについて性能が向上します。
 より大きなパーティションについても入出力性能が必要なのも確かですが、
-/var をディスクの端に置くと大きな改善が可能であるのに対し、
+.Pa /var
+をディスクの端に置くと大きな改善が可能であるのに対し、
 巨大なパーティションをディスクの端に置いてもそれほど性能の
 改善にはつながりません。
-最後は安全性に関わることです。小さく、簡潔な、本質的に読み取りのみの
+最後は安全性に関わることです。
+小さく、簡潔な、本質的に読み込みのみの
 ルートパーティションとすることで、クラッシュを生き延びるチャンスを
 大きくすることができます。
 .Pp
@@ -156,18 +191,31 @@ Linux
 .Fx
 は 8K または 16K のファイルシステムブロックサイズを使用した時に
 最高の性能が得られます。
-デフォルトは 8K です。大きなパーティションでは、
-16K ブロックサイズにするのも大抵よい考えです。
-これにはより大きいフラグメントサイズを指定する必要もあります。
+デフォルトは 16K であり、
+ほとんどのアプリケーションで良い結果となりますが、
+大きなファイルにランダムアクセスするアプリケーション
+(データベースサーバソフトウェア等) は例外です。
+このようなアプリケーションでは、
+小さなブロックサイズで良い結果となる傾向がありますが、
+最近のディスクの特性においては、
+小さなブロックサイズの使用は考慮に値しないでしょう。
+16K より大きなブロックサイズを使用すると
+バッファキャッシュの断片化を招き、性能が低下します。
+.Pp
+デフォルトは、
+多大な inode を必要とするファイルシステムや、
+多大な小ファイルを保持することを意図したファイルシステムには
+向かないかもしれません。
+このようなファイルシステムは、
+8K または 4K のブロックサイズで作成されるべきです。
+これはまた、小さなフラグメントサイズを指定する必要があります。
 常にブロックサイズの 1/8 のフラグメントサイズにすることを推奨します
 (他のフラグメントサイズの割合ではあまりテストされていません)。
 この場合の
-.Fn newfs
+.Xr newfs 8
 オプションは
-.Em newfs -f 2048 -b 16384 ...
+.Dq Li "newfs -f 1024 -b 8192 ..."
 となるでしょう。
-さらに大きなブロックサイズはバッファキャッシュの断片化の原因
-となり、性能の低下につながります。
 .Pp
 大きなパーティションに、データベースファイルのような
 少数の大きなファイルを置くのであれば、
@@ -181,20 +229,13 @@ i
 このオプションを使わないでください。
 空き領域が大量にあるのにファイルを収容できなくなるかもしれません。
 bytes/inode は、32768 か 65536 か 262144 とすることが推奨されます。
-もっと大きな値にすることができますが、fsck による修復時間を増やすだけでしょう。
+もっと大きな値にすることができますが、
+.Xr fsck 8
+による修復時間を増やすだけでしょう。
 例えば、 
-.Em newfs -i 32768 ...
+.Dq Li "newfs -i 32768 ..."
 のようにして値を与えます。
 .Pp
-最後に、
-.Em cylinders/group
-の比率を増やすことは、i ノード同士を近くに寄せる効果があります。
-これはディレクトリの性能を上げ、fsck にかかる時間を減らします。
-もしこのオプションを使うのであれば、最大にすることを推奨します。
-.Em newfs -c 999
-とすれば newfs はエラーとなり最大値を教えてくれるので、その値を
-使ってください。
-.Pp
 .Xr tunefs 8
 はファイルシステムをさらにチューンするのに使えます。
 このコマンドは、シングルユーザモードで実行することができ、
@@ -203,12 +244,21 @@ bytes/inode
 多くの人はファイルシステムの利用可能な空き領域を増やそうとして、
 min-free 比率を 0 に設定します。
 これはファイルシステムの猛烈な断片化につながるので、推奨されません。
-ここで、唯一本当に価値がある tunefs のオプションは、
-.Em tunefs -n enable /filesystem
+ここで、唯一本当に価値がある
+.Xr tunefs 8
+のオプションは、
+.Dq Li "tunefs -n enable /filesystem"
 として
 .Em softupdates
 を有効にすることです
-(注意: 5.x では newfs に -U オプションを与えることで softupdates を有効に
+(注意:
+.Fx
+5.x
+では
+.Xr newfs 8
+に
+.Fl U
+オプションを与えることで softupdates を有効に
 することができます)。
 softupdates はメタデータの性能、
 主にファイルの作成と削除の性能を劇的に改善します。
@@ -223,32 +273,49 @@ softupdates
 ということです。
 あるファイルシステム (例えばルートファイルシステム) が満杯近くの時に
 それに対する大規模な更新、たとえば
-.Em make installworld
+.Dq Li "make installworld"
 をすると、空き領域を使い果たして更新が失敗してしまうことがあります。
 .Pp
-マウント実行時のいくつかのオプションはファイルシステムを
-チューンするのに役立ちます。
+.Xr mount 8
+実行時のいくつかのオプションはファイルシステムをチューンするのに役立ちます。
 最も明らかで、しかも最も危険なのは
-.Em async
-です。これは決して使わないでください。大変危険です。
-比較的危険度が低く、より役に立つマウントオプションは
-.Em noatime
+.Cm async
 です。
-通常 UNIX ファイルシステムは、ファイルやディレクトリにアクセスが
+これは決して使わないでください。
+大変危険です。
+比較的危険度が低く、より役に立つ
+.Xr mount 8
+のオプションは
+.Cm noatime
+です。
+通常
+.Ux
+ファイルシステムは、ファイルやディレクトリにアクセスが
 あった場合は常に、その最終アクセス時刻を更新します。
-FreeBSD では、この動作は遅延書き込みで行なわれ、
+.Fx
+では、この動作は遅延書き込みで行なわれ、
 通常は大した負荷にはなりません。
 しかし、大量のファイルが連続してアクセスされた場合、
 バッファキャッシュがアクセス時刻の更新で汚染され
 大きな負荷となります。
 例えば、高負荷の web サイトや大量の読者を抱えるニューズサーバ
-では、このマウントオプションで大きなパーティションにおける
+では、この
+.Xr mount 8
+のオプションで大きなパーティションにおける
 アクセス時刻の更新を停止することが考えられます。
 根拠もなく、すべての場所でアクセス時刻の更新を停止しないでください。
-例えば / や /usr のようなほとんど読み込みのみの
-パーティションはオンにしたままにすることができるでしょう
-(特に / についてはいくつかのシステムユーティリティが
-アクセス時刻フィールドをリポートのために利用します)。
+例えば、
+.Pa /var
+ファイルシステムは、慣習的にメールボックスを保持し、
+新規メールのメールボックス中の有無判定に atime (および mtime) が使用されます。
+読み込み専用パーティション、
+.Pa /
+や
+.Pa /usr
+では、atime をオンにしておいた方が良いでしょう。
+システムユーティリティには、atime フィールドを使用するものがあるので、
+.Pa /
+では特に有用です。
 .Sh ディスクのストライピング
 大きなシステムでは、いくつかのドライブのパーティションを互いに
 ストライピングして、全体として巨大なパーティションを作ることもあります。
@@ -256,14 +323,22 @@ FreeBSD
 ファイルシステムの性能を向上させることができます。
 .Xr vinum 8
 および
-.Xr ccd 4
+.Xr ccdconfig 8
 ユーティリティは、シンプルなストライピングされたファイルシステムを
 作るのに使われます。
-一般に、ルートや /var/tmp のような小さなパーティション、
-あるいは /usr のような本質的に読み込みのみのパーティションを
+一般に、ルートや
+.Pa /var/tmp
+のような小さなパーティション、
+あるいは
+.Pa /usr
+のような本質的に読み込みのみのパーティションを
 ストライピングしても時間の無駄にしかなりません。
-本当に入出力性能を必要とするパーティションのみをストライピングする
-べきです。典型的には /var や /home あるいはデータベースや Web ページを
+本当に入出力性能を必要とするパーティションのみをストライピングするべきです。
+典型的には
+.Pa /var
+や
+.Pa /home
+あるいはデータベースや Web ページを
 保持するカスタムパーティションです。
 適切なストライプサイズを選ぶことも重要です。
 ファイルシステムはメタデータを 2 の累乗の境界で格納する傾向にあり、
@@ -285,10 +360,10 @@ FreeBSD
 そうでないものも多く含まれます。この文書では
 システムに最も大きな影響を与えるものだけを扱います。
 .Pp
-.Em kern.ipc.shm_use_phys
-は、デフォルトが 0 (オフ) であり、
+.Va kern.ipc.shm_use_phys
+sysctl は、デフォルトが 0 (オフ) であり、
 0 (オフ) または 1 (オン) にセットすることができます。
-このパラメータを 1 にセットすると、全ての SysV 共有メモリセグメントが
+このパラメータを 1 にセットすると、全ての System V 共有メモリセグメントが
 ページング不可の物理メモリにマップされます。
 これは、(A) 大量 (数百) のプロセス間で少量の共有メモリを
 マッピングしているか、(B) 任意個のプロセス間で大量の共有メモリを
@@ -298,8 +373,8 @@ FreeBSD
 カーネルにおける内部のメモリ管理によるページ追跡
 オーバヘッドをかなり減らします。
 .Pp
-.Em vfs.vmiodirenable
-は、デフォルトは 0 (オフ) であり (しかし近いうちにデフォルトが 1 に
+.Va vfs.vmiodirenable
+sysctl は、デフォルトは 0 (オフ) であり (しかし近いうちにデフォルトが 1 に
 なるでしょう)、0 (オフ) または 1 (オン) にセットすることができます。
 このパラメータは、ディレクトリがシステムによってどのように
 キャッシュされるかを制御します。
@@ -317,26 +392,29 @@ VM
 キャッシュするのに使えるようになるということです。
 欠点は、キャッシュに使われる最小のメモリの大きさが 512 バイトではなく
 物理ページサイズ (大抵は 4K) になることです。
-多数のファイルを操作するサービスを稼動しているなら、
-常にこのオプションをオンにすることを推奨します。
+メモリに制約があるシステムでは、
+このオプションをオフにすることを推奨します。
+一方、オンにすると、多数のファイルを操作するサービスの性能が向上します。
 そのようなサービスには、web キャッシュや、大規模なメールシステム、
 ニューズシステムなどが含まれます。このオプションは一般に
 メモリを消費しますが、性能を削減することはありません。
 ただし実験して調べてみるべきでしょう。
 .Pp
 バッファキャッシュと VM ページキャッシュに関連した、様々な sysctl が
-存在します。これらを闇雲に変更するのは推奨されません。
+存在します。
+これらを変更することは推奨されません。
 .Fx 4.3
-について言えば、VM システムは自分自身のチューニングに関して大変よい
+について言えば、VM システムは自分自身のチューニングに関して大変良い
 仕事をしています。
 .Pp
-.Em net.inet.tcp.sendspace
-と
-.Em net.inet.tcp.recvspace
-は、ネットワークに関連するアプリケーションを
+.Va net.inet.tcp.sendspace
+sysctl と
+.Va net.inet.tcp.recvspace
+sysctl は、ネットワークに関連するアプリケーションを
 稼動している場合は特に重要です。これは、TCP コネクションの
 送信および受信バッファ領域の大きさを調節します。
-デフォルトは 16K です。このデフォルトを増やすことで
+デフォルトでは、送信バッファは 32K で、受信バッファは 64K です。
+このデフォルトを増やすことで
 各コネクションについてカーネルメモリがさらに消費されますが、
 帯域幅の利用率が改善することがあります。
 同時に数百とか数千のコネクションを扱っている場合、
@@ -354,6 +432,7 @@ sendspace
 .Xr route 8
 を参照 ) に対しては、経路に特化した送受信バッファを導入することが
 できるということに注意してください。
+.Pp
 付加的な管理ツールとして、ファイアウォールルールにおいて
 パイプ (pipe) を使うことで (
 .Xr ipfw 8
@@ -368,7 +447,7 @@ web
 また、多くの人が、帯域超過による課金をされないように
 意図的な帯域制限をかけています。
 .Pp
-.Em net.inet.tcp.rfc1323
+.Va net.inet.tcp.rfc1323
 sysctl で制御可能な TCP プロトコルのウィンドウスケーリング拡張を
 両方のホストがサポートしない限り、
 TCP の送信あるいは受信バッファサイズを 65535 を超えて指定しても
@@ -377,9 +456,10 @@ TCP
 これらの拡張を有効にし、
 TCP バッファサイズを 65536 より大きく設定すべきです。
 特に、ギガビット WAN リンクや、高レイテンシの衛星リンクが対象となります。
+RFC1323 サポートは、デフォルトでオンになっています。
 .Pp
-.Em net.inet.tcp.always_keepalive
-はオン (1 にセット) にしてそのままにしておいてください。
+.Va net.inet.tcp.always_keepalive
+sysctl はオン (1 にセット) にしてそのままにしておいてください。
 デフォルトは大抵オフです。少量のネットワーク帯域を消費しますが、
 偶然死んでしまった TCP コネクションを認識し除去することを保証します。
 死んでしまった TCP コネクションは、特にダイアルアップのユーザによりアクセス
@@ -387,31 +467,36 @@ TCP
 ユーザは、しばしば正しくアクティブコネクションを閉じずにモデムを切断
 するからです。
 .Pp
-.Em kern.ipc.somaxconn
-は、新しい TCP コネクションを受け付けるための listen キューの
+.Va kern.ipc.somaxconn
+sysctl は、新しい TCP コネクションを受け付けるための listen キューの
 サイズを制限します。高負荷の web サーバ環境では、
 デフォルト値の 128 は新しいコネクションを余裕をもって扱うには低すぎます。
 そのような環境では、この値を 1024 以上に増やすことが推奨されます。
-サービスデーモン (例えば sendmail や apache) は自分自身の
+サービスデーモン (例えば
+.Xr sendmail 8
+や apache) は自分自身の
 listen キューのサイズを制限しているかもしれませんが、設定ファイルで
 キューのサイズを増やすディレクティブを持つようになるでしょう。
 listen キューを大きくすることは、サービス拒否攻撃を防ぐのにも役立ちます。
 .Pp
-.Em kern.maxfiles
-は、システムがどれだけの数のファイルをオープンできるかを
+.Va kern.maxfiles
+sysctl は、システムがどれだけの数のファイルをオープンできるかを
 決めます。デフォルトは典型的には数千ですが、データベースや記述子を
 大量に使うデーモンを稼働している場合は 10000 や 20000 に引き上げる必要
 があるかもしれません。
+読み込み専用の
+.Va kern.openfiles
+sysctl を検査することで、システム上で開かれているファイル数を判定可能です。
 .Pp
-.Em vm.swap_idle_enabled
-は、多数のユーザがシステムに出入りして大量のアイドルプロセスが
+.Va vm.swap_idle_enabled
+sysctl は、多数のユーザがシステムに出入りして大量のアイドルプロセスが
 ある大きなマルチユーザシステムで便利です。
 そのようなシステムでは、フリーメモリの予約に対し、
 継続して重大な負担をかける傾向にあります。これをオンにして
-.Em vm.swap_idle_threshold1
-と
-.Em vm.swap_idle_threshold2
-でスワップアウトヒステリシス (アイドルの秒数) を調整することで
+.Va vm.swap_idle_threshold1
+sysctl と
+.Va vm.swap_idle_threshold2
+sysctl でスワップアウトヒステリシス (アイドルの秒数) を調整することで
 アイドルプロセスに与えられているページの優先度を通常のページアウト
 アルゴリズムよりも速やかに下げることができます。
 これはページアウトデーモンを手助けします。必要がないかぎり、
@@ -423,15 +508,15 @@ listen
 すでにある程度ページングが発生している大きなシステムでは、
 このオプションによって、全体のプロセスがより容易にメモリへ入ったり
 出たりするようにできるでしょう。
-.Sh ブート時の SYSCTL チューニング
-sysctl によっては、
+.Sh ローダのチューナブル
+システムの動作の一部は、
 そのためのメモリ割り当てをブート処理の初期に行う必要があるために、
-実行時にチューニング不可のものがあります。
-これらの sysctl を変更するには、これらの値を
+実行時には調整不可能です。
+ローダのチューナブルを変更するには、これらの値を
 .Xr loader.conf 5
 に設定し、システムをリブートする必要があります。
 .Pp
-.Em kern.maxusers
+.Va kern.maxusers
 sysctl のデフォルトは驚くほど小さな値です。
 最近のマシンでは、おそらく 64 か 128 あるいは 256 に
 増やしたいと思うでしょう。莫大な数のファイル記述子が必要でない限り、
@@ -439,10 +524,15 @@ sysctl
 ネットワークバッファにも影響を与えますが、別のカーネルオプションで
 制御できます。ネットワーク mbuf をさらに得るためだけに maxusers を
 増やさないでください。
-FreeBSD 4.4 より古いシステムでは、この sysctl がありませんので、
-代りにカーネル設定オプションの maxusers を設定する必要があります。
+.Fx 4.4
+より古いシステムでは、このローダのチューナブルがありませんので、
+代りにカーネルの
+.Xr config 8
+オプションの
+.Cd maxusers
+を設定する必要があります。
 .Pp
-.Em NMBCLUSTERS
+.Va kern.ipc.nmbclusters
 を調整することで、システムが割り当てようとしている
 ネットワーク mbuf の数を増やすことができます。
 それぞれのクラスタは約 2K のメモリに相当するので、
@@ -452,61 +542,73 @@ FreeBSD 4.4
 web サーバが同時に最大 1000 本のコネクションを扱い、
 各コネクションが 16K の受信バッファと 16K の送信バッファを消費する場合、
 約 32MB に相当するネットワークバッファを扱う必要があります。
-経験から得た方法によると、2 倍するとよいとされています。
+経験から得た方法によると、2 倍すると良いとされています。
 つまり 32MBx2 = 64MB/2K = 32768 です。
-したがって、この場合は nmbclusters を32768 に設定します。
+したがって、この場合は
+.Va kern.ipc.nmbclusters
+を 32768 に設定します。
 中くらいの量のメモリが搭載されたマシンでは 1024 から 4096、
 さらに大量のメモリが搭載されているなら 4096 から 32768 の値を
 推奨します。
 決して大きい値を指定すべきではありません。
 ブート時にクラッシュを引き起こす可能性があります。
 .Xr netstat 1
-に -m オプションを与えることで、ネットワーククラスタの使用状況が分かります。
-古い FreeBSD ではこの sysctl を持ちませんので、
-代りにカーネル設定オプションの NMBCLUSTERS を設定する必要があります。
+に
+.Fl m
+オプションを与えることで、ネットワーククラスタの使用状況が分かります。
+古い
+.Fx
+ではこのチューナブルを持ちませんので、
+代りにカーネルの
+.Xr config 8
+オプションの
+.Dv NMBCLUSTERS
+を設定する必要があります。
 .Pp
 ますます多くのプログラムが
-.Fn sendfile
+.Xr sendfile 2
 システムコールを使ってネットワークを通じてファイルを
 転送しています。
-.Em kern.ipc.nsfbufs
+.Va kern.ipc.nsfbufs
 sysctl は
-.Fn sendfile
+.Xr sendfile 2
 の実行時にファイルシステムバッファをどれだけの数だけ
-使えるかを制御します。通常このパラメータは 
-.Em maxusers
+使えるかを制御します。
+通常このパラメータは 
+.Va kern.maxusers
 に比例しているので、極端な場合を除いては
 このパラメータに手を出す必要はありません。
-.Pp
 .Sh カーネル構成におけるチューニング
 大規模なシステムでは、いくつかのカーネルオプションを操作しなければ
 ならないかもしれません。これらのオプションを変更する場合、あなたは
 ソースから新しいカーネルをコンパイルできなければなりません。
 .Xr config 8
-マニュアルページやハンドブックがよい入門となるでしょう。
+マニュアルページやハンドブックが良い入門となるでしょう。
 あなただけのカスタムカーネルを作るときに一般に最初にすることは、
 使用しないドライバやサービスをすべて削ることです。
-.Em INET6
+.Dv INET6
 や使わないドライバを削除することで、カーネルのサイズを時に
 1 メガバイト以上減らすことができ、アプリケーションにさらに
 メモリを与えることができます。
 .Pp
-.Em SCSI_DELAY
+.Dv SCSI_DELAY
 と
-.Em IDE_DELAY
+.Dv IDE_DELAY
 は、システムの起動時間を減らすために使うことができます。
 このデフォルト値はかなり大きく、ブート処理の中で 15 秒以上を占めるでしょう。
-SCSI_DELAY を 5 秒に減らしても大抵はうまく動きます (特に最近のドライブでは)。
-IDE_DELAY を減らしてもうまくいきますが、少々慎重になる必要があります。
+.Dv SCSI_DELAY
+を 5 秒に減らしても大抵はうまく動きます (特に最近のドライブでは)。
+.Dv IDE_DELAY
+を減らしてもうまくいきますが、少々慎重になる必要があります。
 .Pp
-.Em XXX_CPU
+.Dv *_CPU
 オプションの多くはコメントアウトできます。
 そのカーネルを Pentium クラスの CPU だけで動かすなら、
-.Em I386_CPU
+.Dv I386_CPU
 と
-.Em I486_CPU
+.Dv I486_CPU
 は削除することができます。ただし、
-.Em I586_CPU
+.Dv I586_CPU
 は、CPU が Pentium II 以上として認識されることを確認してから
 削除してください。Pentium や 486 としてさえ認識されるクローンが存在し、
 その場合はこれらのオプションがないと起動することができません。
@@ -532,10 +634,10 @@ IDE
 もたらします。したがって私たちはデフォルトを安全側に変更しました。
 残念ながら、これは大変な性能の低下をもたらし、私たちはあきらめて
 このリリース後にオンに戻しました。
-.Em hw.ata.wc
+.Va hw.ata.wc
 sysctl 変数を見て、デフォルトをチェックしてみるべきです。
 もし IDE ライトキャッシュがオフになっていたら、
-.Em hw.ata.wc
+.Va hw.ata.wc
 カーネル変数を 1 に戻すことでオンに戻すことができます。
 これはブート時にブートローダから行わなければなりません。
 カーネルがブートした後に行っても効果はありません。
@@ -545,11 +647,13 @@ sysctl
 を参照してください。
 .Pp
 IDE ハードドライブの実験的な新機能として、
-hw.ata.tags と呼ばれるものがあり (これもブートローダで設定します)、
+.Va hw.ata.tags
+と呼ばれるものがあり (これもブートローダで設定します)、
 ライトキャッシュを安全にオンにすることができます。
 これは SCSI のタギング機能を IDE ドライブに持ち込んだものです。
 これを書いている時点では、IBM DPLA と DTLA ドライブだけがこの機能を
-サポートしています。警告! これらのドライブは品質管理に問題
+サポートしています。
+警告! これらのドライブは品質管理に問題
 があるようなので、私は現時点ではこれらの製品を買うことはおすすめしません。
 性能が必要なら SCSI を使いましょう。
 .Sh CPU、メモリ、ディスク、ネットワーク
@@ -558,7 +662,8 @@ hw.ata.tags
 CPU を使い果たしている (アイドル時間が常に 0%) ならば、CPU を
 アップグレードしたり SMP マザーボード (CPU を複数にする) に移行
 したり、あるいは負荷の原因となっているプログラムを見直して最適化する
-ことを考える必要があるでしょう。スワップに対して大量のページングがあるなら
+ことを考える必要があるでしょう。
+スワップに対して大量のページングがあるなら
 メモリをもっと増やす必要があるでしょう。
 ディスク性能が飽和している場合、CPU アイドル時間は高く、全般的に
 ディスクが飽和状態になっています。
@@ -577,7 +682,7 @@ SCSI
 ハブではなくスイッチを使っているか、ということです。
 特に最近はスイッチは安くなっています。
 ハブが高負荷になると、コリジョンバックオフのために深刻な問題が発生します。
-また、一台のホストに問題があると、LAN 全体の性能を大幅に低下させます。
+また、1 台のホストに問題があると、LAN 全体の性能を大幅に低下させます。
 次に、できるだけネットワーク経路を最適化することです。
 例えば
 .Xr firewall 7
@@ -586,31 +691,35 @@ SCSI
 必要に応じて 10BaseT ではなく 100Base-T を、あるいは 100BaseT ではなく
 1000BaseT を使いましょう。
 最大のボトルネックは WAN 回線です (モデム、T1、DSL 等)。
-回線を増強できないのであれば、ipfw の
-.Sy DUMMYNET
+回線を増強できないのであれば、
+.Xr dummynet 4
 機能を使ってピーク削減やその他のトラフィックシェイピングを
 行い過負荷のサービス (web サービス等) が他のサービス (電子メール等)
 に影響を与えるのを防いでください。逆もまた同様です。
 これは、家庭環境において、外部に公開しているサービス
 (web サービスや電子メール) よりも
-インタラクティブなトラフィック (ブラウザや ssh ログイン) を
+インタラクティブなトラフィック (ブラウザや
+.Xr ssh 1
+ログイン) を
 優先するために使うことができるでしょう。
 .Sh 関連項目
 .Xr netstat 1 ,
 .Xr systat 1 ,
 .Xr ata 4 ,
-.Xr ccd 4 ,
+.Xr dummynet 4 ,
 .Xr login.conf 5 ,
 .Xr firewall 7 ,
 .Xr hier 7 ,
 .Xr ports 7 ,
 .Xr boot 8 ,
+.Xr ccdconfig 8 ,
 .Xr config 8 ,
 .Xr disklabel 8 ,
 .Xr fsck 8 ,
 .Xr ifconfig 8 ,
 .Xr ipfw 8 ,
 .Xr loader 8 ,
+.Xr mount 8 ,
 .Xr newfs 8 ,
 .Xr route 8 ,
 .Xr sysctl 8 ,
@@ -622,4 +731,4 @@ SCSI
 .An Matthew Dillon
 によって書かれました。最初に現れたのは
 .Fx 4.3
-で、2001 年 5 月のことです。
+で、2001 年 5 月のことです。