日本語 man コマンド類 (ja-man-1.1j_5) と日本語 man ドキュメント (ja-man-doc-5.4 (5.4-RELEASE 用) など) をインストールすると、以下のような man コマンド閲覧、キーワード検索が コンソールからできるようになります。
4.11-RELEASE-K, 5.4-RELEASE-K, 5.5-RELEASE-K, 6.0-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K, 12.1-RELEASE-K は、 プライベート版 (小金丸が編集してまとめたもの) ですが、 より多くの翻訳したファイルが含まれています。 (5.4-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K から 12.3-RELEASE-K, 13.0-RELEASE-K から 13.2-RELEASE-K は、全翻訳済み)
13.3-STABLE-K, 15.0-CURRENT-K は現在、作成中で日々更新されています。
Table of Contents
TUNING(7) FreeBSD 多方面の情報マニュアル TUNING(7)
名称
tuning -- FreeBSD の下での性能の調整
システム設定 - disklabel, newfs, tunefs, スワップ
スワップパーティションは、一般的に、4GB 未満の RAM があるシステムに対して
メインメモリのほぼサイズの 2 倍であるか、またはより大きいなら、メインメモ
リとほぼ等しいサイズであるべきです。スワップパーティションをサイズを決め
るとき、将来のメモリ拡張を頭に入れておいてください。あまりにも小さなス
ワップを設定することは、利用者がより多くのメモリを利用者のマシンに追加す
るなら、後で問題を引き起こすのと同様に、VM ページのスキャンコードで非効率
性をもたらすかもしれません。複数のディスクがあるより大きなシステムで、各
ドライブでスワップを設定します。ドライブのスワップパーティションは、ほぼ
同じサイズであるべきです。カーネルは、任意のサイズを扱うことがきますが、
内部のデータ構造は、最も大きいスワップパーティションの 4 倍のスケールとな
ります。スワップパーティションを同じサイズに近く保持することは、カーネル
が N ディスクに渡ってスワップ空間を最適にストライプすることを許可します。
それを少しやりすぎることに心配はいりません、スワップ空間は、UNIX の恩恵を
確保することです、たとえ利用者が通常スワップを多く使用しなくても、リブー
トすることを強制される前に、暴走するプログラムから復旧するためにより多く
の時間を与えることができます。
1 つの大きなパーティションを作成することは、よい考えではありません。最初
に、各パーティションは、異なった操作上の特徴があり、それらを分離すること
によって、ファイルシステムは、それらの特徴にそれ自体を調整することができ
ます。例えば、ルートと /usr のパーティションは、ほとんどの書き込みなし
で、ほとんど読み込まれますが、一方、たくさんの読み込みと書き込みが
/var/tmp に起こるかもしれません。適切にパーティションを区切ることによっ
て、より小さくより重い書き込みロードされたパーティションで導入された利用
者のシステムのフラグメンテーションは、ほとんどの読み込みパーティションで
損傷しません。
また、適切に利用者のシステムのパーティションを区切ることによって、利用者
は、newfs(8) と tunefs(8) パラメータを調整することができます。ただ 1 つの
価値がある調整の tunefs(8) オプションは、``tunefs -n enable /filesystem''
で softupdates することです。softupdates は、主にファイルの作成と削除のメ
タデータの性能を大幅に改善します。ほとんどのファイルシステムで softup
dates を有効にすることを推奨します。しかしながら、ファイルシステムでそれ
を使用するかどうかを決定するとき、利用者が注意するべき、softupdates の 2
つ制限があります。最初に、クラッシュの場合にファイルシステムの一貫性を保
証しますが、物理的なディスクへの保留中の書き込みで、とても簡単に数秒 (1
分になることさえ!) 遅れるかもしれません。利用者がクラッシュさせるなら、利
用者は、より多くの作業を失うかもしれず、そうでなければ。2 番目に、softup
dates は、ファイルシステムのブロックの解放を遅らせます。利用者に、満杯に
近い (ルートファイルシステムのような) ファイルシステムがあるなら、例え
ば、``make installworld'' のように、大規模な更新を行うことは、空間を使い
果たし、更新が失敗するかもしれません。この理由のために、softupdates は、
通常のインストールの間に、ルートファイルシステムで有効にされません。ルー
トファイルシステムは、めったに書き込まれないので、性能の損失はありませ
ん。
多くの実行時の mount(8) オプションが、存在し、利用者がシステムを調整する
ことを手助けすることができます。最も明らかで、最も危険なものは、async で
す。それが通常のファイルシステムではるかに危険過ぎるので、gjournal(8) に
関連してこのオプションをのみを使用します。それほど危険ではなく、より役に
立つ mount(8) オプションは、noatime と呼ばれます。UNIX ファイルシステム
は、通常、それがアクセスされるときはいつでも、ファイルまたはディレクトリ
の最後にアクセスされた時刻を更新します。この操作は、遅延する書き込みで
FreeBSD で処理され、通常、システムに負荷をかけません。しかしながら、利用
者のシステムが継続的に膨大な数のファイルをアクセスしているなら、バッファ
キャッシュは、atime (アクセス時刻) の更新で汚染されることになるかもしれ
ず、システムに負荷をかけます。例えば、利用者が、web サイトに重い負荷があ
るか、またはたくさんのリーダがいるニュースサーバで実行しているなら、利用
者は、この mount(8) オプションでより大きなパーティションの atime (アクセ
ス時刻) 更新をオフに切り替えることを考慮したいかもしれません。しかしなが
ら、利用者は、どこでも atime (アクセス時刻) 更新を理由もなくオフにすべき
ではありません。例えば、/var ファイルシステムは、メールボックスを習慣的に
保持し、(mtime との組み合わせで) atime は、メールボックスに新しいメールが
あるかどうかを決定するために使用されます。利用者は、なお / と /usr のよう
な、ほとんどの読み込み専用のパーティションのために atime をオンに切り替え
たままにしておいたほうがよいでしょう。いくつかのシステムユーティリティ
は、報告のために atime フィールドを使用するので、これは、特に / のために
役に立ちます。
ディスクのストライピング
大きなシステムで、利用者は、より大きな全体のパーティションを作成するため
に、ともにいくつかのドライブからパーティションをストライピングすることが
できます。また、ストライピングは、2 つ以上のディスクに渡って I/O 操作を分
割することによってファイルシステムの性能を向上させることができます。
gstripe(8), gvinum(8) と ccdconfig(8) ユーティリティは、簡単なストライピ
ングされたファイルシステムを作成するために使用されます。一般的に言えば、
ルートと /var/tmp のような小さな小さいパーティション、または /usr のよう
な本質的に読み込み専用のパーティションをストライピングすることは、完全に
時間の浪費です。利用者は、重大な I/O 性能を必要とするパーティション、通常
/var, /home またはデータベースと Web ページを保持するために使用されるカス
タムパーティションにのみストライピングするべきです、適切なストライピング
のサイズを選択することも重要です。ファイルシステムは、2 のべき乗の境界で
メタデータを格納する傾向があり、通常、利用者は、シークを増加されるのでは
なく、シークを減らしたいでしょう。これは、利用者が、1152 セクタのような大
きな中心を外れた (off-center) ストライピングのサイズを使用したいので、
シーケンシャルな I/O が両方のディスクをシークするのではないので、メタデー
タが単一のディスクに集中するのではなく両方のディスクに渡って配布されるこ
とを意味しています。
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 共用メモリセグメントは、ページ可能でない物理的
な RAM にマップされます。この機能は、利用者が、(A) 多くの (数百) のプロセ
スに渡って少量の共用メモリをマップするか、または (B) 任意の数のプロセスに
渡って大量の共用メモリのマップするかのいずれかの場合のみ、効果がありま
す。この機能によって、カーネルは、共有メモリを交換可能ではないようにし
て、共用メモリをコアに結び付けることを犠牲にして多くの内部のメモリ管理の
ページの追跡のオーバヘッドを削除することができます。
vfs.vmiodirenable sysctl は、1 (オン) をデフォルトとします。このパラメー
タは、ディレクトリがシステムによってどのようにキャッシュされるかを制御し
ます。ほとんどのディレクトリは、小さいですが、ファイルシステムで単一フラ
グメント (一般的に、2K) とさらに小さいバッファキャッシュ (一般的に、512
バイト) を使用します。しかしながら、デフォルトモードで動作しているとき、
バッファキャッシュは、たとえ利用者に大量のメモリがあっても、ディレクトリ
の固定の数のみをキャッシュします。この sysctl をオンに切り替えることに
よって、バッファキャッシュは、ディレクトリをキャッシュするために VM ペー
ジキャッシュ (VM Page Cache) を使用することができます。有理な点は、すべて
のメモリがディレクトリをキャッシュするために利用可能でないことです。不利
な点は、ディレクトリをキャッシュするために使用される最小のインコア (in
core) メモリが 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 は、守られます。
sysctl に関連している様々な他のバッファキャッシュと VM ページキャッシュが
あります。これらの値を修正することは、推奨されません。
net.inet.tcp.sendspace と net.inet.tcp.recvspace sysctl は、利用者がネッ
トワークに集中的なアプリケーションを実行しているなら、特に興味深いことで
す。それらは、あらゆる与えられた TCP 接続のために許可された送信と受信バッ
ファ空間の量を制御します。デフォルトの送信バッファは、32K です。デフォル
トの受信バッファは、64K です。利用者は、しばしば、接続ごとにより多くの
カーネルメモリを使い果たすことを犠牲にしてデフォルトを増加することによっ
て帯域幅の稼働率を改善することができます。増加しているストール (行き詰ま
る) された接続のために、迅速にシステムのメモリ不足となる可能性があるの
で、利用者が数百または数千の同時の接続をサービスしているなら、デフォルト
を増加することは推奨されません。しかし、利用者が少ない数の接続よりの高い
帯域幅が必要であるなら、特に、利用者にギガビットイーサネットがあるなら、
これらのデフォルトを増加させることは、莫大な違いを生じさせるかもしれませ
ん。利用者は、着信と発信データのためのバッファサイズを個別に調整すること
ができます。例えば、利用者のマシンが、web のサービスを主に行っているな
ら、利用者は、非常に多くのカーネルメモリを消費せずに sendspace (送信空間)
を増加することができる手段として recvspace (受信空間) を減少させたいかも
しれません。デフォルトの経路特有の送信と受信バッファサイズを導入するため
に、経路表 (route(8) を参照) を使用することができることに注意してくださ
い。
追加の管理ツールとして、利用者は、特定の IP ブロックまたはポートへ行く、
または特定の IP ブロックまたはポートから来る帯域幅を制限するために、利用
者のファイアウォール規則 (ipfw(8) を参照) でパイプを使用することができま
す。例えば、利用者が T1 を持っているなら、利用者は、残りをメールと対話型
な使用のために利用可能のままにするために、利用者の web トラフィックを T1
の帯域幅の 70% に制限したいでしょう。通常、高負荷の web サーバは、たとえ
ネットワークリンクが最大限に達したとしても、他のサービスに顕著な待ち時間
を取り入れませんが、制限を強制することは、物事を円滑にし、長期的な安定性
をもたらします。また、多くの人々は、過剰な帯域幅の使用するために課金され
ないことを保証するために、人為的な帯域幅の制限を強制します。
送信または受信の TCP バッファを 65535 より大きな値に設定することは、両方
のホストが、net.inet.tcp.rfc1323 sysctl によって制御される TCP プロトコル
のウィンドウのスケールの拡張をサポートしないなら、最低限度の性能向上を結
果となります。これらの拡張は、有効にされるべきで、TCP バッファサイズは、
ネットワークリンクの特定のタイプからよい性能を得るために 65536 より大きい
値に設定されるべきです。特に、ギガビット WAN リンクと高い待ち時間の衛星中
継リンク。RFC1323 サポートは、デフォルトで有効です。
net.inet.tcp.always_keepalive sysctl は、TCP 実装が接続で ``keepalives''
の断続的な配信によって死んだ TCP 接続を検出することを試みるべきであるかど
うかを決定します。デフォルトで、これは、すべてのアプリケーションのために
有効にされます。この sysctl を 0 に設定することによって、特に keepalives
を要求するアプリケーションだけが、それらを使用します。ほとんどの環境にお
いて、TCP keepalives は、特にネットワークから接続を絶つ前に、常に個別の
TCP 接続を終了しないダイヤルアップのユーザをサービスするシステムのため
に、期限が切れ死んだ TCP 接続によってシステム状態の管理を改善します。しか
しながら、いくつかの環境において、一時的なネットワークの機能停止は、突然
終了した TCP 接続の結果となり、死んだセッションとして間違って識別されるか
もしれません。そのような環境において、sysctl を 0 に設定することは、TCP
セッションの切断の発生を減少します。
net.inet.tcp.delayed_ack 機能は、大体は誤解されます。歴史的に言えば、この
機能は、応答とともに返される転送されたデータに確認応答を許可するように設
計されました。例えば、リモートのシェルで利用者がタイプするとき、利用者が
送信した文字への確認応答は、文字のエコーを表しているデータとともに返すこ
とができます。オフにされた遅延された ack (確認応答) で、確認応答は、リ
モートのサービスが、まさに受信されたデータをエコーされるチャンスがある前
に、それ自体のパケットに送信されます。この同じ概念は、また、あらゆる対話
型のプロトコル (例えば、SMTP、WWW、POP3) に適用し、ネットワークに渡って小
さいパケットの流れの数を半分に削減することができます。FreeBSD の遅延され
た ACK (確認応答) の実装もまた、たとえ標準の 100ms のタイムアウトがまだ渡
されていなくても、少なくともすべての他のパケットが確認応答される TCP プロ
トコル規則に従います。通常、遅延された ACK が行うことができる最悪の事態
は、接続の分解をわずかに遅延するか、または開始が遅れた TCP 接続の立ち上げ
をわずかに遅延します。遅延された ack (確認応答) をオフにすることを進め
る、SAMBA と SQUID のようなパッケージと関連しているいくつかの FAQ は、遅
い開始の問題を参照していると信じることは確かではありません。
net.inet.ip.portrange.* sysctl は、TCP と UDP ソケットに自動的にバインド
されるポート番号の範囲を制御します。3 つの範囲があります: IP_PORTRANGE
setsockopt(2) 呼び出しを通して選択可能な、低い範囲、デフォルトの範囲、と
高い範囲。ほとんどのネットワークプログラムは、それぞれ、49152 と 65535 を
デフォルトとする net.inet.ip.portrange.first と
net.inet.ip.portrange.last によって制御されるデフォルト範囲を使用します。
バインドされたポートの範囲は、発信する接続のために使用され、特定の状況の
下でポートからシステムを実行することが可能です。これは、利用者が、高い負
荷のウェブプロキシを実行しているとき、最も一般的に起こります。ポートの範
囲は、処理が、通常のウェブサーバのような、主に着信する接続、またはメール
リレーのような、制限された数の発信する接続がある、サーバを実行するとき、
問題ではありません。利用者がポートを使い果たして実行している状況につい
て、net.inet.ip.portrange.first をやや減少させることを勧めます。10000 か
ら 30000 までのポートの範囲は、妥当です。また、利用者は、ポート範囲を変更
するとき、ファイアウォールの効果を考慮するべきです。いくつかのファイア
ウォールは、ポート (通常若い番号のポート) の大きな範囲をブロックし、シス
テムが発信する接続のためのポートのより高い範囲を使用することを期待しま
す。デフォルトで、net.inet.ip.portrange.last は、最大の許可されポート番号
で設定されます。
kern.ipc.somaxconn sysctl は、新しい TCP 接続を受け付けるための listen
(接続を受け付け) するキューのサイズを制限します。128 のデフォルト値は、通
常、高負荷の web サーバ環境での新しい接続の強固な処理のためには低すぎま
す。そのような環境について、1024 以上にこの値を増加させることを推奨しま
す。サービスデーモンは、それ自体 listen (接続を受け付け) するキューのサイ
ズ (例えば、sendmail(8), apache) を制限しますが、しばしばキューのサイズを
増加するためにその設定ファイルにディレクティブがあります。また、より大き
な、listen (接続を受け付け) するキューは、サービス拒否攻撃を回避すること
のよりよいジョブを行います。
kern.maxfiles sysctl は、システムがサポートするファイルをどのくらいオープ
ンできるかを決定します。デフォルトは、通常、数千ですが、利用者は、データ
ベースまたは大きな記述子の重いデーモンを実行しているなら、最高 1 万または
2 万にこれに増やす必要があります。読み込み専用の kern.openfiles sysctl
は、システムでオープンしているファイルの現在の数を決定するために問い合わ
されます。
vm.swap_idle_enabled sysctl は、利用者に、システムとたくさんのアイドルプ
ロセスに入って、残っているたくさんのユーザがいる大きなマルチユーザシステ
ムで役に立ちます。そのようなシステムは、空きメモリの予約で多くの継続的な
圧力を生む傾向があります。この機能をオンにして、vm.swap_idle_threshold1
と vm.swap_idle_threshold2 を通してスワップアウトヒステリシス (アイドルの
秒単位で) を調整することは、利用者が、通常のページアウトアルゴリズムより
より迅速にアイドルなプロセスに関連したページの優先度を下げることができま
す。これは、ページアウトデーモンを手助けします。より多くのスワップとディ
スク帯域幅をむしはんで、後ではなくより早く、本質的に前ページメモリの利用
者が行うトレードオフであるので、利用者にそれが必要としないなら、このオプ
ションをオンにしてはいけません。小さいシステムにおいて、このオプション
は、有害な効果がありますが、既に、適度なページングを行っている大きなシス
テムにおいて、このオプションによって、VM システムは、より容易にメモリに出
入りする全体のプロセスを計画することができます。
ローダ調整変数
システムの振る舞いのいくつかの側面は、実行するメモリ割り付けは、初期の
ブートプロセスに存在しなければならないので、実行時で調整することができま
せん。ローダ調整変数を変更するためには、利用者は、loader.conf(5) に、それ
らの値を設定し、システムを再起動しなければなりません。
kern.maxusers は、オープンしているファイルの最大の数、ネットワークメモリ
のリソース等のサイズのためのデフォルトを含んで、静的なシステムテーブルの
数の規模を制御します。kern.maxusers は、システムで利用可能なメモリの量に
基づいてブートで、自動的にサイズが決められ、読み込み専用の kern.maxusers
sysctl の値を検査することによって実行時に決定されます。
kern.dfldsiz と kern.dflssiz 調整変数は、それぞれ、プロセスのデータとス
タックサイズのデフォルトのソフト制限を設定します。プロセスは、
setrlimit(2) を呼び出すことによって、それらをハード制限まで増加させること
ができます。kern.maxdsiz, kern.maxssiz と kern.maxtsiz は、それぞれ、プロ
セスのデータ、スタックとテキストサイズのハード制限を設定します。プロセス
は、これらの制限を超えないかもしれません。kern.sgrowsiz 調整変数は、プロ
セスが、より多くのスタックを割り付ける必要があるとき、スタックセグメント
がどのくらい成長するかを制御します。
kern.ipc.nmbclusters は、システムが、割り付けようとしている、ネットワーク
mbuf の数を増加させるために、調整されます。各クラスタは、約 2K のメモリを
表しているので、1024 の値は、ネットワークバッファのために予約された 2M の
カーネルメモリを表しています。利用者は、どのくらい必要であるかを理解する
ために、簡単な計算をすることができます。利用者には、1000 の同時の接続で最
大限に達している web サーバがあり、各接続が、16K の受信と 16Kの送信バッ
ファを費すなら、利用者は、それを扱うために、約 32MB 相当のネットワーク
バッファのが必要です。確かな経験則は、2 の倍数で増加することですので、
32MBx2 = 64MB/2K = 32768 です。したがって、この場合に、利用者は、
kern.ipc.nmbclusters を 32768 に設定したいでしょう。あまり多くないメモリ
があるマシンに対して 1024 から 4096 の間、大きなメモリがあるマシンに対し
て 4096 から 32768 の間を推奨します。いかなる状況でも、利用者は、それが
ブート時にクラッシュを導くかもしれない、このパラメータのための独断的に大
きな値を指定するべきではありません。netstat(1) への -m オプションは、ネッ
トワーククラスタの使用を観察するために使用されます。
ますます多くのプログラムは、ネットワークを越えてファイルを転送するため
に、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
を容易に削除することができますが、利用者の CPU が Pentium II 以上として認
識されていることを確信しているなら、I586_CPU のみを削除することができま
す。いくつかのクローンは、Pentium または 486 とさえ認識され、それらのオプ
ションなしでブートことができません。それが動作するなら、素晴らしいことで
す! オペレーティングシステムは、MMU、タスク切り替え、タイムベースとデバ
イス操作でさえ、高性能 CPU 機能をよりよく使用することができます。さらに、
高性能の CPU は、重い syscall ロードの下でその効率を増加させる、カーネル
がメモリにカーネル自体のをマップするために使用する、4MB MMU ページをサ
ポートします。
CPU、メモリ、ディスク、ネットワーク
調整しているタイプは、利用者のシステムが負荷の増加としてボトルネックし始
まるところで大きく依存しています。システムが CPU を使い果たす (アイドル時
間が絶えず 0% である) なら、CPU をアップグレードすることを考慮する必要が
あるか、またはおそらく、負荷の原因となっているプログラムを見直し、それら
を最適化する必要があります。利用者のシステムが多くのスワップのためにペー
ジングを行っているなら、より多くのメモリを追加することを考慮する必要があ
ります。利用者のシステムがディスクを飽和させているなら、利用者は、通常、
高い CPU アイドル時間と合計のディスクの飽和状態がわかります。systat(1)
は、これをモニタするために使用することができます。飽和されたディスクのた
めの多くの解決策があります: キャッシュのためのメモリを増加する、ディスク
をミラーリングする、いくつかのマシンに渡って操作を分散する、など。
最後に、利用者は、ネットワークの suds を使い果たすかもしれません。ネット
ワークのパスをできるだけ最適化します。例えば、firewall(7) で、外部的に可
視のホストがそれを通して経路制御されないトポロジで内部的なホストを保護し
ているファイアウォールを記述します。ほとんどのボトルネックは、WAN リンク
で起こます。リンクを拡張するオプションがないなら、(web サービスのような)
負荷をかけられたサービスが (電子メールのような) 他のサービスに影響するこ
とを防止するためにピークを削ることか、またはトラフィックシェイピングの他
の形式を実装するために、逆もまた同様に、dummynet(4) 機能を使用することが
できます。家庭の設備において、これは、利用者のボックスからエクスポートす
るサービス (web サービス、電子メール) より高い対話型なトラフィック (利用
者のブラウザ、ssh(1) ログイン) の優先度を与えるために使用することができる
でしょう。
関連項目
netstat(1), systat(1), sendfile(2), ata(4), dummynet(4), eventtimers(4),
login.conf(5), rc.conf(5), sysctl.conf(5), firewall(7), hier(7),
ports(7), boot(8), bsdinstall(8), ccdconfig(8), config(8), fsck(8),
gjournal(8), gpart(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> によって大幅に修正されました。
FreeBSD 11.2 October 30, 2017 FreeBSD 11.2