コンテンツにスキップ 
XFS NVMe アロケーショングループ、ブロックサイズ、マウントオプション、そしてI/Oスケジューラを、最新のNVMe SSDの特性に合わせて一貫して調整して初めて、その真価が発揮される。 この記事では、AGの並列処理、ログのチューニング、ハードウェアキューの深さが、測定可能なスループットと低レイテンシを実現できるよう、NVMe上でXFSファイルシステムを設計、フォーマット、運用する具体的な方法について解説します。.
中心点
- AG-Design: 並列処理に十分な数のアロケーショングループを選択する一方で、CPUのオーバーヘッドが過大にならないようにする。.
- ブロックサイズ: ファイルシステムブロックを物理的な4Kセクタに紐付けることで、重複アクセスを回避する。.
- マウント・チューニング: デフォルト設定ではなく、noatime、allocsize、logbufs/logbsize を意図的に組み合わせて設定する。.
- スケジューラ: レイテンシの目標に応じて、「none」または「mq‑deadline」をテストし、設定してください。.
- ワークロード: データベース、ストリーミング、AI-Scratchを、適切なAG数とリードアヘッドに合わせて調整する。.
アロケーショングループがNVMeの高速化に寄与する理由
アロケーショングループは、空きブロック、iノード、およびB+木を互いに独立した領域に分割することで、複数のスレッドが同時に処理を行えるようにし、 錠前 アクセス頻度が低い。まさにこの割り当て方式は、多数のキューと高度な並列性によりリクエストを同時に処理し、ブロック競合を低減するNVMeに最適である。 実際には、ハードウェアの並列性を、十分な数のスレッドによる並列割り当てと高速なメタデータ更新に反映させることで、レイテンシのピークを平滑化しています。 性能比較 ファイルシステムのベンチマークでは、XFSが並列アクセス時にどのようにスケーリングするかがよく示される一方で、順次アクセスは引き続き安定して動作します。ただし、バランスが重要です。AGの数が少なすぎると並列割り当てが制限され、多すぎると顕著なパフォーマンスの低下を招きます。 CPU時間.
AGの数と規模を決定する
フォーマット設定の際、私は意図的にAG数を設定しています。通常、1テラバイトあたり数十から64～128 AGの範囲とし、過度な管理負担をかけずに十分な並列性を確保するとともに、 パラレリズム 最大限に活用する。～で mkfs.xfs -f -d agcount=64 /dev/nvme0n1 分布を明示的に指定します。 -d size= あるいは、AGのサイズを調整することも可能です。小さなファイルが多数含まれるワークロードではAGを多めに設定し、大きなシーケンシャルストリームの場合はCPU負荷を抑えるためにAGを少し少なめに設定します。 極端な設定は避けています。なぜなら、非常に小さなAGを多数設定すると、ファイルシステムが満杯になる際に管理負荷が高くなってしまうからです。重要なのは、容量、RAMの搭載量、および典型的なI/O特性に基づいて設定を行い、割り当てが均等に分散されるようにすることです。 部活動 ばらまく。.
ブロックサイズをハードウェアに正しく紐付ける
多くのNVMe SSDは、外部的には512バイトとして提供されているものの、内部では4Kセクタで動作しているため、ファイルシステムのブロックサイズを4096バイトに設定し、それによって内部の読み取り・変更・書き込みサイクルを削減しています。 書き込みアクセス. 書式設定の際には、例えば次のようにしています mkfs.xfs -f -b size=4096 /dev/nvme0n1, 物理セクタサイズが4Kの場合。アライメントが不適切なファイルシステムは、不要な追加I/Oを発生させ、特にランダムな小規模な書き込みにおいて、顕著なパフォーマンス低下を引き起こします。 適切なブロックサイズを設定することで、アクセスが安定し、レイテンシが平滑化され、短いクエリにおいてより高いIOPSが得られます。非常に大規模なシーケンシャル処理が行われる特殊なケースでは、4Kブロックと大きなリードアヘッドを組み合わせて、 スループット率 が増える。
NVMe負荷のマウントオプション
チューニングをしなくてもXFSはすでに高速に動作しますが、適切なマウントオプションを設定することでさらにパフォーマンスを引き出し、不要なメタデータの更新を省くことができます。 読書量. .起動する ノアタイム、ノディラタイム, ワークロードに応じて、より大きな アロケサイズ (例：64M) とし、logバッファを logbufs=8,logbsize=256k メタデータの処理能力を向上させるため。代わりに 破棄 マウントでは、私が案内します fstrim TRIMコマンドがまとめて実行されるように、定期的に実行します。例として、 /etc/fstab こんな感じだ： /dev/nvme0n1 /data xfs noatime,nodiratime,allocsize=64m,logbufs=8,logbsize=256k 0 0. 以下の表では、一般的なオプションとその効果、および典型的な使用例を対応付けており、これにより意思決定を迅速に行い、 構成 記録する。.
| オプション | 効果 | 使用時期 |
|---|---|---|
ノアタイム、ノディラタイム | アクセス時のメタデータ書き込みを削減します | 多数の読み取り処理、Web／分析ワークロード |
allocsize=64m | 割り当てを統合し、断片化を軽減する | 大規模なシーケンシャル書き込みストリーム |
logbufs=8 | メタデータ用の並列ログバッファの増設 | トランザクション負荷、多数の小さな更新 |
logbsize=256k | より大きなログ書き込みブロック | メタデータの処理能力の向上 |
なし 破棄 | 同期TRIMのコストを回避する | その代わりに、定期的に fstrim |
I/Oスケジューラ：none、mq-deadlineなど.
NVMeコントローラはリクエストを効率的に自動で割り振りするため、私はよく なし がベストで、そうすることで オーバーヘッド 低い。レイテンシの要件が厳しいワークロードについては、テストを行っている mq-デッドライン, 、最大スループットがわずかに低下するものの、応答時間を安定させることができるためです。一方、 bfq インタラクティブ性という点では優れているものの、サーバー用NVMeとしてはめったに第一候補にはなりません。私は、測定を行った後に初めて選択を決定します。 fio, 、IOPS、スループット、レイテンシを、読み取り／書き込みおよびランダム／シーケンシャルごとに個別に測定するものです。各オプションを比較検討するための詳細については、この簡潔な記事で詳しく解説します。 I/Oスケジューラガイド, 、本番環境で設定を有効にする前に。.
ワークロードを的確に調整する
コミットの多いデータベースでは、適度なAG数や、アラインメントされた4Kブロックなどが有効であり、, ノータイム そして持ち上げられた ログサイズ, 、メタデータ・トランザクションが迅速に実行されるようにするためです。アナリティクス・ジョブやストリーミング・パイプラインについては、より大きな アロケサイズ また、高いシーケンシャルスループットを実現するには、リードアヘッドを増やす。AI/MLのスクラッチデータや多数の並列ワーカーの場合は、AGの数を増やす方がよい。, ノータイム, 、一括割り当て、および なし スケジューラとして。バックアップやアーカイブ処理は、さらに定期的な fstrim, 、SSDのガベージコレクションの負荷を軽減するためです。各調整については、再現可能な一連の測定結果で検証してから、 デフォルト 恒久的に置き換える。.
よくある症状を素早く見極める
明らかに空き容量があるにもかかわらずXFSが「No space left on device」と表示する場合は、多くの場合、単一のAGが満杯になっているため、データの再配置を行い、, agcount および空きメタデータ領域を確認します。小さなランダム書き込みで予想外に高いレイテンシが発生する場合は、通常、ブロックアライメントが不適切であるか、サイズが小さすぎることを示していると考えます。 アロケサイズ あるいは、メタデータの更新が頻繁すぎる場合などです。このような場合、4Kブロックや、より大きな割り当て単位などが役立ちます。 ノータイム, 、書き込み処理をまとめて実行するためです。ファイルシステムでのCPU負荷が著しく上昇した場合は、特にファイルシステムがほぼ満杯の状態において、AGの数が多すぎた可能性があります。その場合は、再フォーマット時にAGの数を減らすか、パーティションを拡張して 管理 を下げる。
パラメータ一覧：クイックチェック
繰り返し行うセットアップについては、簡単なチェックリストを用意しており、フォーマットを行うたびにこれを順に確認することで、 コンスタンス パフォーマンスを向上させます。まず、NVMeデバイスの物理セクタサイズ、キュー深度、およびコントローラの機能を確認します。その後、AGの数またはサイズを決定し、ブロックサイズを4Kに設定します。 続いて、負荷に適したマウントオプションを定義し、定期的な fstrim. 最後に、I/Oスケジューラのバリエーションをテストし、それぞれのユースケースにおいて最も高速な組み合わせを記録しています。.
NVMe上の新しいXFSの段階的な計画
まず最初に、容量、物理セクタサイズ、一般的なファイルサイズ、および並列スレッド数を調査し、 AGの計画 しっかりと開始します。その後、AG数を調整し、ブロックサイズを4Kに設定し、小さなファイルが多数あると予想される場合はオプションのiノードパラメータを指定してフォーマットを行います。次のステップでは、 ノータイム, よりふさわしい アロケサイズ および最適化されたログパラメータを設定し、結果を以下で確認する fio. 続いてスケジューラの選択が行われますが、私は なし そして mq-デッドライン 比較を行い、その際、IOPSとレイテンシの両方に注意を払う。最後に、モニタリングと計画的な fstrim, 、長期的にパフォーマンスを維持するために 不変 そのままであり、予期せぬ事態が発生しない。.
ホスティング環境における位置づけ
コンテナ、Webスタック、データベースを用いたホスティング環境では、綿密に計画されたXFS構成は、応答時間や スループット 。その際、キューの深さと並列ワーカーの数を考慮し、AGの数とスケジューラを適切に組み合わせるようにしています。NVMeにおけるキューの長さが処理のペースを決定する理由について、詳細な説明は、以下の記事で キューの深さ 作成しました。データ処理量の多いマイクロサービスの場合、私はよく 先行, 、リソース割り当てを統合し、変更のたびに反復的に測定します。高性能なマネージドサーバーやルートサーバー上でアプリケーションを運用している場合は、これにより、低レイテンシ、高い並列性、そして計画しやすい運用環境の恩恵を受けることができます。 エックスエフエス.
Reflink、iノード、メタデータ機能を慎重に選択する
フォーマットを行う際、自分の用途においてCoW/Reflinkが適切かどうかを判断します。 mkfs.xfs -m reflink=1 Copy-on-Write と高速クローン機能を有効にします。これにより、多数のコピーや VM イメージ、ビルド成果物を作成する際に、容量と時間を節約できます。書き込み負荷の高いデータベースの場合は、Reflink を無効にします（reflink=0)、メタデータのオーバーヘッドを削減し、ログの出力を抑えるためです。さらに、私は finobt (Free-Inode-B-Tree) は、多数の iノードに対する割り当て処理を高速化するものであり、最新のツールでは通常、すでに有効になっている。.
仝 iノードのサイズ 私は～について決定する -i size=. 拡張属性（ACL、SELinux、アプリケーションメタデータなど）が多いワークロードの場合、属性がiノード内に収まりやすくなり、別のブロックに分散しないように、512または1024バイトを選択します。例： mkfs.xfs -f -b size=4096 -i size=512 /dev/nvme0n1. 大きなiノードは多少のスペースを消費しますが、メタデータの読み取りや書き込みが頻繁に行われる場合にはアクセス回数を削減できます。次のような機能など bigtime 現代のシステムで利用可能なタイムスタンプの範囲を拡大し、パフォーマンスに目立った悪影響を与えることなく、新規導入時に有効です。次のようなオプションの構造については、 rmapbt 純粋なパフォーマンス向上のためのボリュームについては、主に管理性と検証性を高める一方で、余分な手間がかかるため、私は通常、これらを採用しないようにしています。.
外部ログ、ログサイズ、およびストライプの配置
メタデータが大量に発生するワークロードの場合、ユーザーデータとログ書き込みの競合を最小限に抑えるために、レイテンシが極めて低い別のNVMeドライブ上に専用のログデバイス（ジャーナル）を用意することをお勧めします。私はフォーマット時に次のように設定しています。 -l logdev=/dev/nvme1n1,size= を調整し、バースト発生時にログフォースが頻繁にトリガーされないようログサイズを設定してください（トランザクションのパターンにもよりますが、通常は1～4 GiB）。これと併せて ログバッファ/ログサイズ Mount では、多数の小さなファイルやメタデータの更新が発生する場合、外部ログを使用することでトランザクション時間が著しく安定します。.
NVMeがRAIDまたはデバイスマッパーの背後に配置されている場合、書き込み操作がストライプの境界に正確に合うように、XFSをストライプサイズに合わせて調整します。これはフォーマット時に以下のコマンドで実行します。 -d su=,sw=. その後、以下のコマンドで値を検証します。 xfs_info /mount. 重要：これらのパラメータは、後でフォーマットし直さない限り変更できません。下位レベルのストライピングを行わない単体のNVMeの場合、XFSの自動チューニングに任せます。.
パーティションおよびブロックのアライメントを確認する
フォーマットを行う前に、ファイルシステムのブロックが物理的な4K境界にきれいに収まるよう、パーティションを1 MiB単位でアラインメントして作成します。 parted -a optimal または適切なGPT構成を設定することで、不適切なオフセットの発生を防ぎます。実際の物理セクタサイズおよび論理セクタサイズは、以下のコマンドで確認します。 cat /sys/block/nvme0n1/queue/physical_block_size そして logical_block_size. この基盤が整って初めて、4Kブロックとアロケーション・ハップが本来の威力を発揮する。.
ダイレクトI/O、ページキャッシュ、およびライトバックの制御
独自のキャッシュを管理するデータベースやログストリームに対しては、意図的に O_DIRECT, 、ページキャッシュでの重複キャッシュを防ぐためです。XFSは、同じファイルに対してバッファリングと直接書き込みを同時に混在させない限り、この点で非常に優れたスケーラビリティを発揮します。ストリーミングワークロードの場合、より高い 先行 スループット： blockdev --setra 4096 /dev/nvme0n1 （2 MiBに相当）は、私が測定し、必要に応じて微調整を行う実用的な初期値です。.
システムのバランスを考慮して、ライトバックのしきい値を慎重に調整します。パーセンテージではなく容量単位で設定することで、RAM容量が大きい構成でもダーティデータが過剰に蓄積されるのを防ぎます。例（慎重にテストしてください）：
sysctl -w vm.dirty_background_bytes=268435456
sysctl -w vm.dirty_bytes=2147483648
このようにして、レイテンシを増加させる長時間のフラッシュ波を防ぐようにしています。これらの設定は、再現性を確保し、ディストリビューションのデフォルト設定によって気付かないうちに上書きされないよう、ホストごとに記録しています。.
キューおよびCPUのトポロジーを活用する
NVMeはマルチキューI/Oを採用しています。通常、CPUコアごとに専用のハードウェアキューが存在するため、IRQの割り当てやCPUアフィニティを偶然に任せることはありません。実行中の イラクバランス これがベースラインです。レイテンシに関する特殊なケースでは、 /proc/irq/*/smp_affinity NUMAに近いコアをターゲットに。. cat /sys/block/nvme0n1/queue/scheduler アクティブなスケジューラを表示し、, nr_リクエスト そして rq_affinity クエリがキューに割り振られる方法に影響を与えます。並列処理が高度に進んだワーカーについては、試しに /sys/block/nvme0n1/queue/nr_requests 適度な設定にして、ドライバーに負荷をかけすぎることなく、ピークをうまく吸収できるようにする。.
さらに、NVMeデバイスの割り込み統合（コントローラ機能）を微調整することも可能です。コアリセシングパラメータを適度に引き上げると、IRQ負荷が平滑化されますが、レイテンシの目標値を超過してはなりません。このような調整を行う際は、常に fio‑本番環境に投入される前に、レイテンシのパーセンタイルを確認する。.
クォータ、プロジェクト、および分離
マルチテナント環境では、私は以下を採用しています プロジェクトの割り当て枠, 、荷重と占有スペースを明確に分離しておくためです。私は prjquota そして、以下の方法で境界を管理します xfs_quota ベルベット /etc/projects そして /etc/projid. これにより、例えばビルドディレクトリ、データベースインスタンス、またはクライアントディレクトリに対して、AGの並列処理を制限することなく、厳格な制限を設けることが可能になります。.
多くの大容量ファイルを順次書き込む、インジェスト処理が中心となるディレクトリツリーの場合、 ファイルストリーム‑Allocator を活用すると効果的です。これにより、ディレクトリ内のファイルがより密に配置され、断片化が軽減されます。私は、明らかにストリーミング向けのボリュームに対して、マウントオプションでこの機能を意図的に有効にし、スループットと CPU 負荷への影響を測定しています。.
成長、スナップショット、ライフサイクル
XFSは オンラインで成長する, 、ただし縮小はできない。そのため、将来的にLVM/VMDKを介した拡張が問題なく行えるよう、容量とAGのレイアウトを計画している。 xfs_growfs /mount ファイルシステムを上方向に拡張すると、AG構造もそれに伴って拡大します。次のようなパラメータは sunit そして swidth は固定されています。したがって、RAID構成を変更する場合は、再フォーマットと復元の手順を計画しておく必要があります。.
一貫した スナップ写真 LVM やストレージバックエンドと組み合わせて、ファイルシステムを一時的にフリーズさせます： xfs_freeze -f /mount, スナップショットの作成, xfs_freeze -u /mount. これにより、ログのリプレイが最小限に抑えられ、正常な復元が保証されます。実行時の健全性を確保するため、定期的な xfs_scrub （利用可能な場合）で、そのまま xfs_repair オフライン用ツールとして用意されています。SMARTデータ、, nvme smart-log そして iostat -x これらをウォッチリストに登録し、劣化を早期に検知できるようにしています。.
試験手法と信頼性の高いベースライン
デフォルト設定を上書きする前に、再現性のある測定を行います。まずは明確な fio‑IOPS、スループット、レイテンシを個別に考慮し、ウォームアップフェーズを含むプロファイル：
[global]
ioengine=io_uring
direct=1
runtime=60
time_based=1
group_reporting=1
randrepeat=0
[randread-4k]
filename=/data/testfile
rw=randread
bs=4k
iodepth=64
numjobs=8
[randwrite-4k]
filename=/data/testfile
rw=randwrite
bs=4k
iodepth=64
numjobs=8
[seqread-1m]
filename=/data/testfile
rw=read
bs=1m
iodepth=32
numjobs=4
[seqwrite-1m]
filename=/data/testfile
rw=write
bs=1m
iodepth=32
numjobs=4
目的によって調整します numjobs CPUコアへ、および iodepth 希望するキューの深さに調整します。 重要なのは、一貫性のある境界条件（同じ容量、同一のマウントオプション、適切にトリミングされたボリューム）です。外れ値は、複数回の実行結果の平均値と99パーセンタイルを比較することでフィルタリングしています。これにより、以下の選択肢の間で根拠に基づいた判断を下すことができます。 なし そして mq-デッドライン, 、小さいものと大きいものの間 アロケサイズ あるいは、外部ログが本当に役立つのかという疑問について。.
allocsize、Reflink などの微調整.
アロケサイズ これは便利なツールですが、万能薬ではありません。純粋にランダムな小規模な書き込みの場合、割り当てブロックが大きすぎると不要な書き込み負荷が発生します。そのため、ワークロードに応じて控えめな値を選択し、断片化やレイテンシを確認するようにしています。 Reflinkを有効にしている場合は、CoWが追加のメタデータ処理を伴うため、同じファイル領域での継続的な小規模な更新は避けます。高速なクローンが必要な場合は、ログバッファを大きく設定し、複数のAG内に十分な空き領域と連続した領域を確保するようにしています。.
安全なデフォルト値：バリア、ディスカード、一貫性
執筆の障壁（書き込みバリア) および FUA は、最新のスタックではデフォルトで有効になっています。データ損失のリスクを避けるため、私はこれを変更しません。. ノーバリア たとえ一部のベンチマークで一時的にスコアが向上したとしても、私にとっては論外だ。. 破棄 マウントでの実行は行われず、システム全体の fstrim‑Timerは、アイドル時にTRIMを効率的に実行します。この組み合わせにより、SSDのパフォーマンスを長期的に維持しつつ、安定した低レイテンシを実現できます。.
簡単にまとめると
XFSはアロケーショングループを通じて水平方向にスケーリングし、それによって NVMe 効果的に運用しています。私は、AGの数、ブロックサイズ、マウントオプション、スケジューラを、直感ではなく、ワークロードプロファイルと測定データに基づいて決定しています。小規模なランダム書き込みの場合は、正確なアライメントと軽量なスケジューラが重要であり、大規模なストリームの場合は、むしろ余裕のある アロケサイズ およびリードアヘッド。AGの不均衡や同期的なディスカードといった典型的な課題については、再割り当てと定期的な fstrim. これらの調整項目を体系的に見直すことで、レイテンシを低く抑え、IOPSを向上させ、長期的な安定性を確保できる パフォーマンス.
