diff --git a/ja_JP.eucJP/man/man7/Makefile b/ja_JP.eucJP/man/man7/Makefile
index b01665511f..3532242677 100644
--- a/ja_JP.eucJP/man/man7/Makefile
+++ b/ja_JP.eucJP/man/man7/Makefile
@@ -1,37 +1,38 @@
 MAN7 =	ascii.7\
 	clocks.7\
 	environ.7\
 	groff.7\
 	groff_char.7\
 	groff_man.7\
 	groff_mdoc.7\
 	groff_me.7\
 	groff_mm.7\
 	groff_mmse.7\
 	groff_ms.7\
 	groff_mwww.7\
 	hier.7\
 	hostname.7\
 	intro.7\
 	mailaddr.7\
 	mmroff.7\
 	operator.7\
 	ports.7\
 	re_format.7\
 	roff.7\
 	security.7\
 	style.perl.7\
 	symlink.7\
-	term.7
+	term.7\
+	tuning.7
 
 MLINKS=groff_man.7 man.7
 MLINKS+=groff_mdoc.7 mdoc.7
 MLINKS+=groff_mdoc.7 mdoc.samples.7
 MLINKS=	groff_me.7 me.7
 MLINKS+=groff_mm.7 mm.7
 MLINKS+=groff_mmse.7 mmse.7
 MLINKS+=groff_ms.7 ms.7
 MLINKS+=groff_mwww.7 mwww.7
 MLINKS+=intro.7 miscellaneous.7
 
 .include "bsd.prog.mk"
diff --git a/ja_JP.eucJP/man/man7/tuning.7 b/ja_JP.eucJP/man/man7/tuning.7
new file mode 100644
index 0000000000..e26d216f77
--- /dev/null
+++ b/ja_JP.eucJP/man/man7/tuning.7
@@ -0,0 +1,623 @@
+.\" 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.4 2001/07/10 14:10:21 sheldonh Exp %
+.\"
+.\" $FreeBSD$
+.Dd May 25, 2001
+.Dt TUNING 7
+.Os FreeBSD
+.Sh 名称
+.Nm tuning
+.Nd FreeBSD における性能チューニング
+.Sh システム設定 - disklabel, newfs, tunefs, スワップ
+.Pp
+.Xr disklabel 8
+を使ってハードディスク上にファイルシステムをレイアウトする場合、
+ディスクの内周トラックよりも外周トラックのほうがずっと速くデータを
+転送できることを意識することが重要です。この利点を生かすには、
+小さいファイルシステムやスワップを外周トラックに近いほうから
+詰めていくべきです。より大きいファイルシステムは内周へ近いほうへ詰めていき、
+最も大きいファイルシステムを最後にします。
+後でマシンを増強した時にシステム標準のファイルシステムの大きさを
+変更しなくて済むような大きさに決めることが重要です。
+私は大抵、順番にルートパーティションに 128M、スワップに 1G、
+/var に 128M、/var/tmp に 128M、/usr に 3G、
+そして残りを /home に割り当てます。
+.Pp
+典型的にはメインメモリの約 2 倍のスワップスペースを用意すべきです。
+RAM がそれほど多くない場合は、一般にもっとスワップが必要でしょう。
+256M より小さいスワップを設定するのは奨められません。スワップ
+パーティションの大きさを決めるときは将来のメモリ増設のことを
+考えておくべきです。
+カーネルの VM ページングアルゴリズムは、スワップの大きさが
+メインメモリの少なくとも 2 倍ある場合に最高の
+性能が出るようにチューンされています。スワップを小さくしすぎると、
+VM ページ走査コードが効率的に動かなくなります。
+メモリをさらに追加した時も同様です。
+最後に、複数の SCSI ディスク (あるいは異なるコントローラ上にある
+複数の IDE ディスク) を備えた大規模なシステムにおいては、
+それぞれのドライブ (最大 4 ドライブ) にスワップを置くことを強く推奨します。
+各ドライブ上のスワップパーティションがほぼ同じ大きさになる
+ようにしてください。
+カーネルは任意の大きさを扱うことができますが、内部のデータ構造は
+最大のスワップパーティションのものの 4 倍の大きさになってしまいます。
+スワップパーティションをだいたい同じ大きさにすることで、
+カーネルは最適な方法でスワップ空間を N 台のディスクに対し
+ストライピングします。
+少々のやりすぎを気にする必要はありません。スワップ空間は
+.Ux
+が優雅に動作するためのものです。
+普段それほどスワップを使っていなくても、
+プログラムの暴走で強制的にリブートしてしまう前に、
+回復作業をするための時間稼ぎになります。
+.Pp
+.Em /var
+パーティションをどれだけの大きさにするかは、そのマシンを
+何に使うかということに大きく依存します。
+このパーティションは主にメールボックスやプリントスプール、
+ログファイルの保存場所に使われます。
+.Em /var/log
+を別のパーティションにする人もいます (しかし、パーティション ID を
+消費しないほうがよい極端な場合は例外です)。
+メールサーバやプリントサーバ、あるいは
+訪問数が非常に多い Web サーバとしてマシンが動作するなら、
+極めて大きいパーティション―おそらく 1 ギガバイト以上―を
+作成することを考えるべきでしょう。
+ログファイルの保存に必要な大きさは、小さく見積もられがちです。
+.Pp
+.Em /var/tmp
+の大きさは、テンポラリファイルの類が
+どれだけ使われる必要があるかで決まります。
+最低でも 128M にすることを推奨します。
+sysinstall は /tmp ディレクトリを作成しますが、
+.Em /tmp
+は後で
+.Em /var/tmp
+へのソフトリンクにしておくのは大抵よい考えです。
+テンポラリファイル領域専用に一つのパーティションを
+割り当てることは重要で、2 つの理由があります:
+クラッシュ時のファイルシステムの破壊の可能性を
+減らすのと、[/var]/tmp を一杯にしてしまう
+ような暴走プロセスが、さらに重要なサブシステム
+(メールやログ等) に影響を与える可能性を減らすためです。
+[/var]/tmp が一杯になってしまうのはよくある問題です。
+.Pp
+かつては /tmp と /var/tmp の間には違いがありましたが、
+/var (と /var/tmp) の導入によってプログラマは大変混乱し、
+今日では両方がでたらめに使われています。つまり
+この二つは実際には区別することができません。
+したがって、一つのテンポラリディレクトリだけにしてしまうことは
+意味があります。
+どのように /tmp を扱ったとしても、
+それがルートパーティションにあるのは好ましくないですしょう。
+一杯になったり、クラッシュやリブートにより破壊される
+可能性があるからです。
+.Pp
+.Em /usr
+パーティションはシステムをサポートするために
+必要なファイルの大部分を持っており、そのサブディレクトリ
+.Em /usr/local
+は
+.Xr ports 7
+階層からインストールされるファイルの大部分が置かれます。
+ports をあまり使わず、システムのソース (/usr/src) を
+保持するつもりがなければ /usr は 1 ギガバイトで十分でしょう。
+しかし、大量の ports (特にウィンドウマネージャや
+Linux エミュレーションされるバイナリ) をインストールする場合は、
+少なくとも 2 ギガバイトを推奨します。さらに、システムのソースを
+保持するつもりであれば、3 ギガバイトを推奨します。
+このパーティションに対して必要な領域の大きさを過小評価
+しないでください。これは緩やかに成長し、驚かされることになります !
+.Pp
+.Em /home
+パーティションはユーザ固有のデータを保持するのに使われます。
+私は大抵ディスクの残りを使います。
+.Pp
+何故 パーティションを切るのでしょう ?
+一つの大きな
+.Em /
+パーティションを作るだけでいいのではないでしょうか ?
+そうすれば小さすぎないかどうか気にする必要はないのに !
+はい、その考えがよくないのは、いくつか理由があります。
+一つめは、それぞれのパーティションは運用上の性格が
+異なるのですが、それらを分離することでファイルシステムに対し
+その性格に適したチューンをすることが可能になるからです。
+例えばルートパーティションや /usr パーティションはほとんど
+読み込みであり、ほとんど書き込みがありません。一方で
+/var や /var/tmp に対しては大量の読み込みや書き込みがあるでしょう。
+システムをうまく分割することで、書き込みが多いパーティションの破壊に
+よる被害が、ほとんど読み込みのみのパーティションに及ばないようします。
+加えて、書き込みが多いパーティションをディスクの端
+(すなわちパーティションテーブルにおいて、
+本当に大きなパーティションの後ろではなく、前の方)
+の方に置くことで、そのパーティションについて性能が向上します。
+より大きなパーティションについても入出力性能が必要なのも確かですが、
+/var をディスクの端に置くと大きな改善が可能であるのに対し、
+巨大なパーティションをディスクの端に置いてもそれほど性能の
+改善にはつながりません。
+最後は安全性に関わることです。小さく、簡潔な、本質的に読み取りのみの
+root パーティションとすることで、クラッシュを生き延びるチャンスを
+大きくすることができます。
+.Pp
+システムを正しく分割することで、
+.Xr newfs 8
+や
+.Xr tunefs 8
+に与えるパラメータをチューンすることも可能になります。
+.Fn newfs
+のチューニングにはさらに経験が必要ですが、かなりの性能改善につながります。
+比較的安全にチューンできる 3 つのパラメータがあります:
+.Em blocksize ,
+.Em bytes/inode ,
+.Em cylinders/group
+です。
+.Pp
+.Fx
+は 8K または 16K のファイルシステムブロックサイズを使用した時に
+最高の性能が得られます。
+デフォルトは 8K です。大きなパーティションでは、
+16K ブロックサイズにするのも大抵よい考えです。
+これにはより大きいフラグメントサイズを指定する必要もあります。
+常にブロックサイズの 1/8 のフラグメントサイズにすることを推奨します
+(他のフラグメントサイズの割合ではあまりテストされていません)。
+この場合の
+.Fn newfs
+オプションは
+.Em newfs -f 2048 -b 16384 ...
+となるでしょう。
+さらに大きなブロックサイズはバッファキャッシュのフラグメントの原因
+となり、性能の低下につながります。
+.Pp
+大きなパーティションに、データベースファイルのような
+少数の大きなファイルを置くのであれば、
+.Em bytes/inode
+の比率を増やすことができます。これは、そのパーティションの
+i ノードの数 (ファイルやディレクトリの最大の数) を減らします。
+i ノードの数を減らすことで、クラッシュ後の
+.Xr fsck 8
+による修復時間を大幅に減らすことができます。
+本当にこのパーティションに大きなファイルを置くのでない限り、
+このオプションを使わないでください。
+空き領域が大量にあるのにファイルを収容できなくなるかもしれません。
+32768, 65536, あるいは 262144 bytes/inode とすることが推奨されます。
+もっと大きな値にすることができますが、fsck による修復時間を増やすだけでしょう。
+例えば、 
+.Em 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
+として
+.Em softupdates
+を有効にすることです
+(注意: 5.x では newfs に -U オプションを与えることで softupdates を有効に
+することができます)。
+Softupdates はメタデータの性能、
+主にファイルの作成と削除の性能を劇的に改善します。
+全てのファイルシステムで softupdates を有効にすることを推奨します。
+softupdates に関して、2 つの欠点を意識すべきです。
+1 つめは、softupdates はクラッシュ時における
+ファイルシステムの一貫性は保証しますが、
+それが物理ディスクを更新してから何秒か ( 1 分になることもあります! )
+経過した後となる可能性が高いことです。
+クラッシュした場合、より多くの成果が消えてしまうかもしれません。
+2 つめは、softupdates はファイルシステムブロックを解放するのを遅らせる
+ということです。
+あるファイルシステム (例えばルートファイルシステム) が満杯近くの時に
+それに対する大規模な更新、たとえば
+.Em make installworld
+をすると、空き領域を使い果たして更新が失敗してしまうことがあります。
+.Pp
+mount 実行時のいくつかのオプションはファイルシステムを
+チューンするのに役立ちます。
+最も明らかで、しかも最も危険なのは
+.Em async
+です。これは決して使わないでください。大変危険です。
+比較的危険度が低く、より役に立つマウントオプションは
+.Em noatime
+です。
+通常 UNIX ファイルシステムはファイルやディレクトリにアクセスが
+あった場合は常にその最終アクセス時刻を更新します。
+FreeBSD では、この動作は遅延書き込みで行なわれ、
+通常は大した負荷にはなりません。
+しかし、大量のファイルが連続してアクセスされた場合、
+バッファキャッシュがアクセス時刻の更新で汚染され
+大きな負荷となります。
+例えば、高負荷の web サイトや大量の読者を抱えるニューズサーバ
+では、このマウントオプションで大きなパーティションにおける
+アクセス時刻の更新を停止することが考えられます。
+根拠もなく、すべての場所でアクセス時刻の更新を停止しないでください。
+例えば / や /usr のようなほとんど読み込みのみの
+パーティションはオンにしたままにすることができるでしょう
+(特に / についてはいくつかのシステムユーティリティが
+アクセス時刻フィールドをリポートのために利用します)。
+.Sh ディスクのストライピング
+大きなシステムでは、いくつかのドライブのパーティションを互いに
+ストライピングして、全体として巨大なパーティションを作ることもあります。
+ストライピングは、入出力操作を複数のディスクに振り分けることで
+ファイルシステムの性能を向上させることができます。
+.Xr vinum 8
+および
+.Xr ccd 4
+ユーティリティは、シンプルなストラピングされたファイルシステムを
+作るのに使われます。
+一般に、ルートや /var/tmp のような小さなパーティション、
+あるいは /usr のような本質的に読み込みのみのパーティションを
+ストライピングしても時間の無駄にしかなりません。
+本当に入出力性能を必要とするパーティションのみをストライピングする
+べきです。典型的には /var, /home あるいはデータベースや Web ページを
+保持するカスタムパーティションです。
+適切なストライプサイズを選ぶことも重要です。
+ファイルシステムはメタデータを 2 の累乗の境界で格納する傾向にあり、
+大抵はシークを増やすのではなく減らしたいでしょう。
+これは、1152 セクタといったような、
+シーケンシャルな I/O が両方のディスクをシークしないように、
+かつメタデータが単一のディスクに集中するのではなく両方に分散するような、
+中心を外れた (off-centered) 大きな
+ストライプサイズにしたい、ということを意味します。
+本当に性能が必要なら、
+.Fx
+がサポートする本物のハードウェア RAID コントローラを
+使うことを勧めます。
+.Sh sysctl によるチューニング
+.Pp
+システムには数百の
+.Xr sysctl 8
+変数が存在します。
+そのなかには、チューニングの候補のように見えますが本当は
+そうでないものも多く含まれます。この文書では
+システムに最も大きな影響を与えるものだけを扱います。
+.Pp
+.Em kern.ipc.shm_use_phys
+は、デフォルトが 0 (オフ) であり、
+0 (オフ) または 1 (オン) にセットすることができます。
+このパラメータを 1 にセットすると、全ての SysV 共有メモリセグメントが
+ページング不可の物理メモリにマップされます。
+これは、(A) 大量 (数百) のプロセス間で少量の共有メモリを
+マッピングしているか、(B) 任意個のプロセス間で大量の共有メモリを
+マッピングしている、のいずれかの場合に効果があります。
+この機能は、共有メモリをスワップ不可にすることで、
+共有メモリをコアに結び付ける時に生じる、
+カーネルにおける内部のメモリ管理によるページ追跡
+オーバヘッドをかなり減らします。
+.Pp
+.Em vfs.vmiodirenable
+は、デフォルトは 0 (オフ) であり (しかし近いうちにデフォルトが 1 に
+なるでしょう)、0 (オフ) または 1 (オン) にセットすることができます。
+このパラメータは、ディレクトリがシステムによってどのように
+キャッシュされるかを制御します。
+ほとんどのディレクトリは小さく、
+ファイルシステムにおいては単一フラグメント (典型的には 1K)
+であり、バッファキャッシュではさらに小さくなっています
+(典型的には 512バイト)。
+しかし、デフォルトモードで動作している時は、
+大量のメモリを搭載していても
+バッファキャッシュは固定数のディレクトリしかキャッシュしません。
+この sysctl をオンにすると、バッファキャッシュが
+VM ページキャッシュを、ディレクトリをキャッシュするために使うことを可能に
+します。
+これによる利点は、全てのメモリがディレクトリを
+キャッシュするのに使えるようになるということです。
+欠点は、キャッシュに使われる最小のメモリの大きさが 512 バイトではなく
+物理ページサイズ (大抵は 4K) になることです。
+多数のファイルを操作するサービスを稼動しているなら、
+常にこのオプションをオンにすることを推奨します。
+そのようなサービスには、web キャッシュや、大規模なメールシステム、
+ニューズシステムなどが含まれます。このオプションは一般に
+メモリを消費しますが、性能を削減することはありません。
+ただし実験して調べてみるべきでしょう。
+.Pp
+バッファキャッシュと VM ページキャッシュに関連した、様々な sysctl が
+存在します。これらを闇雲に変更するのは推奨されません。
+.Fx 4.3
+について言えば、VM システムは自分自身のチューニングに関して大変よい
+仕事をしています。
+.Pp
+.Em net.inet.tcp.sendspace
+と
+.Em net.inet.tcp.recvspace
+は、ネットワークに関連するアプリケーションを
+稼動している場合は特に重要です。これは、TCP コネクションの
+送信および受信バッファ領域の大きさを調節します。
+デフォルトは 16K です。このデフォルトを増やすことで
+各コネクションについてカーネルメモリがさらに消費されますが、
+帯域幅の利用率が改善することがあります。
+同時に数百とか数千のコネクションを扱っている場合、
+このデフォルトを増やすことは推奨されません。
+失速してしまったコネクションが蓄積することで、
+システムがメモリをすぐに使い果たしてしまうからです。
+しかし、少ない数のコネクションについて広い帯域幅が必要ならば、
+特にギガビットイーサネットの場合、このデフォルトを大幅に増やす
+ことができます。
+入力データと出力データのバッファを個別に調整することができます。
+たとえば、主に web サービスをしているマシンならば recvspace を
+減らすことで、それほど大量にカーネルメモリを消費せずに
+sendspace を増やすことができます。
+経路表 (
+.Xr route 8
+を参照 ) に対しては、経路に特化した送受信バッファを導入することが
+できるということに注意してください。
+付加的な管理ツールとして、ファイアウォールルールにおいて
+パイプ (pipe) を使うことで (
+.Xr ipfw 8
+を参照 )、特定の IP ブロックやポートへ行く、あるいはそこから
+来る帯域幅を制限することができます。
+例えば T1 回線を持っている場合、
+web トラフィックは回線の 70% に制限し、残りをメールと
+インタラクティブな用途に使いたいと思うでしょう。
+通常高い負荷の web サーバは、ネットワーク回線が
+使い切られていても、他のサービスに大きな遅延を与えることは
+ありませんが、制限をかけることは物事を円滑にし長期的な安定につながります。
+また、多くの人が、帯域超過による課金をされないように
+意図的な帯域制限をかけています。
+.Pp
+TCP の送信あるいは受信バッファサイズを 65535 を超えて指定しても
+ほとんど性能の改善はありません。これは TCP プロトコル自身の制限です。
+この制限により、ある種のネットワーク回線 (特にギガビット WAN 回線や
+高遅延の衛星回線) で最高レベルの性能に達しないことがあります。
+そのような場合で、その性能が受け入れられるようなものなら、
+単純に TCP バッファサイズを 65535 にセットし固定することを推奨します。
+極端な場合は、
+.Em net.inet.tcp.rfc1323
+をオンにしてバッファサイズを 65535 より増やすことができます。
+このオプションは TCP プロトコルのウィンドウサイズ拡張を有効にします。
+どうしてもこれを使わなければならない場合以外は、使わないことを
+推奨します。インターネット上の多くのホストがこの拡張を扱うことができず、
+コネクションが停止してしまう原因になることもあります。
+.Pp
+.Em net.inet.tcp.always_keepalive
+はオン (1 にセット) にしてそのままにしておいてください。
+デフォルトは大抵オフです。少量のネットワーク帯域を消費しますが、
+偶然死んでしまった TCP コネクションを認識し除去することを保証します。
+死んでしまった TCP コネクションは、特にダイアルアップのユーザによりアクセス
+されるシステムで発生する問題です。
+ユーザは、しばしば正しくアクティブコネクションを閉じずにモデムを切断
+するからです。
+.Pp
+.Em kern.ipc.somaxconn
+は、新しい TCP コネクションを受け付けるための listen キューの
+サイズを制限します。高負荷の web サーバ環境では、
+デフォルト値の 128 は新しいコネクションを余裕をもって扱うには低すぎます。
+そのような環境では、この値を 1024 以上に増やすことが推奨されます。
+サービスデーモン (例えば sendmail や apache ) は自分自身の
+listen キューのサイズを制限しているかもしれませんが、設定ファイルで
+キューのサイズを増やすディレクティブを持つようになるでしょう。
+listen キューを大きくすることは、サービス拒否攻撃を防ぐのにも役立ちます。
+.Pp
+.Em kern.maxfiles
+は、システムがどれだけの数のファイルをオープンできるかを
+決めます。デフォルトは典型的には数千ですが、データベースや記述子を
+大量に使うデーモンを稼働している場合は 10000 や 20000 に引き上げる必要
+があるかもしれません。
+.Pp
+.Em vm.swap_idle_enabled
+は、多数のユーザがシステムに出入りして大量のアイドルプロセスが
+ある大きなマルチユーザシステムで便利です。
+そのようなシステムでは、フリーメモリの予約に対する継続した
+大きなプレッシャーを生成する傾向にあります。これをオンにして
+.Em vm.swap_idle_threshold1
+と
+.Em vm.swap_idle_threshold2
+でスワップアウトヒステリシス (アイドルの秒数) を調整することで
+アイドルプロセスに与えられているページの優先度を通常のページアウト
+アルゴリズムよりも速やかに下げることができます。
+これはページアウトデーモンを手助けします。必要がないかぎり、
+このオプションはオンにしないでください。
+これによって起こるトレードオフは、本質的に、
+スワップとディスク帯域幅をより多く消費してメモリのプリページングを
+より早いうちに行うことだからです。
+小さなシステムではこのオプションは有害となるでしょうが、
+すでにある程度ページングが発生している大きなシステムでは、
+このオプションによって、全体のプロセスがより容易にメモリへ入ったり
+出たりするようにできるでしょう。
+.Sh カーネル構成におけるチューニング
+.Pp
+大規模なシステムでは、いくつかのカーネルオプションを操作しなければ
+ならないかもしれません。これらのオプションを変更する場合、あなたは
+ソースから新しいカーネルをコンパイルできなければなりません。
+.Xr config 8
+マニュアルページやハンドブックがよい入門となるでしょう。
+あなただけのカスタムカーネルを作るときに一般に最初にすることは、
+使用しないドライバやサービスをすべて削ることです。
+.Em INET6
+や使わないドライバを削除することで、カーネルのサイズを時に
+1 メガバイト以上減らすことができ、アプリケーションにさらに
+メモリを与えることができます。
+.Pp
+.Em maxusers
+カーネルオプションのデフォルトは驚くほど小さな値です。
+最近のマシンでは、おそらく 64, 128, あるいは 256 に
+増やしたいと思うでしょう。莫大な数のファイル記述子が必要でない限り、
+256 を超えるのは推奨されません。
+ネットワークバッファにも影響を与えますが、別のカーネルオプションで
+制御できます。ネットワーク mbuf をさらに得るためだけに maxusers を
+増やさないでください。
+.Pp
+.Em NMBCLUSTERS
+を調整することで、システムが割り当てようとしている
+ネットワーク mbuf の数を増やすことができます。
+それぞれのクラスタは約 2K のメモリに相当するので、
+1024 は 2M のカーネルメモリをネットワークバッファに
+予約することを示します。
+簡単な計算でどれだけ必要なのかがわかります。
+web サーバが同時に最大 1000 本のコネクションを扱い、
+各コネクションが 16K の受信バッファと 16K の送信バッファを消費する場合、
+約 32MB に相当するネットワークバッファを扱う必要があります。
+経験から得た方法によると、2 倍するとよいとされています。
+つまり 32MBx2 = 64MB/2K = 32768 です。
+したがって、この場合は NMBCLUSTERS を32768 に設定します。
+中くらいの量のメモリが搭載されたマシンでは 1024 から 4096、
+さらに大量のメモリが搭載されているなら 4096 から 32768 の値を
+推奨します。
+大きい値を指定することは、意図的にそうしなければならない限り、
+ブート時にクラッシュを引き起こす可能性があります。
+.Xr netstat 1
+に -m オプションを与えることで、ネットワーククラスタの使用状況が分かります。
+.Pp
+ますます多くのプログラムが
+.Fn sendfile
+システムコールを使ってネットワークを通じてファイルを
+転送しています。
+.Em NSFBUFS
+カーネルパラメータは
+.Fn sendfile
+の実行時にファイルシステムバッファをどれだけの数だけ
+使えるかを制御します。通常このパラメータは 
+.Em maxusers
+に比例しているので、極端な場合を除いては
+このパラメータに手を出す必要はありません。
+.Pp
+.Em SCSI_DELAY
+と
+.Em IDE_DELAY
+は、システムの起動時間を減らすために使うことができます。
+このデフォルト値はかなり大きく、ブート処理の中で 15 秒以上を占めるでしょう。
+SCSI_DELAY を 5 秒に減らしても大抵はうまく動きます (特に最近のドライブでは)。
+IDE_DELAY を減らしてもうまくいきますが、少々慎重になる必要があります。
+.Pp
+.Em XXX_CPU
+オプションの多くはコメントアウトできます。
+そのカーネルを Pentium クラスの CPU だけで動かすなら、
+.Em I386_CPU
+と
+.Em I486_CPU
+は削除することができます。ただし、
+.Em 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
+sysctl 変数を見て、デフォルトをチェックしてみるべきです。
+もし IDE ライトキャッシュがオフになっていたら、
+.Em hw.ata.wc
+カーネル変数を 1 に戻すことでオンに戻すことができます。
+これはブート時にブートローダから行わなければなりません。
+カーネルがブートした後に行っても効果はありません。
+.Xr ata 4
+と
+.Xr loader 8
+を参照してください。
+.Pp
+IDE ハードドライブの実験的な新機能として、
+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 全体の性能を大幅に低下させます。
+次に、できるだけネットワーク経路を最適化することです。
+例えば
+.Xr firewall 7
+には、外部から見えるホストはファイアウォールを
+通ってルーティングされないようなトポロジを持った、
+内部ホストを守るファイアウォールが説明されています。
+必要に応じて 10BaseT ではなく 100Base-T を、あるいは 100BaseT ではなく
+1000BaseT を使いましょう。
+最大のボトルネックは WAN 回線です (モデム、T1、DSL 等)。
+回線を増強できないのであれば、ipfw の
+.Sy DUMMYNET
+機能を使ってピーク削減やその他のトラフィックシェイピングを
+行い過負荷のサービス (web サービス等) が他のサービス (電子メール等)
+に影響を与えるのを防いでください。逆もまた同様です。
+これは、家庭環境において、外部に公開しているサービス
+(web サービスや電子メール) よりも
+インタラクティブなトラフィック (ブラウザや ssh ログイン) を
+優先するために使うことができるでしょう。
+.Sh 関連項目
+.Pp
+.Xr netstat 1 ,
+.Xr systat 1 ,
+.Xr ata 4 ,
+.Xr ccd 4 ,
+.Xr login.conf 5 ,
+.Xr hier 7 ,
+.Xr firewall 7 ,
+.Xr ports 7 ,
+.Xr boot 8 ,
+.Xr config 8 ,
+.Xr disklabel 8 ,
+.Xr fsck 8 ,
+.Xr ifconfig 8 ,
+.Xr ipfw 8 ,
+.Xr loader 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 月のことです。