nhfsstone - システム管理コマンドの説明 - Linux コマンド集 一覧表

nhfsstone - ネットワークファイルシステムのベンチマークプログラム

nhfsstone [ -v ] [ -l load ] [ -p nprocs ] [ -m mixfile ] [ dir ]...

nhfsstone (n-f-s-stone と発音し、"h" は読まない) は NFS クライアント上で人為的な負荷を生成するために使用する。 この負荷には、特定の組み合わせの NFS 操作が含まれる。 このプログラムはサーバーの平均応答時間 (1 回の呼び出し当りのミリ秒数) と 負荷 (1 秒当りの呼び出し回数) を表示する。 このプログラムは、クライアントのカーネルの NFS 統計と所要時間に基づいて、呼び出しパターンを調整する。 負荷は時間または NFS 呼び出しの数を指定することで生成できる。

nhfsstone は進捗状況の監視にカーネルの NFS 統計情報を使用するので、 NFS ファイルシステム以外の性能を計測するのには使えない。

nhfsstone プログラムは、ファイルとディレクトリ操作を使って、 特定のシステムコールに対応する NFS 操作を生成する。 これを行うため、 NFS クライアント側の参照ポートの実装についての知識に基づいた、 いくつかのトリックを使っている。 例えば、長いファイル名を使ってカーネルの名前検索キャッシュを回避させることで、   stat (2) システムコールで NFS lookup 操作を生成する。

NFS 操作の組み合わせは、組み合わせ (mix) ファイルで設定できる。 これは nfsstat (8C)コマンド (下記の "-m" オプションを参照) の出力である。 組み合わせファイルから取得される割合は、 nfsstat で表示される割合ではなく、 NFS 呼び出しの数に基づいて計算される。 組み合わせファイルで 0% となっている操作は、 nhfsstone から呼び出されない。 実際のサーバーにおける負荷の組み合わせでは、特定の NFS 操作の割合が 0% になっているかもしれないが、 呼び出し数は 0 でないことが多い。 nhfsstone は「割合が 0% になっている操作の呼び出し数は、 サーバーの応答に些細な影響しか与えない」と仮定している。

通常は nhfsstone に対して、使用する 2 つ以上のテストディレクトリのリストを指定すべきである (デフォルトではカレントディレクトリを使用する)。 使用するテストディレクトリは、 典型的なサーバーの負荷を現実的にシミュレートするために、 サーバー上の別々のディスクとパーティションに置くべきである。 各 nhfsstone プロセスはディレクトリ <dir>/testdir<n> を扱う (ここで <n> は 0 から nprocs - 1 までの数値である)。 処理するディレクトリ名が既に存在する場合、 テストファイルのセットが正しいかをチェックする。 存在しない場合は、ディレクトリを作成して (訳註: テストファイルを) 配置する。

-v

詳細な出力。

-t secs

指定した実行時間 (単位: 秒) と負荷に基づいて、 calls を設定する。

-c calls

生成する NFS 呼び出しの総数 (デフォルトは 5000)。

-l load

1 秒当りの NFS 呼び出しを生成する負荷 (デフォルトは 30)。

-p nprocs

負荷生成を行うサブプロセスを fork させる数 (デフォルトは 7)。 これは 1 つのマシンで生成できる負荷の総量を最大化するために使用される。 (CPU が遅い、またはメモリ量が少ない) 小さなクライアントマシンでは、 スワッピングを避けるために、プロセス数を少なくした方が良いかもしれない。

-m mixfile

生成する NFS 操作の組み合わせ。 mixfile のフォーマットは nfsstat (8C)プログラムの出力と同じである。 組み合わせファイルは、サーバー上で "nfsstat -s > mixfile" を 実行することで生成できる。 デフォルトの操作の組み合わせは以下の通り: null 0%, getattr 13%, setattr 1%, root 0%, lookup 34%, readlink 8%, read 22%, wrcache 0%, write 15%, create 2%, remove 1%, rename 0%, link 0%, symlink 0%, mkdir 0%, rmdir 0%, readdir 3%, fsstat 1%.

他の全てのベンチマークと同様に、 使用される試験内容を注意深く設定した場合にのみ、 nhfsstone は有用な数値を提供できる。 このプログラムはサーバーを測定するので、 NFS リクエストの生成に制限がないクライアント上で実行すべきである。 クライアントマシンは、速い CPUと優れたイーサーネットインタフェースを備え、 テストの最中にその他の用途で使用すべきではない、という意味である。 Sun-3/50 では、CPU を使いきる前に、1 秒当り 60 NFS 呼び出しが可能である。

nhfsstone は「クライアントで生成された全ての NFS 呼び出しが 1 つのサーバーに対して行われ、全ての NFS 負荷はこのクライアントに依るものである」と仮定している。 この仮定を維持するため、テストの最中は クライアントとサーバーの両方を出来る限り静かにさせて (他の仕事をさせないで) おくべきである。

ネットワークを高負荷で使用していると、 衝突による遅れがサーバー性能の変化を隠してしまうかもしれない。 クライアントとサーバーのどちらかでエラー率が高いと、 失われたパケットや壊れたパケットを再送信するために遅れが生じる可能性がある。 netstat (8C) -i を使ってクライアントとサーバーにおけるエラー率と衝突率を計測できる。

サーバーに対する NFS クライアントの影響を最も正しくシミュレートするには、 サーバーがエクスポートするテストディレクトリを 少なくとも 2 つのディスクパーティションに置いて、 かつそれらのパーティションを出来る限り離すべきである。 dkinfo (8)コマンドを使うと、BSD 系システムにおける ディスクの物理的ジオメトリが分かる。 NFS 操作ではディスク全体へランダムにアクセスする傾向があるので、 全ての nhfsstone のテストディレクトリを 1 つのパーティションに置いたり、 2 つのパーティションが近かったりすると、現実的な結果を示さない。

全てのテストにおいて、テストを繰り返し行って 結果を比較するのは、良い考えである。 呼び出しの数は ( -c オプションを使って) 呼び出し一回当りの時間 (ミリ秒) の変化が 充分小さくなるまで増やすことができる。 呼び出し回数を増やしても助けにならない (訳註: 何の変化も見られない) 場合、 実験の設定に何か問題があるかもしれない。 1 つの一般的な問題としては、 クライアントのテストマシンにメモリが多すぎる場合がある。 メモリが多すぎると、 nhfsstone がクライアントのキャッシュに勝てず、 NFS 操作がサーバーに全く行かなくなる。 キャッシュに問題があると感じた場合は、 -p オプションを使ってプロセス数を増やすことができる。

nhfsstone で生成される数値は、クライアントマシンでのテスト設定を等しくして、 異なるサーバー設定を比較する場合に最も有効である。 実行する毎に nhfsstone のパラメータを変更すると、意味のある比較が出来ない数値が生成される。 たとえば、負荷を生成するプロセスの数は、 クライアントマシンでのコンテクスト切り替えやその他の遅れにより、 計測される応答時間に影響を与えるかもしれない。 一方、 NFS 操作の組み合わせを変更すると、実験の全体的な特性を変えることになる。 その他のクライアント設定についての変更は、 結果が比較できるかに影響を与える可能性がある。 nhfsstone は実際の NFS 統計をサンプリングして、操作の負荷と組み合わせを調整することで、 クライアント設定の違いを補正しようとするが、 いくつかの変更は負荷にも組合わせにも反映されない。 例えば、負荷も組み合わせも変更せず、より速い CPU を組み込んだり、 別の NFS ファイルシステムをマウントすると、応答時間に影響が出るだろう。

異なるサーバー設定を比較する場合、 第 1 段階では、クライアントのテストディレクトリを設定し、 nhfsstone をいくつかの負荷で実行して変動が適度に小さいことを確かめる。 第 2 段階では、興味を持ったいくつかの負荷で nhfsstone を実行し、結果を保存する。 第 3 段階では、サーバーの設定を変更する (メモリを増やす・ディスクコントローラを変更する、など)。 最終段階では、 nhfsstone を同じ負荷で再度実行し、結果を比較する。

ソースコード nhfsstone.c には、プログラムの詳細な操作を記述したコメントが書かれている。

"illegal calls value"

コマンドラインで指定された -c フラグの後の calls 引き数が正の数でない。

"illegal load value"

コマンドラインで指定された -l フラグの後の load 引き数が正の数でない。

"illegal time value"

コマンドラインで指定された -t フラグの後の time 引き数が正の数でない。

"bad mix file"

コマンドラインで指定された -m フラグの後の mixfile ファイル引き数にアクセスできない。

"can't find current directory"

親プロセスがカレントディレクトリのパス名を見つけることができない。 権限の問題を表していることが多い。

"can't fork"

親プロセスが子プロセスを fork できない。 メモリやスワップ空間といったリソースの不足の結果であることが多い。

"can't open log file"

"can't stat log"

"can't truncate log"

"can't write sync file"

"can't write log"

"can't read log"

同期ログファイルの作成・切り詰め・読み込み・書き出しの時に問題が起こった。 親プロセスがログファイルを /tmp に作成し、 子プロセスとの同期や通信に使用する。

"can't open test directory"

"can't create test directory"

"can't cd to test directory"

"wrong permissions on test dir"

"can't stat testfile"

"wrong permissions on testfile"

"can't create rename file"

"can't create subdir"

子プロセスがテストディレクトリの内容を作成・検査するときに問題が起こった。 権限の問題 (例えば、テストディレクトリが 別のユーザーによって作成されている場合) や ファイルシステムがいっぱいである場合が多い。

"bad mix format: unexpected EOF after 'nfs:'"

"bad mix format: can't find 'calls' value"

"bad mix format: unexpected EOF after 'calls'"

"bad mix format: can't find %d op values"

"bad mix format: unexpected EOF"

mix ファイルを解析しているときに問題が起こった。 このファイルの想定されるフォーマットは、 nfsstat (8C)コマンドを "-s" オプションで実行したときの出力と同じである。

"op failed: "

内部的な疑似 NFS 操作の 1 つが失敗した。 操作の名前、例えば read, write, lookup が、失敗の種類と共に表示される。

"select failed"

select システムコールが予期せぬエラーを返した。

nhfsstone を NFS ファイルシステム以外で実行すると、プログラムが永久に動作し続ける。 このプログラムがカーネルの NFS 統計を使って、 充分な呼び出し回数が実行されたかを決定しているためである。

nhfsstone が多くのファイルディスクリプタを使う。 クライアントのカーネルを再設定し、 利用可能なファイルテーブルエントリを増やす必要があるかもしれない。

nhfsstone を使うシェルスクリプトは SIGUSR1 ( signal (3)を参照) をキャッチして無視する必要がある。 このシグナルはテストプロセスを同期するのに使われる。 このプロセスをキャッチしないと、 スクリプトを実行しているシェルが kill される。

/vmunix

システムのネームリスト

/dev/kmem

カーネルの仮想メモリ

./testdir*

プロセス毎のテストディレクトリ

/tmp/nhfsstone%d

プロセスの同期ログファイル