KnowHow

技術的なメモを中心にまとめます。
検索にて調べることができます。

NFSサーバのIOテストコマンドのまとめ

登録日 :2025/11/08 14:59
カテゴリ :Linux

ケース1

FLUENTやCFXなどの並列計算を行う場合、計算時間は、数時間〜数日にかかるものもあります。並列数も数ノード〜数十ノードになり、そう言ったジョブが常時20〜30あることを仮定した場合

FLUENTやCFXなどの数時間~数日に及ぶ大規模並列計算を、数ノード~数十ノードで常時20~30ジョブが稼働する環境を想定したfioテストコマンド例は以下のようになります。

想定負荷
並列数が多い並列計算ジョブが同時に20~30程度稼働

大量の読み書きおよびファイル操作が高頻度で発生

大きなファイルの連続読み書きと小さなI/Oの混在

推奨fioテストコマンド例

fio --name=parallel-cfd-workload --ioengine=libaio --direct=1 --rw=randrw --rwmixread=60 \
--bs=16k --iodepth=32 --numjobs=30 --size=20G --runtime=28800 --time_based \
--group_reporting --filename=/mnt/nfs/fio-parallel-testfile

--numjobs=30:30ジョブの並列処理を模擬(数十ジョブ稼働想定)

--bs=16k :CFD解析などでよくある中~大ブロックI/Oの混在を想定

--rw=randrw/--rwmixread=60:読み書き混合。読み60%、書き40%に調整。

--iodepth=32:ジョブあたりのI/O深度(複数I/Oの同時進行)

--size=20G:1ジョブあたり20GBで、合計600GBの負荷

--runtime=28800:8時間の長時間連続実行

--group_reporting:全ジョブの集約結果を表示

解説・考慮点
長期間稼働のジョブが多数動く特性を反映した負荷を模擬

大規模並列解析ではファイル数やアクセスパターンも多様化するので、定期的に複数の違うパターンもテストするとよい

ネットワーク、NFSサーバーのスレッド数、ストレージの帯域/IOPSが十分かチェック

fio結果からジョブ単位/全体のI/Oスループット、IOPS、レイテンシのバランスを確認

このようなテストで得られた結果を基に、パフォーマンスボトルネックやキャパシティプランニング、ジョブのスケジューリング改善に活用できます


ケース2

NFSサーバには200名以上のユーザのホームディレクトリがあります。この中で50名以上がFLUENTやCFXでのプリポスト処理を行っています。この時のIO負荷のテストの場合

NFSサーバに200名以上のユーザホームディレクトリがあり、このうち50名以上がFLUENTやCFXによるプリポスト処理などの大規模かつ高負荷I/Oジョブを同時に行うケースに適したfio負荷テストの提案は下記のようになります。

想定ワークロード特徴
50名以上が数十~数百GBのデータを同時に読み書き

並列数が多く、ランダムアクセスもシーケンシャルアクセスも混在

計算支援用アプリ(FLUENT, CFX)の入出力パターンを模擬

長時間継続的なI/O負荷がかかる

fioテストコマンド提案

fio --name=nfs-cfd-heavy-load --ioengine=libaio --direct=1 --rw=randrw --rwmixread=70 \
--bs=16k --iodepth=64 --numjobs=50 --size=20G --runtime=28800 --time_based \
--group_reporting --filename=/mnt/nfs/fio-testfile

パラメータ解説
--numjobs=50:50並列ジョブ(50ユーザ同時稼働を模擬)

--rw=randrw、--rwmixread=70:読み書き混合で70%読み込み、30%書き込みを設定。CFD計算の特徴を反映。

--bs=16k:中ブロックサイズ、CFDなどのファイルI/Oサイズを想定

--iodepth=64:高いIOキュー深度でパフォーマンスを最大化

--size=20G:1ジョブ20GBのテストファイルサイズ。合計1TB超の負荷に相当。

--runtime=28800:8時間連続実行の長時間負荷を想定。

--group_reporting:全ジョブの統合結果を集約表示。

追加検討点
NFSサーバのnfsdスレッド数を増やし(100以上推奨)、スレッド不足を防止

ネットワーク帯域(10Gbps×2)やマウントオプション(nconnect、MTU9000など)も適切に設定

CPU、ストレージ(SSDや高速RAID)、ネットワーク機器の性能ボトルネックがないか監視すること

運用中の他ジョブの影響も考慮し、ピーク時のパフォーマンス評価を継続的に行う

このテスト構成は、数十ユーザの複雑なCFD系入出力を模擬でき、NFS環境のスケールと耐久性評価に非常に有効です。負荷に耐え得るかを具体的に検証したい場合に推奨されます。必要に応じて具体的なログ解析や改善ポイントのアドバイスも提供します。


ケース3

ユーザによっては解析データを別のファイルサーバやテープ装置に書き出す処理をすることが発生します。複数名の処理が同時に発生する可能性があります。

ユーザが解析データを別のファイルサーバやテープ装置に書き出す処理が不定期に発生し、複数台のストレージに対するI/O負荷を評価したいケースに最適なfio負荷テストコマンドも提案します。

想定シナリオ
NFSのユーザホームディレクトリから解析データを別ファイルサーバやテープ装置へ大量に書き出す

複数の対象ストレージに分散してI/Oが発生

書き込み中心の大容量連続I/Oが主で、ジョブ数は複数、ファイルサイズ数百GB~数TB

提案fioコマンド例(複数ストレージ向け)

fio --name=multi-storage-write --ioengine=libaio --direct=1 --rw=write --bs=1M \
--numjobs=10 --size=200G --runtime=14400 --time_based --filename=/mnt/nfs/fio-tape-file \
--filename_increment=1 --group_reporting

--numjobs=10:10ジョブ並列で複数ストレージへの同時アクセスを模擬(必要に応じ増減)

--rw=write:大容量連続書き込み

--bs=1M:1MB大ブロック書き込みでテープ書き出しを模倣

--size=200G: 1ジョブあたり200GBの書き込み

--runtime=14400:4時間連続実行で長時間負荷

--filename_increment=1:各ジョブが異なるファイル(異なるパス)に書き出し

--group_reporting:全体の集約結果を表示

複数台分散の考え方
実際にはNAS、テープ装置など複数の異なるペリフェラルへの書き込みになるため、

--filenameの部分を変えて複数のマウントポイント/パスに分けて並列負荷をかけるとより現実に近いテストとなります。

これにより、不定期かつ大規模な解析データ書き出し処理がシステム全体へ与える影響を評価でき、ピーク時の性能ボトルネック把握やリソース配分に役立ちます。
必要に応じて詳細な分割・スケジューリングやログ解析支援も可能です。


ケース4(複合条件)

直前に提示した3ケース(FLUENT/CFX)の並列計算、プリポスト処理、そして解析データのデータ移動(書き出しなど)は、ユーザ数が200名以上いるため、同時発生的に起こる可能性が高いです。

FLUENTやCFXのような大規模並列計算において、数百ユーザ環境でプリポスト処理、解析データの書き出しなど複数の高負荷I/O処理が同時に発生する状況を踏まえたfio負荷テストは以下のように設計すると良いです。

想定される負荷の概要
数十~数百の同時並列ジョブ(20〜30は最低想定、さらに多くも想定可)

大きめのブロックI/O(16KB〜1MB程度が混在)

読み取り主体のプリポスト処理、書き込み主体の解析データ書き出しなど混在

長時間の継続的な負荷発生

提案fioテストコマンド例

fio --name=cfd-full-load-test --ioengine=libaio --direct=1 --rw=randrw --rwmixread=65 \
--bs=64k --iodepth=64 --numjobs=50 --size=30G --runtime=28800 --time_based \
--filename=/mnt/nfs/fio-testfile --group_reporting --filename_increment=1

--numjobs=50:50ジョブで同時並列処理を模擬

--rw=randrw と --rwmixread=65:読み65%、書き35%の混合 workload

--bs=64k:中〜大ブロックI/OでCFD解析特有のアクセスを想定

--iodepth=64:高いIOキュー深度で負荷最大化

--size=30G:1ジョブあたり30GBの読み書き(合計約1.5TB)

--runtime=28800:8時間の長時間テスト

--filename_increment=1:ジョブ毎に別ファイルでファイルロック競合を減少

--group_reporting:一括集計表示

運用開始想定のチューニングポイント
NFSサーバのnfsdスレッドは100以上へ増やすこと

ネットワークの10Gbps×2回線の特性を十分活かす設定(MTU9000, nconnectなど)

ストレージはNVMeなど高速SSDを複数用意

CPU、メモリリソースの監視と必要な増強

負荷ピーク時でも他ジョブに影響しないI/Oスケジューリング設計

このテスト負荷と設計で、実運用に見合ったNFS性能評価・チューニングが行え、ユーザ数百人規模でのCFD計算並列処理およびデータ書き出し負荷を十分に再現・検証が可能です。
更に細かな負荷パターンやテストログの詳細解析などもサポート可能です。


Appendix 1

Gneshaのパフォーマンスに関する予測。とりあえず、Thread数の設定を確認しておく。
fioコマンドでThread数4、サイズ100GB、ランダム読み書き70%の高負荷テスト(例のコマンド)を実行した場合、NFS-GaneshaのCPU使用率が異常に高くなるのはよくあることです。

理由は以下です:

GaneshaはユーザースペースでNFS処理を行うためカーネルNFSよりCPU負荷が高めに出やすい

高負荷I/O(大量の同時並列IO、16KBのランダム読み書き)で大量のTCP/IPパケット処理、RPC処理が走りCPUコアを多く使う

特に--iodepth=64や--numjobs=50のような大並列設定ではCPU負荷が激増する

Ganeshaがこの負荷に「耐えられるか」は以下の条件次第です:

NFS-Ganeshaのworker thread数が十分(100以上推奨)あるか

サーバに割り当てられたCPUコア数やメモリが十分か

ネットワークスタックのチューニング(jumboframe、割り込み制御など)が適切か

FSAL(ファイルシステムアブストラクションレイヤー)の実装とストレージ性能が高いか

簡単まとめ
大規模fio負荷はGaneshaのCPU負荷を激増させるため高負荷は自然

CPU・スレッド数・チューニング・ハードウェアで性能対応可能

逆にこれら不足しているとパフォーマンス低下・高レイテンシ・タイムアウトが発生

もし現状でCPU使用率が高すぎる場合は、

Ganeshaのworker thread増加

サーバCPU、メモリ増強

ネットワーク・NFS設定最適化

fio負荷パラメータ見直し

を検討してください。
上記を満たせば、提示コマンドによる高負荷でも耐えうる場合が多いです。


Appendix 2

fioテスト前に推奨されるNFS-Ganeshaの事前設定とチューニング項目は以下の通りです。

  1. worker thread数の増加
    Ganeshaのganesha.confにてNFS { Threads = 100; }のようにworker thread数を増やす。

サーバCPUコア数に合わせて設定し、並列IOを効率処理。

  1. ファイルディスクリプタ上限の引き上げ
    システムのfd上限値を増やす(例:ulimit -n 65536)。

/etc/security/limits.confに永続設定。

  1. ネットワーク設定の最適化
    MTUを9000(ジャンボフレーム)に設定。

NICの割り込み負荷分散(IRQバランス)を適用。

  1. ログレベルと監視
    ganesha.confでログレベルを適切に設定し、負荷時のログ過多を防止。

CPU、メモリ、ネットワーク、ディスクIOのモニタリングを実装。

  1. ファイルシステム層とストレージ最適化
    高速なファイルシステム(例:XFS、ext4のチューニング)。

ストレージ性能を活かすRAID、NVMe使用。

  1. その他
    Ganeshaのバージョンは最新または安定版を利用。

export設定でアクセスコントロールやキャッシュ設定を最適化。

fioテストはジョブ数、iodepth、ブロックサイズなど負荷を段階的に上げながら実施。

これら設定・チューニングにより、大量の並列IOを伴うfio負荷テストや実運用にGaneshaが耐えうる基盤を構築可能です。具体的な設定例やコマンドも必要に応じて提供します。

具体的な確認と設定方法

fioテスト前に推奨されるNFS-Ganeshaの主な設定・チューニング項目ごとの確認方法と設定方法を、わかりやすくまとめます。

  1. worker thread数の確認・設定
    確認方法
    Ganesha設定ファイルを確認(例:/etc/ganesha/ganesha.conf)

ログにworker threadの起動情報がある場合もある

実行中のプロセススレッド数一覧を確認

ps -L -p $(pidof ganesha)

設定方法
設定ファイルganesha.confを編集し、NFSまたはNFSV4ブロックで設定

text
NFS {
Threads = 100;
}
編集後、サービス再起動

sudo systemctl restart nfs-ganesha
  1. ファイルディスクリプタ上限の確認・設定
    確認方法
    現ユーザのfd制限確認
ulimit -n
cat /proc/$(pidof ganesha)/limits | grep "Max open files"

設定方法
一時設定(rootで実行)

ulimit -n 65536

永続設定は/etc/security/limits.confに以下を追加

ganesha_user soft nofile 65536
ganesha_user hard nofile 65536

ganesha_userはGanesha実行ユーザ名

再ログインや再起動後に反映

  1. ネットワークMTU確認・変更
    確認方法
ip link show eth0

設定方法(例:eth0のMTUを9000に設定)

sudo ip link set dev eth0 mtu 9000

永続化はネットワーク設定ファイルで行う

  1. CPU・メモリ使用状況の監視
    確認方法
top
htop
vmstat 1
  1. ファイルシステムのチューニング
    確認方法
mount | grep /mnt/nfs
tune2fs -l /dev/sdXN  # ext4の場合
xfs_info /mnt/nfs     # XFSの場合

設定例(XFSマウント時のオプション)

options noatime,nodiratime,nobarrier

これらの項目を事前にチェック・設定し、fioなどの高負荷テストを行うことでNFS-Ganeshaの安定稼働と性能向上が期待できます。
必要あればそれぞれの設定ファイルの具体例やコマンドもご案内します。