名称

tuning — FreeBSD の下での性能の調整

システム設定 - disklabel, newfs, tunefs, スワップ

スワップパーティションは、一般的に、4GB 未満の RAM があるシステムに対してメインメモリのほぼサイズの 2 倍であるか、またはより大きいなら、メインメモリとほぼ等しいサイズであるべきです。スワップパーティションをサイズを決めるとき、将来のメモリ拡張を頭に入れておいてください。スワップを小さくしすぎると、 VM ページ走査コードが効率的に動かなくなります。メモリをさらに追加した時も同様です。複数の SCSI ディスク (または、異なるコントローラで動作する複数の IDE ディスク) を備えた大規模なシステムにおいては、それぞれのドライブにスワップを設定してください。各ドライブ上のスワップパーティションがほぼ同じ大きさになるようにしてください。カーネルは任意の大きさを扱うことができますが、内部のデータ構造は、最大のスワップパーティションのものの 4 倍の大きさになってしまいます。スワップパーティションをだいたい同じ大きさにすることで、カーネルは最適な方法でスワップ空間を N 台のディスクに対しストライピングします。少々のやりすぎを気にする必要はありません。スワップ空間は、 UNIX が優雅に動作するためのものです。普段それほどスワップを使っていなくても、プログラムの暴走で強制的にリブートしてしまう前に、回復作業をするための時間稼ぎになります。

1 つの大きなパーティションを作成することは、よい考えではありません。 1 つめは、それぞれのパーティションは運用上の性格が異なるのですが、それらを分離することでファイルシステムに対しその性格に適した調整をすることが可能になるからです。例えば、ルートパーティションや /usr パーティションはほとんど読み込みであり、ほとんど書き込みがありません。一方で /var/tmp に対しては大量の読み込みや書き込みがあるでしょう。システムをうまく分割することで、書き込みが多いパーティションの破壊による被害が、ほとんど読み込みのみのパーティションに及ばないようします。

システムを正しく分割することで、 newfs(8) と tunefs(8) に与えるパラメータを調整することも可能になります。ただ 1 つの価値がある調整の tunefs(8) オプションは、“ tunefs -n enable /filesystem”で softupdates することです。大部分のファイルシステムで softupdates を有効にすることを推奨します。しかしながら、ファイルシステムで softupdates を使うかどうか判断する際に気をつけるべき 2 つの制限があります。 1 つめは、softupdates はクラッシュ時におけるファイルシステムの一貫性は保証しますが、未反映の物理ディスク書き込みより何秒か (1 分になることもあります!) おそらく遅れていることです。クラッシュした場合、より多くの成果が消えてしまうかもしれません。 2 つめは、softupdates はファイルシステムブロックを解放するのを遅らせるということです。あるファイルシステム (例えばルートファイルシステム) が満杯近くの時にそれに対する大規模な更新、たとえば“ make installworld”をすると、空き領域を使い果たして更新が失敗してしまうことがあります。そのため標準的なインストールではルートファイルシステムの softupdates を有効にしません。ルートファイルシステムは滅多に書き込まれませんので、性能上の損失はありません。

mount(8) 実行時のいくつかのオプションはファイルシステムを調整するのに役立ちます。最も明らかで、しかも最も危険なのは、 async です。それが通常のファイルシステムではるかに危険過ぎるので、 gjournal(8) に関連してこのオプションをのみを使用します。比較的危険度が低く、より役に立つ mount(8) のオプションは、 noatime です。通常 UNIX ファイルシステムは、ファイルやディレクトリにアクセスがあった場合は常に、その最終アクセス時刻を更新します。 FreeBSD では、この動作は遅延書き込みで行なわれ、通常は大した負荷にはなりません。しかし、大量のファイルが連続してアクセスされた場合、バッファキャッシュがアクセス時刻の更新で汚染され大きな負荷となります。例えば、高負荷の web サイトや大量の読者を抱えるニューズサーバでは、この mount(8) のオプションで大きなパーティションにおけるアクセス時刻の更新を停止することが考えられます。根拠もなく、すべての場所でアクセス時刻の更新を停止しないでください。例えば、 /var ファイルシステムは、慣習的にメールボックスを保持し、新規メールのメールボックス中の有無判定に atime (および mtime) が使用されます。読み込み専用パーティション、 / や /usr では、atime をオンにしておいた方が良いでしょう。システムユーティリティには、atime フィールドを使用するものがあるので、 / では特に有用です。

ディスクのストライピング

大きなシステムでは、いくつかのドライブのパーティションを互いにストライピングして、全体として巨大なパーティションを作ることもあります。ストライピングは、入出力操作を複数のディスクに振り分けることでファイルシステムの性能を向上させることができます。 gstripe(8), gvinum(8) と ccdconfig(8) ユーティリティは、シンプルなストライピングされたファイルシステムを作るのに使われます。一般に、ルートや /var/tmp のような小さなパーティション、あるいは /usr のような本質的に読み込みのみのパーティションをストライピングしても時間の無駄にしかなりません。本当に入出力性能を必要とするパーティションのみをストライピングするべきです。典型的には、 /var, /home あるいはデータベースや Web ページを保持するカスタムパーティションです。適切なストライプサイズを選ぶことも重要です。ファイルシステムはメタデータを 2 の累乗の境界で格納する傾向にあり、大抵はシークを増やすのではなく減らしたいでしょう。これは、1152 セクタといったような、シーケンシャルな I/O が両方のディスクをシークしないように、かつメタデータが単一のディスクに集中するのではなく両方に分散するような、中心を外れた (off-centered) 大きなストライプサイズにしたい、ということを意味します。本当に性能が必要なら、 FreeBSD がサポートする本物のハードウェア RAID コントローラを使うことを勧めます。

sysctl による調整

sysctl(8) 変数は、実行時に、システムの動作のモニタおよび制御を可能とします。 sysctl には、単にシステムの動作を報告するものもありますが、システムの動作を変更するものもあります。ブート時に rc.conf(5) を使用して設定可能なものもありますが、大部分は、 sysctl.conf(5) で設定可能です。システムには数百の sysctl 変数があります。そのなかには、調整の候補のように見えますが本当は、そうでないものも多く含まれます。この文書では、システムに最も大きな影響を与えるものだけを扱います。

vm.overcommit sysctl は、vm サブシステムの振る舞いを過度に定義します。仮想メモリシステムは、常にスワップ空間の予約、システムとユーザごとの合計の両方を計算します。対応する値は、スワップのために利用可能な合計バイトを与える、sysctl vm.swap_total とすべての現在割り付けられた匿名のメモリを裏打ちするために必要なバイトの数を与える vm.swap_reserved を通して利用可能です。

vm.overcommit sysctl のビット 0 を設定することによって、仮想メモリシステムは、 vm.swap_reserved が vm.swap_total を超えてメモリを割り付けるとき、プロセスに失敗を返します。 sysctl のビット 1 は、 RLIMIT_SWAP の制限を強制します ( getrlimit(2) 参照)。ルートは、この制限を免除されています。ビット 2 によって、(それぞれ、 vm.stats.vm.v_free_target と vm.stats.vm.v_wire_count sysctl で説明されている) 結びつけられていて、解放されている予約されてページを除いて、割り付け可能な物理的なメモリの大部分をカウントすることができます。

kern.ipc.maxpipekva ローダ調整変数は、パイプバッファのマッピングに割り付けられたカーネルアドレス空間の総量に関する強固な制限を設定するために使用されます。マッピングの使用によって、カーネルは、マップされたバッファの内容を直接リーダ (reader) にコピーすることで、ライタ (writer) のアドレス空間からカーネルへのデータのコピーを排除することができます。 `25165824' のように、この値をより大きな設定に増加させると、パイプバッファをマップするための空間が、すぐに使い果たされるシステムにおいて性能が、向上するかもしれません。すぐに使い果たされることは、致命的ではありません。しかしながら、パイプは、二重コピーを使用するように後退 (fall back) するのみです。

kern.ipc.shm_use_phys sysctl は、デフォルトが 0 (オフ) であり、 0 (オフ) または 1 (オン) にセットすることができます。このパラメータを 1 にセットすると、全ての System V 共有メモリセグメントがページング不可の物理メモリにマップされます。これは、(A) 大量 (数百) のプロセス間で少量の共有メモリをマッピングしているか、(B) 任意個のプロセス間で大量の共有メモリをマッピングしている、のいずれかの場合に効果があります。この機能は、共有メモリをスワップ不可にすることで、共有メモリをコアに結び付ける時に生じる、カーネルにおける内部のメモリ管理によるページ追跡オーバヘッドをかなり減らします。

vfs.vmiodirenable sysctl は、1 (オン) がデフォルトです。このパラメータは、ディレクトリがシステムによってどのようにキャッシュされるかを制御します。ほとんどのディレクトリは、小さいですが、ファイルシステムで単一フラグメント (一般的に、2K) とさらに小さいバッファキャッシュ (一般的に、512 バイト) を使用します。しかし、デフォルトモードで動作している時は、大量のメモリを搭載していてもバッファキャッシュは固定数のディレクトリしかキャッシュしません。この sysctl をオンにすると、バッファキャッシュが VM ページキャッシュを、ディレクトリをキャッシュするために使うことを可能にします。これによる利点は、全てのメモリがディレクトリをキャッシュするのに使えるようになるということです。欠点は、キャッシュに使われる最小のメモリの大きさが 512 バイトではなく物理ページサイズ (大抵は、4K) になることです。メモリに制約があるシステムでは、このオプションをオフにすることを推奨します。一方、オンにすると、多数のファイルを操作するサービスの性能が向上します。そのようなサービスには、web キャッシュや、大規模なメールシステム、ニューズシステムなどが含まれます。このオプションは一般にメモリを消費しますが、性能を削減することはありません。ただし実験して調べてみるべきでしょう。

vfs.write_behind sysctl は、デフォルトで 1 (オン) です。これによって、ファイルシステムからメディアへの書き込みが、クラスタ分が集まった時に発行されるようになります。そのような状況は、典型的には、大きなシーケンシャルファイルへ書き込んでいる時に起こります。これは、I/O パフォーマンスに寄与しないであろう場合に、ダーティなバッファでバッファキャッシュが飽和するのを避けるというアイデアです。しかしながら、これによってプロセスが止まるかもしれないので、状況によっては、この機能を切りたいと望むかもしれません。

vfs.hirunningspace sysctl は、未完了の書き込み I/O が、任意の与えられる時刻に、システム全体のディスクコントローラへどのくらいキューに入れられるかを決定します。それは、UFS ファイルシステムによって使用されます。通常、自己調整されるデフォルトで十分ですが、最新式のコントローラと多くのディスクがあるマシンでは、コントローラのバッファとマッチするように調整されるかもしれません。この設定をコントローラのタグ付けされたキューのケーパビリティまたは最もよく動作する生産に使用される平均した IO サイズがあるドライブにマッチするように設定します (例えば: 16 MiB は、128 KiB の IO 要求で 128 個のタグを使用します)。値を大きくしすぎる (バッファキャッシュの書き込みの閾値を超えて) と、クラスタリングの効果が極端に悪くなる可能性があるので注意してください。この値を思いつきで大きくしてはいけません! また、書き込みのキューの値を大きくすると、同時に発生した読み込みの待ち時間が増えます。

vfs.read_max sysctl は、VFS 先読みを管理し、発見的なアルゴリズムが、読み込みが連続して発行されることを決定するなら、先行して読み込むためのブロックの数として伝達されます。それは、UFS、ext2fs と msdosfs ファイルシステムによって使用されます。 32 KiB のデフォルトの UFS ブロックサイズで、64 の設定は、最大 2 MiB を投機的に読む込むことができます。この設定は、特に、仮想マシンをエミュレートする環境などのように、これらの待ち時間が大きいところで、ディスク I/O 待ち時間を回避するために増加するかもしれません。 I/O ロードが、性能に悪影響を与える先読みのようなところ、またはシステムにメモリが実際に少ないところのような、特定の場合に調整を落されるされるかもしれません。

vfs.ncsizefactor sysctl は、VFS 名前キャッシュ (namecache) がどれくらい大きく成長するかを定義します。名前キャッシュの現在割り付けられたエントリの数は、 debug.numcache sysctl によって提供され、状態 debug.numcache < kern.maxvnodes * vfs.ncsizefactor は、守られます。

vfs.ncnegfactor sysctl は、負のエントリの VFS 名前キャッシュ (namecache) がいくつ作成できるかを定義します。現在割り付けられた負のエントリの数は、 debug.numneg sysctl によって提供され、状態 vfs.ncnegfactor * debug.numneg < debug.numcache は、守られます。

他にもバッファキャッシュと VM ページキャッシュに関連した、様々な sysctl が存在します。これらを変更することは推奨されません。 FreeBSD 4.3 について言えば、VM システムは自分自身の調整に関して大変良い仕事をしています。

net.inet.tcp.sendspace sysctl と net.inet.tcp.recvspace sysctl は、ネットワークに関連するアプリケーションを稼動している場合は特に重要です。これは、TCP コネクションの送信および受信バッファ領域の大きさを調節します。デフォルトでは、送信バッファは、32K で、受信バッファは、64K です。このデフォルトを増やすことで各コネクションについてカーネルメモリがさらに消費されますが、帯域幅の利用率が改善することがあります。同時に数百とか数千のコネクションを扱っている場合、このデフォルトを増やすことは推奨されません。失速してしまったコネクションが蓄積することで、システムがメモリをすぐに使い果たしてしまうからです。しかし、少ない数のコネクションについて広い帯域幅が必要ならば、特にギガビットイーサネットの場合、このデフォルトを大幅に増やすことができます。入力データと出力データのバッファを個別に調整することができます。たとえば、主に web サービスをしているマシンならば recvspace を減らすことで、それほど大量にカーネルメモリを消費せずに sendspace を増やすことができます。経路表 ( route(8) を参照 ) に対しては、経路に特化した送受信バッファを導入することができるということに注意してください。

付加的な管理ツールとして、ファイアウォールルールにおいてパイプ (pipe) を使うことで ( ipfw(8) を参照)、特定の IP ブロックやポートへ行く、あるいはそこから来る帯域幅を制限することができます。例えば T1 回線を持っている場合、 web トラフィックは回線の 70% に制限し、残りをメールとインタラクティブな用途に使いたいと思うでしょう。通常高い負荷の web サーバは、ネットワーク回線が使い切られていても、他のサービスに大きな遅延を与えることはありませんが、制限をかけることは物事を円滑にし長期的な安定につながります。また、多くの人が、帯域超過による課金をされないように意図的な帯域制限をかけています。

net.inet.tcp.rfc1323 sysctl で制御可能な TCP プロトコルのウィンドウスケーリング拡張を両方のホストがサポートしない限り、 TCP の送信あるいは受信バッファサイズを 65535 を超えて指定してもほとんど性能の改善はありません。ある種のネットワークリンクから良い性能を引き出すために、これらの拡張を有効にし、 TCP バッファサイズを 65536 より大きく設定すべきです。特に、ギガビット WAN リンクや、高レイテンシの衛星リンクが対象となります。 RFC1323 サポートは、デフォルトでオンになっています。

net.inet.tcp.always_keepalive sysctl は、TCP 実装が、コネクション上に断続的に“keepalives”を配送することで死んでしまった TCP コネクションの検出を試みるかどうかを決定します。デフォルトで、これはすべてのアプリケーションについて許可されています。この sysctl を 0 に設定すると、特に keepalives を要求したアプリケーションだけが検出機能を利用できます。大抵の環境において、死んでしまった TCP コネクションを失効にすることで、 TCP keepalives はシステム状態の管理を改善します。特にダイヤルアップのユーザにサービスを提供しているシステムでは、効果があります。なぜならユーザがネットワークとのコネクションを切る前にいつも個々の TCP コネクションを終了するとは限らないからです。しかしながら、ある種の環境では、一時的なネットワークの停止が誤ってセッションの死と判断されるかもしれません。結果として予期しない TCP コネクションの終了となります。その様な環境では、sysctl を 0 に設定することで、 TCP のセッション切断の発生を減らせるかもしれません。

net.inet.tcp.delayed_ack TCP 機能は大きく誤解されています。歴史的には、この機能は、転送されたデータに対する確認応答を、応答と共に返せるようにするためにデザインされました。例えば、リモートシェル上でキー入力しているとき、あなたが送信した文字への確認応答は、文字のエコーを表すデータと共に返されます。遅延確認応答をオフにすると、リモートサービスが丁度受け取ったデータをエコーする機会を得る前に、確認応答がそれだけを含むパケットで送られてしまうかもしれません。この同じ考え方がすべての対話的プロトコル (例 SMTP, WWW, POP3) にあてはまり、ネットワークの片一方を流れている小パケットを減らせるのです。 FreeBSD の遅延確認応答の実装も、TCP プロトコルの規則に従っています。すなわち、標準の 100ms のタイムアウトが経過しなくても、 2 パケットに 1 回は確認応答を行います。通常、遅延確認応答が行う最悪のことは、コネクションの破壊を少々遅らせること、スロースタート TCP コネクションの立ち上がりを少々遅らせることです。確かなことは分かりませんが、 SAMBA や SQUID といった package に関連する FAQ が遅延確認応答をオフにするように勧めているのは、スロースタートの問題に言及しているのでしょう。 FreeBSD では、スロースタートフライトサイズを net.inet.tcp.slowstart_flightsize sysctl で増やすことの方が、遅延確認応答をオフにするより、利益があるでしょう。

net.inet.ip.portrange.* sysctls は、自動的に TCP や UDP ソケットに結合されるポート番号の範囲を制御します。 3 種類の範囲があります。すなわち、下位の範囲、デフォルトの範囲、高位の範囲であり、 IP_PORTRANGE setsockopt(2) 呼び出しで選択可能です。ほとんどのネットワークプログラムが使用するのはデフォルトの範囲であり、 net.inet.ip.portrange.first と net.inet.ip.portrange.last で制御されます。それぞれ 49152 と 65535 がデフォルトです。範囲を限定されたポート範囲は外向きコネクションに使用され、ある条件下ではシステムがポートを使い尽してしまう場合があります。これは、高負荷のウェブプロキシを実行している場合に、よく発生します。通常のウェブサーバ等の主に内向きコネクションを扱うサーバや、メールリレー等の外向きコネクションが限られているサーバを実行している場合、これは問題とはなりません。ポートを使い果たしてしまう場合、控えめに net.inet.ip.portrange.first を減らしてみてください。 10000 から 30000 のポートの範囲が妥当でしょう。ポートの範囲を変えるときには、ファイアウォールの影響も考慮に入れるべきです。ファイアウォールによっては、広い範囲のポート (通常は下位のポート) を遮蔽し、システムが高位のポートを外向きコネクションに使用することを期待します。デフォルトでは、 net.inet.ip.portrange.last は、許容できる最大のポート番号に設定されます。

kern.ipc.somaxconn sysctl は、新しい TCP コネクションを受け付けるための listen キューのサイズを制限します。高負荷の web サーバ環境では、デフォルト値の 128 は新しいコネクションを余裕をもって扱うには低すぎます。そのような環境では、この値を 1024 以上に増やすことが推奨されます。サービスデーモン (例えば sendmail(8) や apache) は自分自身の listen キューのサイズを制限しているかもしれませんが、設定ファイルでキューのサイズを増やすディレクティブを持つようになるでしょう。 listen キューを大きくすることは、サービス拒否攻撃を防ぐのにも役立ちます。

kern.maxfiles sysctl は、システムがどれだけの数のファイルをオープンできるかを決めます。デフォルトは典型的には数千ですが、データベースや記述子を大量に使うデーモンを稼働している場合は、10000 や 20000 に引き上げる必要があるかもしれません。読み込み専用の kern.openfiles sysctl を検査することで、システム上で開かれているファイル数を判定可能です。

vm.swap_idle_enabled sysctl は、多数のユーザがシステムに出入りして大量のアイドルプロセスがある大きなマルチユーザシステムで便利です。そのようなシステムでは、フリーメモリの予約に対し、継続して重大な負担をかける傾向にあります。これをオンにして vm.swap_idle_threshold1 sysctl と vm.swap_idle_threshold2 sysctl でスワップアウトヒステリシス (アイドルの秒数) を調整することでアイドルプロセスに与えられているページの優先度を通常のページアウトアルゴリズムよりも速やかに下げることができます。これはページアウトデーモンを手助けします。必要がないかぎり、このオプションはオンにしないでください。これによって起こるトレードオフは、本質的に、スワップとディスク帯域幅をより多く消費してメモリのプリページングをより早いうちに行うことだからです。小さなシステムではこのオプションは有害となるでしょうが、すでにある程度ページングが発生している大きなシステムでは、このオプションによって、全体のプロセスがより容易にメモリへ入ったり出たりするようにできるでしょう。

ローダ調整変数 (チューナブル)

システムの動作の一部は、そのためのメモリ割り当てをブート処理の初期に行う必要があるために、実行時には調整不可能です。ローダ調整変数を変更するには、これらの値を loader.conf(5) に設定し、システムをリブートする必要があります。

kern.maxusers は、静的なシステムテーブルの大きさを制御します。これには、オープンファイルの最大数、ネットワークメモリ資源の大きさ等が含まれます。 FreeBSD 4.5 の時点では、 kern.maxusers は、ブート時に、システムで利用可能なメモリ量に応じて、大きさが自動的に決定されます。また、実行時に、読み込み専用の kern.maxusers sysctl 値を見て決定することも可能です。サイトによっては、 kern.maxusers を大きくしたり小さくしたりする必要があり、これはローダ調整変数で設定可能です。 64, 128, 256 は、変な値ではありません。膨大なファイル記述子が必要なのでない限り、 256 より大きくすることは勧められません。 kern.maxusers によってデフォルト値が決定される多くの調整可能な値は、本文書の別の場所に記述した方法で、個々にブート時または実行時に上書き可能です。 FreeBSD 4.4 より古いシステムでは、代わりにカーネルの config(8) オプションの maxusers を設定する必要があります。

kern.dfldsiz と kern.dflssiz 調整変数は、それぞれ、プロセスのデータとスタックサイズのデフォルトのソフト制限を設定します。プロセスは、 setrlimit(2) を呼び出すことによって、それらをハード制限まで増加させることができます。 kern.maxdsiz, kern.maxssiz と kern.maxtsiz は、それぞれ、プロセスのデータ、スタックとテキストサイズのハード制限を設定します。プロセスは、これらの制限を超えないかもしれません。 kern.sgrowsiz 調整変数は、プロセスが、より多くのスタックを割り付ける必要があるとき、スタックセグメントがどのくらい成長するかを制御します。

kern.ipc.nmbclusters を調整することで、システムが割り当てようとしているネットワーク mbuf の数を増やすことができます。それぞれのクラスタは約 2K のメモリに相当するので、 1024 は、2M のカーネルメモリをネットワークバッファに予約することを示します。簡単な計算でどれだけ必要なのかがわかります。 web サーバが同時に最大 1000 本のコネクションを扱い、各コネクションが 16K の受信バッファと 16K の送信バッファを消費する場合、約 32MB に相当するネットワークバッファを扱う必要があります。経験から得た方法によると、2 倍すると良いとされています。つまり 32MBx2 = 64MB/2K = 32768 です。したがって、この場合は、 kern.ipc.nmbclusters を 32768 に設定します。中くらいの量のメモリが搭載されたマシンでは、1024 から 4096、さらに大量のメモリが搭載されているなら 4096 から 32768 の値を推奨します。決して大きい値を指定すべきではありません。ブート時にクラッシュを引き起こす可能性があります。 netstat(1) に -m オプションを与えることで、ネットワーククラスタの使用状況が分かります。古い FreeBSD ではこのチューナブルを持ちませんので、代りにカーネルの config(8) オプションの NMBCLUSTERS を設定する必要があります。

ますます多くのプログラムが sendfile(2) システムコールを使ってネットワークを通じてファイルを転送しています。 kern.ipc.nsfbufs sysctl は、 sendfile(2) の実行時にファイルシステムバッファをどれだけの数だけ使えるかを制御します。通常このパラメータは、 kern.maxusers に比例しているので、極端な場合を除いては、このパラメータに手を出す必要はありません。詳細は、 sendfile(2) マニュアルページの 調整 セクションを参照してください。

カーネル構成における調整

大規模なシステムでは、いくつかのカーネルオプションを操作しなければならないかもしれません。これらのオプションを変更する場合、あなたは、ソースから新しいカーネルをコンパイルできなければなりません。 config(8) マニュアルページやハンドブックが良い入門となるでしょう。あなただけのカスタムカーネルを作るときに一般に最初にすることは、使用しないドライバやサービスをすべて削ることです。 INET6 や使わないドライバを削除することで、カーネルのサイズを時に 1 メガバイト以上減らすことができ、アプリケーションにさらにメモリを与えることができます。

SCSI_DELAY は、システムの起動時間を減らすために使うことができます。このデフォルト値はかなり大きく、ブート処理の中で 5 秒以上を占めるでしょう。 SCSI_DELAY を 5 秒未満に減らしてもうまく動くかもしれません (特に最近のドライブでは)。

*_CPU オプションの多くはコメントアウトできます。そのカーネルを Pentium クラスの CPU だけで動かすなら、 I486_CPU は削除することができます。ただし、 I586_CPU は、CPU が Pentium II 以上として認識されることを確認してから削除してください。 Pentium や 486 としてさえ認識されるクローンが存在し、その場合はこれらのオプションがないと起動することができません。もし動いたらすごいことです ! オペレーティングシステムは、MMU やタスク切り替え、タイムベース、デバイス操作に至る、より高度な機能をより利用することができるようになります。加えてより高度な CPU は、カーネルがカーネル自身をメモリにマップする 4MB の MMU ページをサポートします。これは高いシステムコール負荷の下での効率を上げます。

CPU、メモリ、ディスク、ネットワーク

負荷が上がるとシステムのどの部分がボトルネックになりはじめているかによって、調整の種類が違ってきます。システムが CPU を使い果たす (アイドル時間が絶えず 0% である) なら、 CPU をアップグレードすることを考慮する必要があるか、またはおそらく、負荷の原因となっているプログラムを見直し、それらを最適化する必要があります。スワップに対して大量のページングがあるならメモリをもっと増やす必要があるでしょう。ディスク性能が飽和している場合、CPU アイドル時間は高く、全般的にディスクが飽和状態になっています。 systat(1) でこれらをモニタすることができます。ディスク性能の飽和を解決するにはいろいろな方法があります: キャッシュのためのメモリを増やす、ディスクをミラーリングする、複数のマシンに操作を分散させる等です。ディスク性能が問題で、IDE ドライブを使っている場合、 SCSI に切り替えることでずいぶんよくなります。生のシーケンシャルな帯域幅については、最近の IDE ドライブは、SCSI のものに匹敵していますが、調べると大抵 SCSI ドライブが勝っています。

最後に、ネットワーク性能を使い果たしているかもしれません。できるだけネットワーク経路を最適化することです。例えば、 firewall(7) で説明した内部ホストを守るファイアウォールでは、外部から見えるホストはファイアウォールを通さないトポロジです。必要に応じて、100BaseT ではなく 1000BaseT を使用します。ほとんどのボトルネックは、WAN リンク (例えば、モデム、T1、DSL、のようなもの) で起こります。回線を増強できないのであれば、 dummynet(4) 機能を使ってピーク削減やその他のトラフィックシェイピングを行い過負荷のサービス (web サービス等) が他のサービス (電子メール等) に影響を与えるのを防いでください。逆もまた同様です。これは、家庭環境において、外部に公開しているサービス (web サービスや電子メール) よりもインタラクティブなトラフィック (ブラウザや ssh(1) ログイン) を優先するために使うことができるでしょう。

関連項目

netstat(1), systat(1), sendfile(2), ata(4), dummynet(4), login.conf(5), rc.conf(5), sysctl.conf(5), firewall(7), eventtimers(7), hier(7), ports(7), boot(8), bsdinstall(8), bsdlabel(8), ccdconfig(8), config(8), fsck(8), gjournal(8), gstripe(8), gvinum(8), ifconfig(8), ipfw(8), loader(8), mount(8), newfs(8), route(8), sysctl(8), tunefs(8)

歴史

tuning マニュアルページは、最初に Matthew Dillon によって書かれ、2001 年 5 月に、 FreeBSD 4.3 ではじめて登場しました。マニュアルページは、 Eitan Adler <eadler@FreeBSD.org>によって大幅に修正されました。