diff --git a/ja_JP.eucJP/man/man7/tuning.7 b/ja_JP.eucJP/man/man7/tuning.7
index a56a4a6a0f..4293e6ef16 100644
--- a/ja_JP.eucJP/man/man7/tuning.7
+++ b/ja_JP.eucJP/man/man7/tuning.7
@@ -1,625 +1,734 @@
 .\" Copyright (c) 2001, Matthew Dillon.  Terms and conditions are those of
 .\" 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
 .Dt TUNING 7
 .Os
 .Sh 名称
 .Nm tuning
 .Nd FreeBSD における性能チューニング
 .Sh システム設定 - disklabel, newfs, tunefs, スワップ
 .Xr disklabel 8
 を使ってハードディスク上にファイルシステムをレイアウトする場合、
 ディスクの内周トラックよりも外周トラックのほうがずっと速くデータを
 転送できることを意識することが重要です。この利点を生かすには、
 小さいファイルシステムやスワップを外周トラックに近いほうから
 詰めていくべきです。より大きいファイルシステムは内周へ近いほうへ詰めていき、
 最も大きいファイルシステムを最後にします。
 後でマシンを増強した時にシステム標準のファイルシステムの大きさを
 変更しなくて済むような大きさに決めることが重要です。
 私は大抵、順番にルートパーティションに 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 がそれほど多くない場合は、一般にもっとスワップが必要でしょう。
 256M より小さいスワップを設定するのは奨められません。スワップ
 パーティションの大きさを決めるときは将来のメモリ増設のことを
 考えておくべきです。
 カーネルの VM ページングアルゴリズムは、スワップの大きさが
 メインメモリの少なくとも 2 倍ある場合に最高の
 性能が出るようにチューンされています。スワップを小さくしすぎると、
 VM ページ走査コードが効率的に動かなくなります。
 メモリをさらに追加した時も同様です。
 最後に、複数の SCSI ディスク (あるいは異なるコントローラ上にある
 複数の IDE ディスク) を備えた大規模なシステムにおいては、
 それぞれのドライブ (最大 4 ドライブ) にスワップを置くことを強く推奨します。
 各ドライブ上のスワップパーティションがほぼ同じ大きさになる
 ようにしてください。
 カーネルは任意の大きさを扱うことができますが、内部のデータ構造は
 最大のスワップパーティションのものの 4 倍の大きさになってしまいます。
 スワップパーティションをだいたい同じ大きさにすることで、
 カーネルは最適な方法でスワップ空間を N 台のディスクに対し
 ストライピングします。
 少々のやりすぎを気にする必要はありません。スワップ空間は
 .Ux
 が優雅に動作するためのものです。
 普段それほどスワップを使っていなくても、
 プログラムの暴走で強制的にリブートしてしまう前に、
 回復作業をするための時間稼ぎになります。
 .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
+に対しては大量の読み込みや書き込みがあるでしょう。
 システムをうまく分割することで、書き込みが多いパーティションの破壊に
 よる被害が、ほとんど読み込みのみのパーティションに及ばないようします。
 加えて、書き込みが多いパーティションをディスクの端
 (すなわちパーティションテーブルにおいて、
 本当に大きなパーティションの後ろではなく、前の方)
 の方に置くことで、そのパーティションについて性能が向上します。
 より大きなパーティションについても入出力性能が必要なのも確かですが、
-/var をディスクの端に置くと大きな改善が可能であるのに対し、
+.Pa /var
+をディスクの端に置くと大きな改善が可能であるのに対し、
 巨大なパーティションをディスクの端に置いてもそれほど性能の
 改善にはつながりません。
-最後は安全性に関わることです。小さく、簡潔な、本質的に読み取りのみの
+最後は安全性に関わることです。
+小さく、簡潔な、本質的に読み込みのみの
 ルートパーティションとすることで、クラッシュを生き延びるチャンスを
 大きくすることができます。
 .Pp
 システムを正しく分割することで、
 .Xr newfs 8
 や
 .Xr tunefs 8
 に与えるパラメータをチューンすることも可能になります。
 .Fn newfs
 のチューニングにはさらに経験が必要ですが、かなりの性能改善につながります。
 比較的安全にチューンできる 3 つのパラメータがあります:
 .Em blocksize ,
 .Em bytes/inode ,
 .Em cylinders/group
 です。
 .Pp
 .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
 大きなパーティションに、データベースファイルのような
 少数の大きなファイルを置くのであれば、
 .Em bytes/inode
 の比率を増やすことができます。これは、そのパーティションの
 i ノードの数 (ファイルやディレクトリの最大の数) を減らします。
 i ノードの数を減らすことで、クラッシュ後の
 .Xr fsck 8
 による修復時間を大幅に減らすことができます。
 本当にこのパーティションに大きなファイルを置くのでない限り、
 このオプションを使わないでください。
 空き領域が大量にあるのにファイルを収容できなくなるかもしれません。
 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
 はファイルシステムをさらにチューンするのに使えます。
 このコマンドは、シングルユーザモードで実行することができ、
 ファイルシステムの再フォーマットは不要です。
 しかし、おそらく最も誤って使用されているプログラムでしょう。
 多くの人はファイルシステムの利用可能な空き領域を増やそうとして、
 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 はメタデータの性能、
 主にファイルの作成と削除の性能を劇的に改善します。
 全てのファイルシステムで softupdates を有効にすることを推奨します。
 softupdates に関して、2 つの欠点を意識すべきです。
 1 つめは、softupdates はクラッシュ時における
 ファイルシステムの一貫性は保証しますが、
 物理ディスクの更新が何秒か (1 分になることもあります!)
 遅れる可能性が高いことです。
 クラッシュした場合、より多くの成果が消えてしまうかもしれません。
 2 つめは、softupdates はファイルシステムブロックを解放するのを遅らせる
 ということです。
 あるファイルシステム (例えばルートファイルシステム) が満杯近くの時に
 それに対する大規模な更新、たとえば
-.Em make installworld
+.Dq Li "make installworld"
 をすると、空き領域を使い果たして更新が失敗してしまうことがあります。
 .Pp
-マウント実行時のいくつかのオプションはファイルシステムを
-チューンするのに役立ちます。
+.Xr mount 8
+実行時のいくつかのオプションはファイルシステムをチューンするのに役立ちます。
 最も明らかで、しかも最も危険なのは
-.Em async
-です。これは決して使わないでください。大変危険です。
-比較的危険度が低く、より役に立つマウントオプションは
-.Em noatime
+.Cm async
+です。
+これは決して使わないでください。
+大変危険です。
+比較的危険度が低く、より役に立つ
+.Xr mount 8
+のオプションは
+.Cm noatime
 です。
-通常 UNIX ファイルシステムは、ファイルやディレクトリにアクセスが
+通常
+.Ux
+ファイルシステムは、ファイルやディレクトリにアクセスが
 あった場合は常に、その最終アクセス時刻を更新します。
-FreeBSD では、この動作は遅延書き込みで行なわれ、
+.Fx
+では、この動作は遅延書き込みで行なわれ、
 通常は大した負荷にはなりません。
 しかし、大量のファイルが連続してアクセスされた場合、
 バッファキャッシュがアクセス時刻の更新で汚染され
 大きな負荷となります。
 例えば、高負荷の web サイトや大量の読者を抱えるニューズサーバ
-では、このマウントオプションで大きなパーティションにおける
+では、この
+.Xr mount 8
+のオプションで大きなパーティションにおける
 アクセス時刻の更新を停止することが考えられます。
 根拠もなく、すべての場所でアクセス時刻の更新を停止しないでください。
-例えば / や /usr のようなほとんど読み込みのみの
-パーティションはオンにしたままにすることができるでしょう
-(特に / についてはいくつかのシステムユーティリティが
-アクセス時刻フィールドをリポートのために利用します)。
+例えば、
+.Pa /var
+ファイルシステムは、慣習的にメールボックスを保持し、
+新規メールのメールボックス中の有無判定に atime (および mtime) が使用されます。
+読み込み専用パーティション、
+.Pa /
+や
+.Pa /usr
+では、atime をオンにしておいた方が良いでしょう。
+システムユーティリティには、atime フィールドを使用するものがあるので、
+.Pa /
+では特に有用です。
 .Sh ディスクのストライピング
 大きなシステムでは、いくつかのドライブのパーティションを互いに
 ストライピングして、全体として巨大なパーティションを作ることもあります。
 ストライピングは、入出力操作を複数のディスクに振り分けることで
 ファイルシステムの性能を向上させることができます。
 .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 の累乗の境界で格納する傾向にあり、
 大抵はシークを増やすのではなく減らしたいでしょう。
 これは、1152 セクタといったような、
 シーケンシャルな I/O が両方のディスクをシークしないように、
 かつメタデータが単一のディスクに集中するのではなく両方に分散するような、
 中心を外れた (off-centered) 大きな
 ストライプサイズにしたい、ということを意味します。
 本当に性能が必要なら、
 .Fx
 がサポートする本物のハードウェア RAID コントローラを
 使うことを勧めます。
 .Sh sysctl によるチューニング
 システムには数百の
 .Xr sysctl 8
 変数が存在します。
 そのなかには、チューニングの候補のように見えますが本当は
 そうでないものも多く含まれます。この文書では
 システムに最も大きな影響を与えるものだけを扱います。
 .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) 任意個のプロセス間で大量の共有メモリを
 マッピングしている、のいずれかの場合に効果があります。
 この機能は、共有メモリをスワップ不可にすることで、
 共有メモリをコアに結び付ける時に生じる、
 カーネルにおける内部のメモリ管理によるページ追跡
 オーバヘッドをかなり減らします。
 .Pp
-.Em vfs.vmiodirenable
-は、デフォルトは 0 (オフ) であり (しかし近いうちにデフォルトが 1 に
+.Va vfs.vmiodirenable
+sysctl は、デフォルトは 0 (オフ) であり (しかし近いうちにデフォルトが 1 に
 なるでしょう)、0 (オフ) または 1 (オン) にセットすることができます。
 このパラメータは、ディレクトリがシステムによってどのように
 キャッシュされるかを制御します。
 ほとんどのディレクトリは小さく、
 ファイルシステムにおいては単一フラグメント (典型的には 1K)
 であり、バッファキャッシュではさらに小さくなっています
 (典型的には 512 バイト)。
 しかし、デフォルトモードで動作している時は、
 大量のメモリを搭載していても
 バッファキャッシュは固定数のディレクトリしかキャッシュしません。
 この sysctl をオンにすると、バッファキャッシュが
 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 です。
+このデフォルトを増やすことで
 各コネクションについてカーネルメモリがさらに消費されますが、
 帯域幅の利用率が改善することがあります。
 同時に数百とか数千のコネクションを扱っている場合、
 このデフォルトを増やすことは推奨されません。
 失速してしまったコネクションが蓄積することで、
 システムがメモリをすぐに使い果たしてしまうからです。
 しかし、少ない数のコネクションについて広い帯域幅が必要ならば、
 特にギガビットイーサネットの場合、このデフォルトを大幅に増やす
 ことができます。
 入力データと出力データのバッファを個別に調整することができます。
 たとえば、主に web サービスをしているマシンならば recvspace を
 減らすことで、それほど大量にカーネルメモリを消費せずに
 sendspace を増やすことができます。
 経路表 (
 .Xr route 8
 を参照 ) に対しては、経路に特化した送受信バッファを導入することが
 できるということに注意してください。
+.Pp
 付加的な管理ツールとして、ファイアウォールルールにおいて
 パイプ (pipe) を使うことで (
 .Xr ipfw 8
 を参照)、特定の IP ブロックやポートへ行く、あるいはそこから
 来る帯域幅を制限することができます。
 例えば T1 回線を持っている場合、
 web トラフィックは回線の 70% に制限し、残りをメールと
 インタラクティブな用途に使いたいと思うでしょう。
 通常高い負荷の web サーバは、ネットワーク回線が
 使い切られていても、他のサービスに大きな遅延を与えることは
 ありませんが、制限をかけることは物事を円滑にし長期的な安定につながります。
 また、多くの人が、帯域超過による課金をされないように
 意図的な帯域制限をかけています。
 .Pp
-.Em net.inet.tcp.rfc1323
+.Va net.inet.tcp.rfc1323
 sysctl で制御可能な TCP プロトコルのウィンドウスケーリング拡張を
 両方のホストがサポートしない限り、
 TCP の送信あるいは受信バッファサイズを 65535 を超えて指定しても
 ほとんど性能の改善はありません。
 ある種のネットワークリンクから良い性能を引き出すために、
 これらの拡張を有効にし、
 TCP バッファサイズを 65536 より大きく設定すべきです。
 特に、ギガビット WAN リンクや、高レイテンシの衛星リンクが対象となります。
+RFC1323 サポートは、デフォルトでオンになっています。
 .Pp
-.Em net.inet.tcp.always_keepalive
-はオン (1 にセット) にしてそのままにしておいてください。
+.Va net.inet.tcp.always_keepalive
+sysctl はオン (1 にセット) にしてそのままにしておいてください。
 デフォルトは大抵オフです。少量のネットワーク帯域を消費しますが、
 偶然死んでしまった TCP コネクションを認識し除去することを保証します。
 死んでしまった 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 でスワップアウトヒステリシス (アイドルの秒数) を調整することで
 アイドルプロセスに与えられているページの優先度を通常のページアウト
 アルゴリズムよりも速やかに下げることができます。
 これはページアウトデーモンを手助けします。必要がないかぎり、
 このオプションはオンにしないでください。
 これによって起こるトレードオフは、本質的に、
 スワップとディスク帯域幅をより多く消費してメモリのプリページングを
 より早いうちに行うことだからです。
 小さなシステムではこのオプションは有害となるでしょうが、
 すでにある程度ページングが発生している大きなシステムでは、
 このオプションによって、全体のプロセスがより容易にメモリへ入ったり
 出たりするようにできるでしょう。
-.Sh ブート時の SYSCTL チューニング
-sysctl によっては、
+.Sh ローダのチューナブル
+システムの動作の一部は、
 そのためのメモリ割り当てをブート処理の初期に行う必要があるために、
-実行時にチューニング不可のものがあります。
-これらの sysctl を変更するには、これらの値を
+実行時には調整不可能です。
+ローダのチューナブルを変更するには、これらの値を
 .Xr loader.conf 5
 に設定し、システムをリブートする必要があります。
 .Pp
-.Em kern.maxusers
+.Va kern.maxusers
 sysctl のデフォルトは驚くほど小さな値です。
 最近のマシンでは、おそらく 64 か 128 あるいは 256 に
 増やしたいと思うでしょう。莫大な数のファイル記述子が必要でない限り、
 256 を超えるのは推奨されません。
 ネットワークバッファにも影響を与えますが、別のカーネルオプションで
 制御できます。ネットワーク mbuf をさらに得るためだけに maxusers を
 増やさないでください。
-FreeBSD 4.4 より古いシステムでは、この sysctl がありませんので、
-代りにカーネル設定オプションの maxusers を設定する必要があります。
+.Fx 4.4
+より古いシステムでは、このローダのチューナブルがありませんので、
+代りにカーネルの
+.Xr config 8
+オプションの
+.Cd maxusers
+を設定する必要があります。
 .Pp
-.Em NMBCLUSTERS
+.Va kern.ipc.nmbclusters
 を調整することで、システムが割り当てようとしている
 ネットワーク mbuf の数を増やすことができます。
 それぞれのクラスタは約 2K のメモリに相当するので、
 1024 は 2M のカーネルメモリをネットワークバッファに
 予約することを示します。
 簡単な計算でどれだけ必要なのかがわかります。
 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 としてさえ認識されるクローンが存在し、
 その場合はこれらのオプションがないと起動することができません。
 もし動いたらすごいことです !
 オペレーティングシステムは、MMU や
 タスク切り替え、タイムベース、デバイス操作に至る、より高度な機能を
 より利用することができるようになります。
 加えてより高度な CPU は、カーネルがカーネル自身をメモリにマップする
 4MB の MMU ページをサポートします。これは高いシステムコール負荷の
 下での効率を上げます。
 .Sh IDE ライトキャッシュ
 .Fx 4.3
 では IDE のライトキャッシュがオフになりました。これは
 IDE ディスクへの書き込み帯域幅を減らしてしまうことになりますが、
 ハードドライブベンダに起因するデータの一貫性に関する重大な問題のために、
 必要なことだと考えられました。
 基本的には、書き込み完了時期について IDE ドライブが嘘をつくという問題です。
 IDE ライトキャッシュがオンであると、
 IDE ハードドライブはデータを順番に書きこまないばかりか、
 ディスクの負荷が高い時にはいくつかのブロックの書き込みを
 無期限に延期してしまいます。
 クラッシュや電源故障の場合、ファイルシステムの重大な破壊を
 もたらします。したがって私たちはデフォルトを安全側に変更しました。
 残念ながら、これは大変な性能の低下をもたらし、私たちはあきらめて
 このリリース後にオンに戻しました。
-.Em hw.ata.wc
+.Va hw.ata.wc
 sysctl 変数を見て、デフォルトをチェックしてみるべきです。
 もし IDE ライトキャッシュがオフになっていたら、
-.Em hw.ata.wc
+.Va hw.ata.wc
 カーネル変数を 1 に戻すことでオンに戻すことができます。
 これはブート時にブートローダから行わなければなりません。
 カーネルがブートした後に行っても効果はありません。
 .Xr ata 4
 と
 .Xr loader 8
 を参照してください。
 .Pp
 IDE ハードドライブの実験的な新機能として、
-hw.ata.tags と呼ばれるものがあり (これもブートローダで設定します)、
+.Va hw.ata.tags
+と呼ばれるものがあり (これもブートローダで設定します)、
 ライトキャッシュを安全にオンにすることができます。
 これは SCSI のタギング機能を IDE ドライブに持ち込んだものです。
 これを書いている時点では、IBM DPLA と DTLA ドライブだけがこの機能を
-サポートしています。警告! これらのドライブは品質管理に問題
+サポートしています。
+警告! これらのドライブは品質管理に問題
 があるようなので、私は現時点ではこれらの製品を買うことはおすすめしません。
 性能が必要なら SCSI を使いましょう。
 .Sh CPU、メモリ、ディスク、ネットワーク
 負荷が上がるとシステムのどの部分がボトルネックになりはじめているかによって、
 チューニングの種類が違ってきます。
 CPU を使い果たしている (アイドル時間が常に 0%) ならば、CPU を
 アップグレードしたり SMP マザーボード (CPU を複数にする) に移行
 したり、あるいは負荷の原因となっているプログラムを見直して最適化する
-ことを考える必要があるでしょう。スワップに対して大量のページングがあるなら
+ことを考える必要があるでしょう。
+スワップに対して大量のページングがあるなら
 メモリをもっと増やす必要があるでしょう。
 ディスク性能が飽和している場合、CPU アイドル時間は高く、全般的に
 ディスクが飽和状態になっています。
 .Xr systat 1
 でこれらをモニタすることができます。
 ディスク性能の飽和を解決するにはいろいろな方法があります:
 キャッシュのためのメモリを増やす、ディスクをミラーリングする、
 複数のマシンに操作を分散させる等です。
 ディスク性能が問題で、IDE ドライブを使っている場合、
 SCSI に切り替えることでずいぶんよくなります。
 生のシーケンシャルな帯域幅については、最近の IDE ドライブは SCSI のものに
 匹敵していますが、調べると大抵 SCSI ドライブが勝っています。
 .Pp
 最後に、ネットワーク性能を使い果たしているかもしれません。
 ネットワーク性能を改善するために最初に確認すべきことは、
 ハブではなくスイッチを使っているか、ということです。
 特に最近はスイッチは安くなっています。
 ハブが高負荷になると、コリジョンバックオフのために深刻な問題が発生します。
-また、一台のホストに問題があると、LAN 全体の性能を大幅に低下させます。
+また、1 台のホストに問題があると、LAN 全体の性能を大幅に低下させます。
 次に、できるだけネットワーク経路を最適化することです。
 例えば
 .Xr firewall 7
 で説明した内部ホストを守るファイアウォールでは、
 外部から見えるホストはファイアウォールを通さないトポロジです。
 必要に応じて 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 ,
 .Xr tunefs 8 ,
 .Xr vinum 8
 .Sh 歴史
 .Nm
 マニュアルページは、もともと
 .An Matthew Dillon
 によって書かれました。最初に現れたのは
 .Fx 4.3
-で、2001 年 5 月のことです。
\ No newline at end of file
+で、2001 年 5 月のことです。