tuning(7) FreeBSD 一般コマンドマニュアル

tuning

前のページ 上に戻る 次のページ

tuning


     合、ディスクの内周トラックよりも外周トラックのほうがずっと速くデータを転
     送できることを意識することが重要です。この利点を生かすには、小さいファイ
     ルシステムやスワップを外周トラックに近いほうから詰めていくべきです。より
     大きいファイルシステムは内周へ近いほうへ詰めていき、最も大きいファイルシ
     ステムを最後にします。後でマシンを増強した時にシステム標準のファイルシス
     テムの大きさを変更しなくて済むような大きさに決めることが重要です。私は大
     抵、順番にルートパーティションに 128M、スワップに 1G、 /var に
     128M、/var/tmp に 128M、/usr に 3G、そして残りを /home に割り当てます。

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

     /var パーティションをどれだけの大きさにするかは、そのマシンを何に使うかと
     いうことに大きく依存します。このパーティションは主にメールボックスやプリ
     ントスプール、ログファイルの保存場所に使われます。 /var/log を別のパー
     ティションにする人もいます (しかし、パーティション ID を消費しないほうが
     よい極端な場合は例外です)。メールサーバやプリントサーバ、あるいは訪問数が
     非常に多い Web サーバとしてマシンが動作するなら、極めて大きいパーティショ
     ン―おそらく 1 ギガバイト以上―を作成することを考えるべきでしょう。ログ
     ファイルの保存に必要な大きさは、小さく見積もられがちです。

     /var/tmp の大きさは、テンポラリファイルの類がどれだけ使われる必要があるか
     で決まります。最低でも 128M にすることを推奨します。 sysinstall は /tmp
     ディレクトリを作成しますが、 /tmp は後で /var/tmp へのソフトリンクにして
     おくのは大抵よい考えです。テンポラリファイル領域専用に一つのパーティショ
     ンを割り当てることは重要で、2 つの理由があります: クラッシュ時のファイル
     システムの破壊の可能性を減らすのと、[/var]/tmp を一杯にしてしまうような暴
     走プロセスが、さらに重要なサブシステム (メールやログ等) に影響を与える可
     能性を減らすためです。 [/var]/tmp が一杯になってしまうのはよくある問題で
     す。

     かつては /tmp と /var/tmp の間には違いがありましたが、 /var (と /var/tmp)
     の導入によってプログラマは大変混乱し、今日では両方がでたらめに使われてい
     ます。つまりこの二つは実際には区別することができません。したがって、一つ
     のテンポラリディレクトリだけにしてしまうことは意味があります。どのように
     /tmp を扱ったとしても、それがルートパーティションにあるのは好ましくないで
     抵ディスクの残りを使います。

     何故 パーティションを切るのでしょう ?  一つの大きな / パーティションを作
     るだけでいいのではないでしょうか ?  そうすれば小さすぎないかどうか気にす
     る必要はないのに !  はい、その考えがよくないのは、いくつか理由がありま
     す。一つめは、それぞれのパーティションは運用上の性格が異なるのですが、そ
     れらを分離することでファイルシステムに対しその性格に適したチューンをする
     ことが可能になるからです。例えばルートパーティションや /usr パーティショ
     ンはほとんど読み込みであり、ほとんど書き込みがありません。一方で /var や
     /var/tmp に対しては大量の読み込みや書き込みがあるでしょう。システムをうま
     く分割することで、書き込みが多いパーティションの破壊による被害が、ほとん
     ど読み込みのみのパーティションに及ばないようします。加えて、書き込みが多
     いパーティションをディスクの端 (すなわちパーティションテーブルにおいて、
     本当に大きなパーティションの後ろではなく、前の方) の方に置くことで、その
     パーティションについて性能が向上します。より大きなパーティションについて
     も入出力性能が必要なのも確かですが、 /var をディスクの端に置くと大きな改
     善が可能であるのに対し、巨大なパーティションをディスクの端に置いてもそれ
     ほど性能の改善にはつながりません。最後は安全性に関わることです。小さく、
     簡潔な、本質的に読み取りのみのルートパーティションとすることで、クラッ
     シュを生き延びるチャンスを大きくすることができます。

     システムを正しく分割することで、 newfs(8)tunefs(8) に与えるパラメータ
     をチューンすることも可能になります。 newfs() のチューニングにはさらに経験
     が必要ですが、かなりの性能改善につながります。比較的安全にチューンできる
     3 つのパラメータがあります: blocksize, bytes/inode, cylinders/group で
     す。

     FreeBSD は 8K または 16K のファイルシステムブロックサイズを使用した時に最
     高の性能が得られます。デフォルトは 8K です。大きなパーティションでは、
     16K ブロックサイズにするのも大抵よい考えです。これにはより大きいフラグメ
     ントサイズを指定する必要もあります。常にブロックサイズの 1/8 のフラグメン
     トサイズにすることを推奨します (他のフラグメントサイズの割合ではあまりテ
     ストされていません)。この場合の newfs() オプションは newfs -f 2048 -b
     16384 ... となるでしょう。さらに大きなブロックサイズはバッファキャッシュ
     の断片化の原因となり、性能の低下につながります。

     大きなパーティションに、データベースファイルのような少数の大きなファイル
     を置くのであれば、 bytes/inode の比率を増やすことができます。これは、その
     パーティションの i ノードの数 (ファイルやディレクトリの最大の数) を減らし
     ます。 i ノードの数を減らすことで、クラッシュ後の fsck(8) による修復時間
     を大幅に減らすことができます。本当にこのパーティションに大きなファイルを
     置くのでない限り、このオプションを使わないでください。空き領域が大量にあ
     るのにファイルを収容できなくなるかもしれません。 bytes/inode は、32768 か
     65536 か 262144 とすることが推奨されます。もっと大きな値にすることができ
     ますが、fsck による修復時間を増やすだけでしょう。例えば、 newfs -i 32768
     ... のようにして値を与えます。

     最後に、 cylinders/group の比率を増やすことは、i ノード同士を近くに寄せる
     効果があります。これはディレクトリの性能を上げ、fsck にかかる時間を減らし
     ます。もしこのオプションを使うのであれば、最大にすることを推奨します。
     newfs -c 999 とすれば newfs はエラーとなり最大値を教えてくれるので、その
     値を使ってください。
     ります!)  遅れる可能性が高いことです。クラッシュした場合、より多くの成果
     が消えてしまうかもしれません。 2 つめは、softupdates はファイルシステムブ
     ロックを解放するのを遅らせるということです。あるファイルシステム (例えば
     ルートファイルシステム) が満杯近くの時にそれに対する大規模な更新、たとえ
     ば make installworld をすると、空き領域を使い果たして更新が失敗してしまう
     ことがあります。

     マウント実行時のいくつかのオプションはファイルシステムをチューンするのに
     役立ちます。最も明らかで、しかも最も危険なのは async です。これは決して使
     わないでください。大変危険です。比較的危険度が低く、より役に立つマウント
     オプションは noatime です。通常 UNIX ファイルシステムは、ファイルやディレ
     クトリにアクセスがあった場合は常に、その最終アクセス時刻を更新します。
     FreeBSD では、この動作は遅延書き込みで行なわれ、通常は大した負荷にはなり
     ません。しかし、大量のファイルが連続してアクセスされた場合、バッファ
     キャッシュがアクセス時刻の更新で汚染され大きな負荷となります。例えば、高
     負荷の web サイトや大量の読者を抱えるニューズサーバでは、このマウントオプ
     ションで大きなパーティションにおけるアクセス時刻の更新を停止することが考
     えられます。根拠もなく、すべての場所でアクセス時刻の更新を停止しないでく
     ださい。例えば / や /usr のようなほとんど読み込みのみのパーティションはオ
     ンにしたままにすることができるでしょう (特に / についてはいくつかのシステ
     ムユーティリティがアクセス時刻フィールドをリポートのために利用します)。


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

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


sysctl によるチューニング

     システムには数百の sysctl(8) 変数が存在します。そのなかには、チューニング
     の候補のように見えますが本当はそうでないものも多く含まれます。この文書で
     はシステムに最も大きな影響を与えるものだけを扱います。

     kern.ipc.shm_use_phys は、デフォルトが 0 (オフ) であり、 0 (オフ) または
     1 (オン) にセットすることができます。このパラメータを 1 にセットすると、
     全ての SysV 共有メモリセグメントがページング不可の物理メモリにマップされ
     ます。これは、(A) 大量 (数百) のプロセス間で少量の共有メモリをマッピング
     しているか、(B) 任意個のプロセス間で大量の共有メモリをマッピングしてい
     る、のいずれかの場合に効果があります。この機能は、共有メモリをスワップ不
     キャッシュに使われる最小のメモリの大きさが 512 バイトではなく物理ページサ
     イズ (大抵は 4K) になることです。多数のファイルを操作するサービスを稼動し
     ているなら、常にこのオプションをオンにすることを推奨します。そのようなサ
     ービスには、web キャッシュや、大規模なメールシステム、ニューズシステムな
     どが含まれます。このオプションは一般にメモリを消費しますが、性能を削減す
     ることはありません。ただし実験して調べてみるべきでしょう。

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

     net.inet.tcp.sendspacenet.inet.tcp.recvspace は、ネットワークに関連す
     るアプリケーションを稼動している場合は特に重要です。これは、TCP コネク
     ションの送信および受信バッファ領域の大きさを調節します。デフォルトは 16K
     です。このデフォルトを増やすことで各コネクションについてカーネルメモリが
     さらに消費されますが、帯域幅の利用率が改善することがあります。同時に数百
     とか数千のコネクションを扱っている場合、このデフォルトを増やすことは推奨
     されません。失速してしまったコネクションが蓄積することで、システムがメモ
     リをすぐに使い果たしてしまうからです。しかし、少ない数のコネクションにつ
     いて広い帯域幅が必要ならば、特にギガビットイーサネットの場合、このデフォ
     ルトを大幅に増やすことができます。入力データと出力データのバッファを個別
     に調整することができます。たとえば、主に web サービスをしているマシンなら
     ば recvspace を減らすことで、それほど大量にカーネルメモリを消費せずに
     sendspace を増やすことができます。経路表 ( route(8) を参照 ) に対しては、
     経路に特化した送受信バッファを導入することができるということに注意してく
     ださい。付加的な管理ツールとして、ファイアウォールルールにおいてパイプ
     (pipe) を使うことで ( ipfw(8) を参照)、特定の IP ブロックやポートへ行く、
     あるいはそこから来る帯域幅を制限することができます。例えば T1 回線を持っ
     ている場合、 web トラフィックは回線の 70% に制限し、残りをメールとインタ
     ラクティブな用途に使いたいと思うでしょう。通常高い負荷の web サーバは、
     ネットワーク回線が使い切られていても、他のサービスに大きな遅延を与えるこ
     とはありませんが、制限をかけることは物事を円滑にし長期的な安定につながり
     ます。また、多くの人が、帯域超過による課金をされないように意図的な帯域制
     限をかけています。

     TCP の送信あるいは受信バッファサイズを 65535 を超えて指定してもほとんど性
     能の改善はありません。これは TCP プロトコル自身の制限です。この制限によ
     り、ある種のネットワーク回線 (特にギガビット WAN 回線や高遅延の衛星回線)
     で最高レベルの性能に達しないことがあります。そのような場合で、その性能が
     受け入れられるようなものなら、単純に TCP バッファサイズを 65535 にセット
     し固定することを推奨します。極端な場合は、 net.inet.tcp.rfc1323 をオンに
     してバッファサイズを 65535 より増やすことができます。このオプションは TCP
     プロトコルのウィンドウサイズ拡張を有効にします。どうしてもこれを使わなけ
     ればならない場合以外は、使わないことを推奨します。インターネット上の多く
     のホストがこの拡張を扱うことができず、コネクションが停止してしまう原因に
     なることもあります。

     net.inet.tcp.always_keepalive はオン (1 にセット) にしてそのままにしてお
     いてください。デフォルトは大抵オフです。少量のネットワーク帯域を消費しま
     すが、偶然死んでしまった TCP コネクションを認識し除去することを保証しま
     す。死んでしまった TCP コネクションは、特にダイアルアップのユーザによりア
     うデーモンを稼働している場合は 10000 や 20000 に引き上げる必要があるかも
     しれません。

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


カーネル構成におけるチューニング

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

     maxusers カーネルオプションのデフォルトは驚くほど小さな値です。最近のマシ
     ンでは、おそらく 64 か 128 あるいは 256 に増やしたいと思うでしょう。莫大
     な数のファイル記述子が必要でない限り、 256 を超えるのは推奨されません。
     ネットワークバッファにも影響を与えますが、別のカーネルオプションで制御で
     きます。ネットワーク mbuf をさらに得るためだけに maxusers を増やさないで
     ください。

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

     ますます多くのプログラムが sendfile() システムコールを使ってネットワーク
     を通じてファイルを転送しています。 NSFBUFS カーネルパラメータは
     sendfile() の実行時にファイルシステムバッファをどれだけの数だけ使えるかを
     制御します。通常このパラメータは maxusers に比例しているので、極端な場合
     り替え、タイムベース、デバイス操作に至る、より高度な機能をより利用するこ
     とができるようになります。加えてより高度な CPU は、カーネルがカーネル自身
     をメモリにマップする 4MB の MMU ページをサポートします。これは高いシステ
     ムコール負荷の下での効率を上げます。


IDE ライトキャッシュ

     FreeBSD 4.3 では IDE のライトキャッシュがオフになりました。これは IDE
     ディスクへの書き込み帯域幅を減らしてしまうことになりますが、ハードドライ
     ブベンダに起因するデータの一貫性に関する重大な問題のために、必要なことだ
     と考えられました。基本的には、書き込み完了時期について IDE ドライブが嘘を
     つくという問題です。 IDE ライトキャッシュがオンであると、 IDE ハードドラ
     イブはデータを順番に書きこまないばかりか、ディスクの負荷が高い時にはいく
     つかのブロックの書き込みを無期限に延期してしまいます。クラッシュや電源故
     障の場合、ファイルシステムの重大な破壊をもたらします。したがって私たちは
     デフォルトを安全側に変更しました。残念ながら、これは大変な性能の低下をも
     たらし、私たちはあきらめてこのリリース後にオンに戻しました。 hw.ata.wc
     sysctl 変数を見て、デフォルトをチェックしてみるべきです。もし IDE ライト
     キャッシュがオフになっていたら、 hw.ata.wc カーネル変数を 1 に戻すことで
     オンに戻すことができます。これはブート時にブートローダから行わなければな
     りません。カーネルがブートした後に行っても効果はありません。 ata(4)loader(8) を参照してください。

     IDE ハードドライブの実験的な新機能として、 hw.ata.tags と呼ばれるものがあ
     り (これもブートローダで設定します)、ライトキャッシュを安全にオンにするこ
     とができます。これは SCSI のタギング機能を IDE ドライブに持ち込んだもので
     す。これを書いている時点では、IBM DPLA と DTLA ドライブだけがこの機能をサ
     ポートしています。警告! これらのドライブは品質管理に問題があるようなの
     で、私は現時点ではこれらの製品を買うことはおすすめしません。性能が必要な
     ら SCSI を使いましょう。


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

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

     最後に、ネットワーク性能を使い果たしているかもしれません。ネットワーク性
     能を改善するために最初に確認すべきことは、ハブではなくスイッチを使ってい
     るか、ということです。特に最近はスイッチは安くなっています。ハブが高負荷
     になると、コリジョンバックオフのために深刻な問題が発生します。また、一台
     のホストに問題があると、LAN 全体の性能を大幅に低下させます。次に、できる
     だけネットワーク経路を最適化することです。例えば firewall(7) で説明した内
     ifconfig(8), ipfw(8), loader(8), newfs(8), route(8), sysctl(8),
     tunefs(8), vinum(8)


歴史

     tuning マニュアルページは、もともと Matthew Dillon によって書かれました。
     最初に現れたのは FreeBSD 4.3 で、2001 年 5 月のことです。

FreeBSD 4.4                      May 25, 2001                      FreeBSD 4.4

ABELNET VPSサービス