8.4. 設定ツール

Red Hat Enterprise Linux ではストレージやファイルシステムの設定を行う際に役立つツールがいくつか用意されています。このセクションではこうしたツールを簡単に説明し、Red Hat Enterprise Linux 7 でそのツールを使って I/O およびファイルシステム関連の問題を解決する例を紹介します。

8.4.1. ストレージパフォーマンス向けチューニングプロファイルの設定

Tuned サービスには特定の使用事例でパフォーマンスを改善できるようデザインされたプロファイルが用意されています。次のプロファイルはストレージのパフォーマンス改善に特に役立ちます。
  • latency-performance
  • throughput-performance (デフォルト)
システムでプロファイルを設定するには次のコマンドを実行します。name には使用するプロファイル名を入力します。 
$ tuned-adm profile name
tuned-adm recommend コマンドはシステムに適切なプロファイルを推薦します。
プロファイルの詳細および設定オプションなどについては「tuned-adm」を参照してください。

8.4.2. デフォルト I/O スケジューラーの設定

デフォルトの I/O スケジューラーとは、デバイスで他のスケジューラーを明示的に指定しなかった場合に使用されるスケジューラーです。
デフォルトのスケジューラーを指定しない場合、SATA ドライブでは cfq スケジューラーが使用され、その他すべてのドライブでは deadline スケジューラーが使用されます。このセクションで説明する手順に従ってデフォルトのスケジューラーを指定した場合には、そのデフォルトスケジューラーがすべてのデバイスに適用されます。
デフォルトの I/O スケジューラーは、Tuned ツールを使用するか、手動で /etc/default/grub ファイルを変更して設定することができます。
起動しているシステムのデフォルト I/O スケジューラーを指定する場合は、Tuned ツールの使用を推奨します。elevator パラメーターを設定するには、disk プラグインを有効にします。disk プラグインの詳細については、『Tuned』の章の「プラグイン」を参照してください。
GRUB 2 を使用してデフォルトのスケジューラーを修正するには、起動時またはシステムが起動している時に、カーネルコマンドラインに elevator パラメーターを追加します。Tuned ツールを使用するか、手順8.1「GRUB 2 を使用したデフォルト I/O スケジューラーの設定」で説明するように手動で /etc/default/grub ファイルを修正することができます。

手順8.1 GRUB 2 を使用したデフォルト I/O スケジューラーの設定

起動しているシステムのデフォルト I/O スケジューラーを設定し、再起動後も設定を維持するには、以下の手順を実施します。
  1. /etc/default/grub ファイルの GRUB_CMDLINE_LINUX 行に、elevator パラメーターを追加します。 
    # cat /etc/default/grub
...
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=vg00/lvroot rd.lvm.lv=vg00/lvswap elevator=noop"
...
    Red Hat Enterprise Linux 7 で使用可能なスケジューラーは、deadline、noop、および cfq です。詳細については、お使いのカーネルのドキュメントに含まれている cfq-iosched.txt および deadline-iosched.txt ファイルを参照してください。これらは kernel-doc パッケージのインストールにより利用することができます。
  2. 追加した elevator パラメーターを含む新しい設定ファイルを作成します。
    BIOS ファームウェアを使用しているシステムと UEFI ファームウェアを使用しているシステムとでは、GRUB 2 設定ファイルの場所が異なります。以下のコマンドのいずれかを使用して、GRUB 2 設定ファイルを再作成します。
    • BIOS ファームウェアを使用している場合は、以下のコマンドを使用します。 
      # grub2-mkconfig -o /etc/grub2.cfg
    • UEFI ファームウェアを使用している場合は、以下のコマンドを使用します。 
      # grub2-mkconfig -o /etc/grub2-efi.cfg
  3. システムを再起動して、変更を有効にします。
    GNU GRand Unified Bootloader バージョン 2 (GRUB 2) の詳細な情報については、『Red Hat Enterprise Linux 7 システム管理者のガイド』の「GRUB 2 について」セクションを参照してください。

8.4.3. 汎用のブロックデバイスチューニングパラメーター

ここで取り上げる汎用チューニングパラメーターは、/sys/block/sdX/queue/ ディレクトリーないで利用できます。リストされたチューニングパラメーターは I/O スケジューラーのチューニングと区別され、すべての I/O スケジューラーに適用できます。
add_random
いくつかの I/O イベントが /dev/random のエントロピープールに貢献しています。これらの貢献のオーバーヘッドが計測可能になる場合、このパラメーターを 0 に設定することができます。
iostats
デフォルト値は 1 (enabled) です。iostats を 0 に設定すると、デバイスに対する I/O 統計の収集が無効化され、I/O パスのオーバーヘッドが若干削減されます。一部の NVMe ソリッドステートストレージデバイスなどのパフォーマンスが非常に高いデバイスの場合、iostats を 0 に設定すると、パフォーマンスが若干向上します。ストレージモデルに対してベンダーの指定がない限り、iostats を有効の状態にすることが推奨されます。
iostats を無効にすると、デバイスの I/O 統計は /proc/diskstats ファイル内に存在しなくなります。/sys/diskstats の内容は、sar や iostats などの I/O ツールを監視するための I/O 情報のソースです。そのため、デバイスの iostats パラメーターを無効にすると、デバイスは I/O 監視ツールの出力から除外されます。
max_sectors_kb
I/O 要求の最大サイズをキロバイト単位で指定します。デフォルト値は 512 KB です。このパラメーターの最小値はストレージデバイスの論理ブロックサイズで確定されます。パラメーターの最大値は max_hw_sectors_kb の値で確定されます。
一部のソリッドステートディスクは、I/O リクエストが内部消去ブロックサイズよりも大きいとパフォーマンスが悪化します。システムにアタッチするソリッドステートディスクモデルがこれに該当するかを判断するには、ハードウェアのベンダーに確認し、ベンダーの推奨事項に従います。Red Hat は、常に max_sectors_kb を最適な I/O サイズと内部消去ブロックサイズの倍数にするよう推奨しています。これらの値がゼロであったり、ストレージデバイスの指定がない場合は、いずれかのパラメーターに logical_block_size の値を使用します。
nomerges
リクエストのマージはほとんどのワークロードに対して有用ですが、デバッグの目的でマージを無効にすると便利です。デフォルトでは、nomerges パラメーターは 0 に設定され、マージが有効になっています。簡単な 1 度のマージを無効にするには、nomerges を 1 に設定します。あらゆる種類のマージを無効にするには、nomerges を 2 に設定します。
nr_requests
一度にキュー待ちさせることができる読み取りと書き込み要求の最大数を指定します。デフォルト値は 128 です。つまり、読み取りまたは書き込みの要求に対する次の処理をスリープ状態にするまでそれぞれ 128 個の読み取り要求と 128 個の書き込み要求をキュー待ちにすることができます。
遅延の影響を受けやすいアプリケーションの場合、ライトバック I/O が書き込み要求でデバイスキューを満杯にできないようにするため、このパラメーターの値を低くしてストレージのコマンドキューの深さを制限します。デバイスのキューが満杯になると I/O 動作を実行しようとしている他のプロセスはキューが使用できるようになるまでスリープ状態になります。要求はラウンドロビン方式で割り当てられ、1 つのプロセスが継続してキューのすべての領域を使用しないようにします。
I/O スケジューラー内の I/O 操作の最大数は nr_requests*2 です。nr_requests は読み取りと書き込みで別々に適用されます。nr_requests は I/O スケジューラー内の I/O 操作のみに適用され、基盤のデバイスにすでにディスパッチされた I/O 操作には適用されません。そのため、1 つのデバイスに対する未処理の I/O 操作の最大数は (nr_requests*2)+(queue_depth) になります (queue_depth は /sys/block/sdN/device/queue_depth で LUN キューの深さと呼ばれることもあります)。たとえば、未処理の I/O 操作の合計数は avgqu-sz 列の iostat の出力に表示されます。
optimal_io_size
このパラメーターを使用すると最適な I/O サイズを報告するストレージデバイスがあります。この値が報告される場合は、できるだけ報告された最適な I/O サイズに合わせその倍数の I/O をアプリケーションで発行させることを推奨しています。
read_ahead_kb
シーケンシャル読み取り操作中にオペレーティングシステムが先に読み取る最大キロバイト数を定義します。その結果、次のシーケンシャル読み取りに対し、必要となりそうな情報はカーネルページキャッシュ内にすでに存在するため、読み取りの I/O 操作が向上します。
デバイスマッパーでは、多くの場合で read_ahead_kb の値を大きくすると効果的です。開始点として、各デバイスに対して 128 KB の値にするとよいでしょう。read_ahead_kb の値を 4–8 MB に上げると、大型のファイルのシーケンシャル読み取りが行われるアプリケーション環境でのパフォーマンスが向上する可能性があります。
rotational
一部の SSD はそのソリッドステート状態を正しく通知しないため、従来の回転ディスクとしてマウントされます。ご使用の SSD デバイスで、この値が自動的に 0 に設定されない場合は、この値を手作業で設定し、スケジューラーで不要なシーク時間短縮ロジックを無効にします。
rq_affinity
デフォルトでは I/O 要求を発行したプロセッサーとは異なるプロセッサーで I/O の完了を処理することができます。rq_affinity を 1 に設定するとこの機能を無効にして I/O の完了はその I/O 要求を発行したプロセッサーでしか行わないようにします。これによりプロセッサーのデータキャッシングの効率性が改善されます。
scheduler
スケジューラーや特定ストレージデバイスのスケジューラー優先順位を設定するには、/sys/block/devname/queue/scheduler ファイルを編集します (devname は設定するデバイスの名前に置き換えます)。 
# echo cfq > /sys/block/hda/queue/scheduler

8.4.4. deadline スケジューラーのチューニング

deadline を使用するとキュー待ちの I/O 要求は読み取りまたは書き込みのバッチに分けられてから増大している論理ブロックアドレス順に実行スケジュールに入れられます。アプリケーションは読み取り I/O でブロックする可能性の方が高いため、デフォルトでは読み取りバッチの方が書き込みバッチより優先されます。1 バッチが処理されると deadline は書き込み動作が待機している長さを確認して次の読み取りバッチまたは書き込みバッチを適宜スケジュールします。
deadline スケジューラーの動作に影響を与えるパラメーターです。
fifo_batch
ひとつのバッチで発行する読み取りまたは書き込みの動作数です。デフォルトは 16 です。値を高くするほど処理能力も高まりますが待ち時間も増加します。
front_merges
前方マージを一切生成しない作業負荷の場合、0 に設定することは可能です。ただし、このチェックのオーバーヘッドを測定していない限り Red Hat ではデフォルト値の 1 の使用を推奨しています。
read_expire
ミリ秒単位で指定します。この時間内に読み取り要求がスケジュールされます。デフォルト値は 500 (0.5 秒) です。
write_expire
ミリ秒単位で指定します。この時間内に書き込み要求がスケジュールされます。デフォルト値は 5000 (5 秒) です。
writes_starved
読み取りバッチ数を指定します。指定バッチ数を先に処理してから書き込みバッチをひとつ処理します。高い値を設定するほど読み取りバッチの方が多く優先して処理されます。

8.4.5. CFQ スケジューラーのチューニング

CFQ を使用するとプロセスはリアルタイム、ベストエフォート、アイドルの 3 種類いずれかのクラスに配置されます。リアルタイムのプロセスはすべてベストエフォートのプロセスより先にスケジュールされます。ベストエフォートのプロセスはすべてアイドルのプロセスより先にスケジュールされます。デフォルトではプロセスはベストエフォートのクラスに配置されます。プロセスのクラスを手作業で調整する場合は ionice コマンドを使って行います。
次のパラメーターを使用すると CFQ スケジューラーの動作をさらに調整することができます。パラメーターは /sys/block/devname/queue/iosched ディレクトリー配下にある指定ファイルでデバイスごとに設定を変更します。
back_seek_max
CFQ に後方シークを行わせる最長距離をキロバイトで指定します。デフォルト値は 16 KB です。後方シークは特にパフォーマンスを低下さるため、大きな値の使用は推奨していません。
back_seek_penalty
ディスクヘッドで前方または後方への移動を決定する際に後方シークに対して適用する乗数を指定します。デフォルト値は 2 です。ディスクヘッドの位置が 1024 KB でシステムに等距離の要求がある場合 (1008 KB と 1040 KB など)、back_seek_penalty が後方シークの距離に対して適用されディスクは前方に移動します。
fifo_expire_async
ミリ秒単位の長さで指定します。非同期 (バッファされた書き込み) の要求を処理せず放置する長さです。この時間を過ぎると非同期の処理待ち要求が処理リストに移動されます。デフォルト値は 250 ミリ秒です。
fifo_expire_sync
ミリ業単位の長さで指定します。同期 (読み取りまたは O_DIRECT 書き込み) の要求を処理せず放置する長さです。この時間を過ぎると非同期の処理待ち要求が処理リストに移動されます。デフォルト値は 125 ミリ秒です。
group_idle
このパラメーターはデフォルトでは 0 (無効) に設定されます。1 (有効) に設定すると cfq スケジューラーは制御グループ内で I/O を発行している最後のプロセスでアイドリングします。比例加重 I/O 制御グループを使用し、slice_idle を 0 に設定している (高速ストレージで) 場合に便利です。
group_isolation
このパラメーターはデフォルトでは 0 (無効) に設定されます。1 (有効) に設定するとグループ間をより強力に分離しますが、ランダムな作業負荷および連続した作業負荷の両方に対して公平性が適用されるため処理能力は低減されます。group_isolation を無効にすると (0 の設定) 公平性は連続した作業負荷にのみ適用されます。詳細は /usr/share/doc/kernel-doc-version/Documentation/cgroups/blkio-controller.txt にインストールされているドキュメントをご覧ください。
low_latency
このパラメーターはデフォルトでは 1 (有効) に設定されます。有効の場合、cfq はデバイスで I/O を発行している各プロセスごと最大 300  ミリ秒の待ち時間を与え処理能力より公平性を優先させます。0 (無効) に設定するとターゲットの待ち時間は無視され、各プロセスは完全なタイムスライスを受け取ります。
quantum
cfq がひとつのデバイスに一度に送信できる I/O 要求数を指定します。基本的にはキューの深さを制限します。デフォルト値は 8 です。使用するデバイス側はより深いキューに対応している可能性はありますが、quantum の値を上げると待ち時間も増えます。特に大量の連続する書き込み作業負荷がある場合は顕著です。
slice_async
非同期の I/O 要求を発行している各プロセスに割り当てるタイムスライスの長さを指定します (ミリ秒単位)。デフォルト値は 40 ミリ秒です。
slice_idle
次の要求を待つあいだ cfq にアイドリングを行わせる長さをミリ秒単位で指定します。デフォルト値は 0 (キューまたはサービスツリーレベルではアイドリングを行わない) です。デフォルト値を使用すると外付け RAID ストレージでの処理能力が最適となりますが、シーク動作の総数が増加するため RAID ではない内蔵ストレージの場合には処理能力が低下します。
slice_sync
同期 I/O 要求を発行している各プロセスに割り当てるタイムスライスの長さをしていします (ミリ秒単位)。デフォルト値は 100  ミリ秒です。

8.4.5.1. 高速ストレージの CFQ のチューニング

高速な外付けストレージアレイや SSD などの、シークによる影響をさほど受けないハードウェアの場合、cfq スケジューラーの使用は推奨しません。こうしたストレージで cfq を使用しなければならない場合は、次の設定ファイルを編集する必要があります。
  • /sys/block/devname/queue/iosched/slice_idle を 0 に設定します。
  • /sys/block/devname/queue/iosched/quantum を 64 に設定します。
  • /sys/block/devname/queue/iosched/group_idle を 1 に設定します。

8.4.6. noop スケジューラーのチューニング

noop I/O スケジューラーは、主に高速のストレージを使用する CPU バウンドシステムで使用すると便利です。一般的に、noop I/O スケジューラーは仮想マシンが仮想ディスクに I/O 操作を実行するときに仮想マシンで使用されますが、この使用に限定されません。
noop I/O スケジューラーに固有するチューニング可能なパラメーターはありません。

8.4.7. パフォーマンス改善を目的としたファイルシステムの設定

本セクションでは Red Hat Enterprise Linux 7 で対応している各ファイルシステムに固有のパラメーターのチューニングについて説明しています。パラメーターはストレージデバイスのフォーマット時にパラメーターを設定する場合と、フォーマット化したデバイスのマウント時に設定する場合のいずれかに分けられます。
パフォーマンス低下の原因がファイルの断片化またはリソースの競合にある場合、一般的にはファイルシステムの再設定を行うことでパフォーマンスが改善されます。ただし、アプリケーションの変更を要する場合があります。このような場合にはカスタマーサポートに連絡してください。

8.4.7.1. XFS チューニング

本セクションではフォーマット時とマウント時に XFS ファイルシステムに使用できるチューニングパラメーターのいくつかについて説明します。
ほとんどの作業負荷で XFS のデフォルトフォーマットとマウント設定が適しています。この設定の変更は特定の作業負荷に必要な場合に限ってください。
8.4.7.1.1. フォーマットオプション
フォーマットオプションの詳細については man ページをご覧ください。 
$ man mkfs.xfs
ディレクトリーのブロックサイズ
ディレクトリーのブロックサイズは I/O 動作ごとに読み出したり修正したりするディレクトリー情報の量に影響を与えます。ディレクトリーブロックサイズの最小値はファイルシステムのブロックサイズになります (デフォルト 4 KB)。また最大値は 64 KB になります。
所定のブロックサイズの場合、サイズが大きいディレクトリーの方が小さいディレクトリーより多くの I/O を必要とします。またディレクトリーのブロックサイズが大きいシステムの方が小さいサイズより I/O 動作ごとの処理能力の消費量が高くなります。したがってディレクトリーのサイズ、ディレクトリーブロックサイズ共にできるだけ小さいサイズにすることを推奨しています。
Red Hat では 表8.1「ディレクトリーブロックサイズに対して推奨しているディレクトリーエントリーの最大数」に示すディレクトリーブロックサイズで書き込みが多い作業負荷のエントリー数および読み取りが多い作業負荷のエントリー数を超えない設定を推奨しています。
ディレクトリーのブロックサイズによって異なる読み取りや書き込みの作業に与える影響については XFS 提供のドキュメントを参照してください。
ディレクトリーのブロックサイズを設定するには mkfs.xfs -l オプションを使用します。詳細は mkfs.xfs man ページをご覧ください。
割り当てグループ
割り当てグループは独立した構造でファイルシステムのセクション全体に割り当てられている inode や空領域でインデックスを作成します。各割り当てグループは個別に修正できるため XFS による割り当て動作および割り当て解除の動作は影響するグループが異なる限り同時に行わせることが可能です。したがってファイルシステム内で実行可能な並列動作数は割り当てグループ数と同数になります。ただし、並列動作の実行は動作を行えるプロセッサー数によっても制限されるため割り当てグループ数はシステム内のプロセッサー数と同数またはそれ以上にすることを推奨しています。
ひとつのディレクトリーを複数の割り当てグループで同時に変更することはできません。したがって多数のファイルを作成したり削除するアプリケーションには一つのディレクトリーに全てのファイルを保存させないようにすることを推奨しています。
割り当てグループを設定するには mkfs.xfs -d オプションを使用します。詳細は mkfs.xfs の man ページをご覧ください。
増大に関する制約
フォーマットを行った後にファイルシステムのサイズを大きくする必要が生じた場合 (ハードウェアの追加やシンプロビジョニング)、一旦フォーマットを完了した割り当てグループのサイズは変更できないため初期のファイルレイアウトに十分注意してください。
割り当てグループのサイズ決定は初期のファイルシステム容量ではなく最終的な容量に応じて行ってください。完全に増大し切った状態のファイルシステムの割り当てグループ数はその最大サイズ (1 TB) に達しない限り 200 から 300 以内に収まるようにします。したがって、ほとんどのファイルシステムで増大可能な推奨最大サイズは初期サイズの 10 倍になります。
RAID アレイでファイルシステムを増大させる場合、新しい割り当てグループのヘッダーが追加したストレージに正しく合うようデバイスのサイズを割り当てグループサイズの倍数にする必要があるため更に注意が必要です。また、新しいストレージには既存ストレージと同じ配列を持たせる必要があります。フォーマット後は配列を変更することができないため、同じブロックデバイスに異なる配列のストレージがある場合は最適化が行えません。
inode とインライン属性
inode に十分な領域がある場合は inode への属性名と値の書き込みを XFS で直接行うことができます。こうしたインライン属性の読み出しや変更は余分な I/O が必要ないため別々の属性ブロックの読み出しに比べ 10 倍速くなります。
デフォルトの inode サイズは 256 バイトです。属性の格納に使用できるのはこのうちの約 100 バイトのみ、inode に格納されるデータエクステントポインター数により異なります。ファイルシステムをフォーマットする際に inode サイズを増やすと属性の格納に使用できる領域サイズが増加します。
属性名および属性値はいずれも最大サイズ 254 バイトに制限されています。属性名か属性値のいずれかの長さが 254 バイトを超えるとその属性は別の属性ブロックにプッシュされインラインには格納されなくなります。
inode パラメーターを設定するには mkfs.xfs -i オプションを使用します。詳細は mkfs.xfs の man ページをご覧ください。
RAID
ソフトウェア RAID を使用している場合は mkfs.xfs で自動的にベースとなるハードウェアが適切なストライプ単位とストライプ幅に設定されます。しかし、ハードウェア RAID を使用している場合はハードウェア RAID が必ずしもすべてこの情報をエクスポートするとは限らないため手作業によるストライプ単位とストライプ幅の設定が必要な場合があります。設定を行う場合は mkfs.xfs -d オプションを使用します。詳細は mkfs.xfs の man ページをご覧ください。
ログサイズ
保留中の変更はログに書き込みが行われる同期イベントの発生までメモリー内に集められます。ログのサイズにより同時に処理できる並列の変更数が決定します。また、メモリー内に集めることができる変更の最大サイズも決定するため、ログ記録したデータがディスクに書き込まれる頻度も決定されます。ログが小さいほどデータのディスクへの書き込み頻度は多くなります。ただし、大きいログはそれだけ保留中の変更を記録するため大きくのメモリーを使用するため、メモリーに制限があるシステムの場合はログを大きくしても意味がありません。
ログはベースとなるストライブの単位と合わせるとパフォーマンスが良くなります。つまり、ログがストライプ単位の境界線で開始や終了を行うためです。ログをストライプ単位に合わせるには mkfs.xfs -d オプションを使用します。詳細は mkfs.xfs の man ページをご覧ください。
ログサイズを設定するには以下の mkfs.xfs オプションを使用します。logsize にはログのサイズを入力します。 
# mkfs.xfs -l size=logsize
詳細については mkfs.xfs の man ページをご覧ください。 
$ man mkfs.xfs
ログのストライプ単位
RAID5 や RAID6 レイアウトを使用するストレージデバイスに書き込みを行うログの場合、ストライプ単位の境界線で書き込みの開始や終了を行わせるとパフォーマンスが良くなります (ベースとなるストライプ単位にあわせる)。mkfs.xfs を使用すると自動的に適切なログのストライブ単位への設定が試行されます。ただし、この情報をエクスポートしている RAID デバイスによります。
同期イベントが非常に頻繁に発生するような作業の場合、ログのストライプ単位を大きく設定するとパフォーマンスが低下する場合があります。書き込みが小さい場合、1 ログストライプのサイズを埋める必要があるため待ち時間が増えることがあるためです。ログ書き込みの待ち時間で制約を受ける作業の場合は、Red Hat では、ログのストライプ単位を 1 ブロックに設定して、アラインされていないログの書き込み開始を可能とすることを推奨しています。
対応しているログのストライプ単位の最大サイズはログのバッファサイズの最大値です (256 KB)。これによりベースとなるストレージにログに設定できるストライプ単位より大きいストライプ単位を持たせることができます。この場合、mkfs.xfs により警告が発せられログのストライプ単位には 32 KB が設定されます。
ログのストライプ単位を設定するには以下のいずれかのオプションを使用します。N にはストライプ単位として使用するブロック数を入力します。size にはストライプ単位のサイズを KB で入力します。 
mkfs.xfs -l sunit=Nb
mkfs.xfs -l su=size
詳細については mkfs.xfs の man ページをご覧ください。 
$ man mkfs.xfs
8.4.7.1.2. マウントオプション
Inode 割り当て
1 TB を超えるサイズのファイルシステムの場合、inode 割り当ての使用を強く推奨します。inode64 パラメーターを使用すると XFS が inode とデータをファイルシステム全体に割り当てるよう設定されます。これにより inode の多くがファイルシステムの先頭に割り当てられるのを防ぎ、データの多くがファイルシステムの後方に割り当てられるようになります。
ログのバッファサイズと数
ログバッファが大きいほどログにすべての変更を書き込む際に要する I/O 動作数が少なくなります。大きなログバッファは I/O 使用が多い作業で非揮発性の書き込みキャッシュがないシステムのパフォーマンスを改善します。
ログのバッファサイズは logbsize マウントオプションで設定、ログバッファに格納できる情報量の最大値を定義します。ログのストライプ単位を設定していない場合はバッファの書き込みは最大値より短くなるため、同期の多い作業に対してはログのバッファサイズを小さくする必要はありません。ログバッファのデフォルトサイズは 32 KB です。最大サイズは 256 KB です。これ以外に対応しているサイズは 64 KB、128 KB、または 32 KB から 256 KB のあいだのログストライプ単位の 2 の累乗の倍数です。
ログバッファ数は logbufs マウントオプションで指定します。デフォルト値は 8 ログバッファ (最大) ですが最小では 2 ログバッファを指定することができます。余分なログバッファにメモリーを割り当てる余裕のないメモリー制約のあるシステム以外、通常はログバッファ数を減らす必要はありません。ログバッファ数を減らすとログのパフォーマンスが低下する傾向があります。特にログの I/O 待ち時間に制約のある作業に顕著に見られます。
変更のログ記録の遅延
XFS にはログに変更を書き込む前にメモリーにその変更を集めておくことができるオプションがあります。delaylog パラメーターを使うと頻繁に変更されるメタデータは変更の度にログに書き込むのではなく、定期的なログへの書き込みを行わせることができるようになります。このオプションを使用するとクラッシュで失う可能性のある動作数が増え、またメタデータの追跡に使用するメモリー量も増加します。ただし、メタデータの変更速度やスケーラビリティーが 10 倍向上されるため、fsync、fdatasync、sync などを使ってデータとメタデータのディスクへの書き込みを確実に行わせる場合にデータやメタデータの整合性を損うことがありません。
マウントオプションの詳細は、man xfs を参照してください。

8.4.7.2. ext4 のチューニング

本セクションではフォーマットおよびマウント行う際に使用できる ext4 ファイルシステムのチューニングパラマーターについて説明します。
8.4.7.2.1. フォーマットオプション
Inode テーブルの初期化
ファイルシステム内のすべての inode を初期化するときに、非常に大きいファイルシステムではかなりの時間がかかる場合があります。デフォルトでは、初期化のプロセスは保留になります (レイジー inode テーブルの初期化が有効)。ただし、システムに ext4 ドライバーがない場合は、レイジー inode テーブルの初期化がデフォルトでは無効になります。lazy_itable_init を 1 に設定すると有効になります。このような場合、カーネルのプロセスはファイルシステムがマウントされるとその初期化を続行します。
本セクションではフォーマット時に利用できる一部のオプションについてのみ説明しています。フォーマットのパラメーターの詳細については mkfs.ext4 の man ページをご覧ください。 
$ man mkfs.ext4
8.4.7.2.2. マウントオプション
Inode テーブル初期化の割合
レイジー inode テーブルの初期化が有効になっている場合は init_itable パラメーターの値を指定することで初期化が起こる割合を制御することができます。バックグラウンドでの初期化にかかる時間はほぼ 1 をこのパラメーターの値で割った数値になります。デフォルト値は 10 です。
ファイルの自動同期
既存ファイル名の変更を行ったり、ファイルの短縮や書き直しをすると fsync が正しく動作しないアプリケーションがあります。ext4 の場合、デフォルトではこうした動作の後には必ず自動的にファイルの同期が行われます。ただしこのファイルの自動同期は時間がかかる場合があります。
ここまでの同期を必要としない場合はマウント時に noauto_da_alloc オプションを指定するとこの動作を無効にすることができます。noauto_da_alloc を設定する場合、データの整合性を確保するにはアプリケーション側で明示的に fsync を使用する必要があります。
ジャーナル I/O の優先度
ジャーナル I/O の優先度はデフォルトでは通常の I/O より若干高い 3 です。マウント時に journal_ioprio パラメーターを使ってジャーナル I/O の優先度を制御することができます。journal_ioprio に指定できる値は 0 から 7 の範囲です。0 が最も優先度の高い I/O になります。
本セクションではマウント時に使用できる一部のオプションのみを説明しています。マウントオプションの詳細については mount の man ページをご覧ください。 
$ man mount

8.4.7.3. Btrfs のチューニング

Red Hat Enterprise Linux 7.0 以降、Btrfs がテクノロジープレビューとして提供されています。チューニングは、現在の負荷に基づいてシステムを最適化するために常に行う必要があります。作成およびマウントのオプションについては、『Red Hat Enterprise Linux 7 ストレージ管理ガイド』の「Btrfs」の章を参照してください。

データ圧縮

デフォルトの圧縮アルゴリズムは zlib ですが、特定の負荷がある場合は、圧縮アルゴリズムを変更することが推奨されます。たとえば、ファイル I/O が大きいシングルスレッドの場合は、lzo アルゴリズムを使用することが推奨されます。マウント時オプションは次のとおりです。
  • compress=zlib – 圧縮率が高く、古いカーネルに安全なデフォルトオプション。
  • compress=lzo – 圧縮は高速ですが、zlib よりも低速です。
  • compress=no – 圧縮を無効にします。
  • compress-force=method – 動画やディスクイメージなどの圧縮率が高くないファイルにも圧縮を有効にします。利用可能な方法は zlib と lzo です。
マウントオプションの追加後に作成または変更されたファイルのみが圧縮されます。既存のファイルを圧縮するには、以下で method を zlib または lzo に置き換えたあとでこのコマンドを実行します。 
$ btrfs filesystem defragment -cmethod
lzo を使用してファイルを再圧縮するには、次のコマンドを実行します。 
$ btrfs filesystem defragment -r -v -clzo /

8.4.7.4. GFS2 のチューニング

本セクションではフォーマット時およびマウント時に GFS2 ファイルシステムに対して使用できるチューニングパラメーターの一部について説明しています。
ディレクトリーの間隔
GFS2 マウントポイントの最上位レベルのディレクトリー内に作成されるディレクトリーはすべて自動的に間隔が置かれ、断片化を低減すると共にディレクトリー内での書き込み速度を速めています。最上位レベルのディレクトリー同様別のディレクトリーノ間隔も空ける場合は以下に示すように T 属性でそのディレクトリーに印を付けます。dirname には間隔を空けるディレクトリーのパスを入力します。 
# chattr +T dirname
chattr は e2fsprogs パッケージの一部として提供されます。
競合を減らす
GFS2 はクラスター内のノード間で通信を必要とする可能性があるグローバルロックのメカニズムを使用します。複数のノード間でファイルやディレクトリーの競合が起きるとパフォーマンスの低下を招きます。複数のノード間で共有するファイルシステムの領域をできるだけ小さくすることでキャッシュ間の無効化を招く危険性を最小限に抑えることができます。
このページには機械翻訳が使用されている場合があります (詳細はこちら)。