NFS の障害追跡には以下のコマンドを使用します。
このコマンドを使用すると、NFS と RPC 接続について統計情報を収集できます。このコマンドの構文は次のとおりです。
nfsstat [ -cmnrsz ]
-c |
クライアント側の情報を表示する |
-m |
NFS マウントされた各ファイルシステムの統計を表示する |
-n |
クライアント側とサーバー側の両方で、NFS の情報が表示されるように指定する |
-r |
RPC 統計を表示する |
-s |
サーバー側の情報を表示する |
-z |
統計をゼロに設定するように指定する |
コマンド行にオプションを指定しないと、-cnrs が使用されます。
新しいソフトウェアやハードウェアを処理環境に追加した場合、サーバー側の統計を収集することが、デバッグにたいへん役立ちます。このコマンドを週に最低 1 度は実行し、履歴を作成するようにしてください。統計を保存しておくと、以前のパフォーマンスの有効な記録となります。
# nfsstat -s Server rpc: Connection oriented: calls badcalls nullrecv badlen xdrcall dupchecks dupreqs 11420263 0 0 0 0 1428274 19 Connectionless: calls badcalls nullrecv badlen xdrcall dupchecks dupreqs 14569706 0 0 0 0 953332 1601 Server nfs: calls badcalls 24234967 226 Version 2: (13073528 calls) null getattr setattr root lookup readlink read 138612 1% 1192059 9% 45676 0% 0 0% 9300029 71% 9872 0% 1319897 10% wrcache write create remove rename link symlink 0 0% 805444 6% 43417 0% 44951 0% 3831 0% 4758 0% 1490 0% mkdir rmdir readdir statfs 2235 0% 1518 0% 51897 0% 107842 0% Version 3: (11114810 calls) null getattr setattr lookup access readlink read 141059 1% 3911728 35% 181185 1% 3395029 30% 1097018 9% 4777 0% 960503 8% write create mkdir symlink mknod remove rmdir 763996 6% 159257 1% 3997 0% 10532 0% 26 0% 164698 1% 2251 0% rename link readdir readdirplus fsstat fsinfo pathconf 53303 0% 9500 0% 62022 0% 79512 0% 3442 0% 34275 0% 3023 0% commit 73677 0% Server nfs_acl: Version 2: (1579 calls) null getacl setacl getattr access 0 0% 3 0% 0 0% 1000 63% 576 36% Version 3: (45318 calls) null getacl setacl 0 0% 45318 100% 0 0% |
このリストは、NFS サーバーの統計の例です。最初の 5 行は RPC に関するもので、残りの部分は NFS のアクティビティのレポートです。どちらの統計でも、badcalls または calls の平均値、および各週の calls の数がわかるので、問題を特定するのに役立ちます。badcalls 値は、クライアントからの不良メッセージ数を示しています。この値は、ネットワークのハードウェアに問題が発生したことを示す場合があります。
いくつかの接続では、ディスクに対する書き込みアクティビティが発生します。この数値の急激な上昇は障害の可能性を示すものなので、調査が必要です。NFS バージョン 2 の統計で注意が必要なのは、setattr、write、create、remove、rename、link、symlink、mkdir、および rmdir です。NFS バージョン 3 では、commit の値に特に注意します。ある NFS サーバーの commit レベルが、それと同等のサーバーと比較して高い場合は、NFS クライアントに十分なメモリーがあるかどうかを確認してください。サーバーの commit オペレーションの数は、クライアントにリソースがない場合に上昇します。
このコマンドを使用すると、各プロセスのスタックトレースが表示されます。pstack コマンドは、必ずプロセスの所有者、または root が実行してください。 pstack を使用して、プロセスがハングした場所を判断します。使用できるオプションは、チェックするプロセスの PID だけです (proc(1) のマニュアルページを参照)。
以下の例では、実行中の nfsd プロセスをチェックしています。
# /usr/proc/bin/pstack 243 243: /usr/lib/nfs/nfsd -a 16 ef675c04 poll (24d50, 2, ffffffff) 000115dc ???????? (24000, 132c4, 276d8, 1329c, 276d8, 0) 00011390 main (3, efffff14, 0, 0, ffffffff, 400) + 3c8 00010fb0 _start (0, 0, 0, 0, 0, 0) + 5c |
たとえば、プロセスが新規の接続要求を待っていることが示されています。これは正常な反応です。要求が行われた後でもプロセスがポーリングしていることがスタックからわかった場合、そのプロセスはハングしている可能性があります。「NFS サービスを再起動する方法」 の指示に従って問題を解決してください。ハングしたプログラムによって問題が発生しているかどうかを確実に判断するには、「NFS の障害追跡の手順」 を参照してください。
このコマンドは、システムで動作している RPC サービスに関する情報を生成します。RPC サービスの変更にも使用できます。このコマンドには、たくさんのオプションがあります (rpcinfo(1M) のマニュアルページを参照)。以下は、このコマンドで使用できるオプションの構文です。
rpcinfo [ -m | -s ] [ hostname ]
rpcinfo -T transport hostname [ progname ]
rpcinfo [ -t | -u ] [ hostname ] [ progname ]
-m |
rpcbind 処理の統計テーブルを表示する |
-s |
登録されているすべての RPC プログラムを簡易リストで表示する |
-T |
特定のトランスポートまたはプロトコルを使用するサービスの情報を表示する |
-t |
TCP を使用する RPC プログラムを検索する |
-u |
UDP を使用する RPC プログラムを検索する |
transport |
サービスに使用するトランスポートまたはプロトコルを選択する |
hostname |
必要な情報の取得元のサーバーのホスト名を選択する |
progname |
情報の取得対象の RPC プログラムを選択する |
hostname を指定しないと、ローカルホスト名が使用されます。progname の代わりに RPC プログラム番号が使用できますが、ユーザーが覚えやすいのは番号よりも名前です。NFS バージョン 3 が実行されていないシステムでは、-s オプションの代わりに -p オプションを使用できます。
このコマンドを実行すると、次の項目を含むデータを生成することができます。
RPC プログラム番号
特定プログラムのバージョン番号
使用されているトランスポートプロトコル
RPC サービス名
RPC サービスの所有者
次の例では、サーバーで実行されている RPC サービスに関する情報を収集しています。生成されたテキストには sort コマンドのフィルタをかけ、より読みやすくしています。この例では、RPC サービスの数行を省略しています。
% rpcinfo -s bee |sort -n program version(s) netid(s) service owner 100000 2,3,4 udp6,tcp6,udp,tcp,ticlts,ticotsord,ticots rpcbind superuser 100001 4,3,2 ticlts,udp,udp6 rstatd superuser 100002 3,2 ticots,ticotsord,tcp,tcp6,ticlts,udp,udp6 rusersd superuser 100003 3,2 tcp,udp,tcp6,udp6 nfs superuser 100005 3,2,1 ticots,ticotsord,tcp,tcp6,ticlts,udp,udp6 mountd superuser 100007 1,2,3 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 ypbind superuser 100008 1 ticlts,udp,udp6 walld superuser 100011 1 ticlts,udp,udp6 rquotad superuser 100012 1 ticlts,udp,udp6 sprayd superuser 100021 4,3,2,1 tcp,udp,tcp6,udp6 nlockmgr superuser 100024 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 status superuser 100029 3,2,1 ticots,ticotsord,ticlts keyserv superuser 100068 5 tcp,udp cmsd superuser 100083 1 tcp,tcp6 ttdbserverd superuser 100099 3 ticotsord autofs superuser 100133 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser 100134 1 ticotsord tokenring superuser 100155 1 ticots,ticotsord,tcp,tcp6 smserverd superuser 100221 1 tcp,tcp6 - superuser 100227 3,2 tcp,udp,tcp6,udp6 nfs_acl superuser 100229 1 tcp,tcp6 metad superuser 100230 1 tcp,tcp6 metamhd superuser 100231 1 ticots,ticotsord,ticlts - superuser 100232 10 udp,udp6 sadmind superuser 100234 1 ticotsord gssd superuser 100235 1 tcp,tcp6 - superuser 100242 1 tcp,tcp6 metamedd superuser 100249 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser 300326 4 tcp,tcp6 - superuser 300598 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser 390113 1 tcp - unknown 805306368 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser 1289637086 1,5 tcp - 26069 |
次の例では、サーバーの特定トランスポートを選択して、RPC サービスの情報を収集する方法について説明しています。
% rpcinfo -t bee mountd program 100005 version 1 ready and waiting program 100005 version 2 ready and waiting program 100005 version 3 ready and waiting % rpcinfo -u bee nfs program 100003 version 2 ready and waiting program 100003 version 3 ready and waiting |
最初の例では、TCP で実行されている mountd サービスをチェックしています。2 番目の例では、UDP で実行されている NFS サービスをチェックしています。
このコマンドは、ネットワーク上のパケットの監視によく使用されます。snoop コマンドは、root で実行する必要があります。このコマンドは、クライアントとサーバーの両方で、ネットワークハードウェアが機能しているかどうかを確認する方法としてよく使用されます。使用できるオプションは多数あります (snoop(1M) のマニュアルページを参照)。以下で、このコマンドの概要を説明します。
snoop [ -d device ] [ -o filename ] [ host hostname ]
-d device |
ローカルネットワークのインタフェースを指定する |
-o filename |
受信したすべてのパケットを指定したファイルに保存する |
hostname |
特定のホストが送受信したパケットを表示する |
-d device オプションは、複数のネットワークインタフェースがあるサーバーで特に有効です。ホストの設定以外にも、使用できる式が多数あります。コマンド式を grep で組み合わせることでも、十分に使用できるデータを生成できます。
障害追跡をする場合は、パケットの発信元と送信先のホストが正しいことを確認してください。また、エラーメッセージも調べてください。パケットをファイルに保存すると、データを簡単に参照することができます。
このコマンドを使用すると、プロセスがハングしたかどうかを確認できます。truss コマンドは、必ずプロセスの所有者、または root が実行してください。 このコマンドに指定できるオプションは多数あります ( truss(1) のマニュアルページを参照)。以下で、このコマンドの構文を説明します。
truss [ -t syscall ] -p pid
-t syscall |
追跡するシステムコールを選択する |
-p pid |
追跡するプロセスの PID を指定する |
syscall には、追跡するシステムコールをコンマで区切って指定することもできます。また、syscall の指定を ! で始めると、そのシステムコールは追跡されなくなります。
次の例は、プロセスが新しいクライアントからの接続要求を待っていることを示しています。
# /usr/bin/truss -p 243 poll(0x00024D50, 2, -1) (sleeping...) |
これは正常な反応です。新規接続の要求が行われた後でも反応が変わらない場合、そのプロセスはハングしている可能性があります。「NFS サービスを再起動する方法」 の指示に従ってプログラムを修正してください。ハングしたプログラムによって問題が発生しているかどうかを確実に判断するには、「NFS の障害追跡の手順」 を参照してください。