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 までの数値である)。 処理するディレクトリ名が既に存在する場合、 テストファイルのセットが正しいかをチェックする。 存在しない場合は、ディレクトリを作成して (訳註: テストファイルを) 配置する。
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 には、プログラムの詳細な操作を記述したコメントが書かれている。
nhfsstone を NFS ファイルシステム以外で実行すると、プログラムが永久に動作し続ける。 このプログラムがカーネルの NFS 統計を使って、 充分な呼び出し回数が実行されたかを決定しているためである。
nhfsstone が多くのファイルディスクリプタを使う。 クライアントのカーネルを再設定し、 利用可能なファイルテーブルエントリを増やす必要があるかもしれない。
nhfsstone を使うシェルスクリプトは SIGUSR1 (signal(3) を参照) をキャッチして無視する必要がある。 このシグナルはテストプロセスを同期するのに使われる。 このプロセスをキャッチしないと、 スクリプトを実行しているシェルが kill される。
[man1]
[man2]
[man3]
[man4]
[man5]
[man6]
[man7]
[man8]
[a]
[b]
[c]
[d]
[e]
[f]
[g]
[h]
[i]
[j]
[k]
[l]
[m]
[n]
[o]
[p]
[q]
[r]
[s]
[t]
[u]
[v]
[w]
[x]
[y]
[z]