アプリケーションの潜在的なボトルネックを追跡するために、NFS サーバーを分析したいと思います。サーバーは SUSE Enterprise Linux 10 を実行しています。
私が知りたいことは以下の通りです。
- どのクライアントがどのファイルにアクセスしているか
- クライアントごとの読み取り/書き込みスループット
- 他のRPC呼び出しによって課せられるオーバーヘッド
- クライアントにサービスを提供するために他の NFS 要求またはディスク I/O を待機する時間
私はすでに統計について知っており/proc/net/rpc/nfsd、実際にブログ投稿それらを詳細に説明することはできません。私が探しているのは、さらに深く掘り下げて、特定のクライアントのパフォーマンスにどのような要因が影響しているかを理解するのに役立つ方法です。NFS サーバーがクラスター上のアプリケーションのパフォーマンスに果たす役割を分析して、最適な最適化方法を考えたいと考えています。
答え1
単なるアイデアですが、wireshark で nfs トラフィックをスニッフィングしてみてください。どのユーザーがどのファイルにアクセスしたかがわかるかもしれません。
tshark -R nfs -i eth0
答え2
利用できるさまざまな *stat ユーティリティの中で、nfsstat は断然最悪だと言わざるを得ません。このユーティリティでは、多数のカウンターを見ることができますが、それだけです。カウンターを 2 回見る場合は、各カウンターがどれだけ変化したかを把握する作業を行う必要があります。変化率を知りたい場合は、サンプル間の秒数で割る必要があります。公平に言えば、nfsstat は、物事がまだかなり粗雑だった何年も前に遡り、出力形式を変更すると多くのものが壊れる可能性があるため、誰も変更したくないという理由で現在では妨げられています。
collectl を使用して nfs を監視する場合、nfsstat 出力がはるかに読みやすい形式で提供されますが、さらに優れているのは、数時間または数日間実行して、バックグラウンドで収集したデータを再生できることです。プロセスが何を実行しているかを確認する要求に関しては、collectl は各プロセスが実行している I/O の量などのプロセス データを収集し、上位の I/O ユーザーを表示して再生することもできます。また、トップ機能をリアルタイムで使用することもできます。
ディスクのテーマセルフを視聴したい場合は、collectl でもそれを実行し、すべてをコーディネートされたディスプレイに表示できます。
チェックしてみてください... -マーク
答え3
収集する（特にそのNFS サブシステム）は非常に優れたユーティリティであり、分析に役立つかもしれませんが、ない要件リストに一致します。一致する Linux ユーティリティは知りません。
（この話題から外れたメモを追加させてください：は要件に合うソフトウェア: SunのDTraceベースの分析 (pdf)- 残念ながらLinuxでは利用できません。ブレンダン・グレッグのブログこれらはこのツールの機能を示しています。
答え4
私の意見では、これはまさに今日のツールの問題を浮き彫りにしています。ここでは、nfsstat、iostat、iotop を含む少なくとも 3 つが言及されています。次に、wireshare と nfsreplay について簡単に触れられています。これは本当に通常の方法のように思えますか? wireshark は独自のカテゴリですが、1 つのツールの方が好みではないでしょうか?
まず、iostat の出力は非常に便利だと思いますが、数字に .00 がたくさんあるため読みにくいです。collectl はまったく同じデータを報告しますが、はるかに見やすい形式になっています。nfsstat について私がどう思っているかは既にご存知でしょうが、collectl はあらゆるデータを再生できるので、「再生」ユーティリティは必要ありません。「iotop」に関しては、collect は I/O を含むものごとに並べ替えたプロセスを表示することもできます。
これで、タイムスタンプも含めたすべての情報が揃いました。より細かい監視間隔が必要な場合は、いつでもサンプリングを 0.1 秒、0.5 秒、またはその間の任意の値に設定できます。ただし、プロセスをこれほど高速に監視するとオーバーヘッドが増加しますが、これはどのプロセス監視ユーティリティでも同様です。
そして最後のボーナスは、collectl で収集したものはすべてスプレッドシートに読み込んで簡単にプロットしたり、collectl-utils の一部である colplot を使用したりできることです。
-マーク