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 のアクティビティのレポートです。どちらの統計でも総コール数に対する不良コールの数や 1 週間あたりのコール数がわかるので、障害が発生した時点を突き止めのに役立ちます。不良コールの値は、クライアントからの不良メッセージの数を表すもので、ネットワーク上のハードウェアにおける問題を突き止められます。
いくつかの接続では、ディスクに対する書き込みアクティビティが発生します。この数値の急激な上昇は障害の可能性を示すものなので、調査が必要です。NFS バージョン 2 の場合、特に注意しなければならない接続は、setattr、write、create、remove、rename、link、symlink、mkdir、および rmdir です。NFS バージョン 3 の場合には、commit の値に特に注意します。ある NFSサーバの commit レベルが、それと同等のサーバと比較して高い場合は、NFS クライアントに十分なメモリがあるかどうかを確認してください。サーバの commit オペレーションの数は、クライアントにリソースがない場合に上昇します。
このコマンドを使用すると、各プロセスにおけるスタックトレースが表示されます。root で実行しなければなりません。プロセスがハングした場所を判断するのに使用します。使用できるオプションは、チェックするプロセスの 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 | -u ] [ hostname ] [ progname ]
-m は rpcbind 操作の統計テーブル、-s は登録済みの RPC プログラムすべての簡易リスト、-t は TCP を使う RPC プログラム、-u は UDP を使う RPC プログラムを表示します。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 udp,tcp,ticlts,ticotsord,ticots portmapper superuser 100001 4,3,2 ticlts,udp rstatd superuser 100002 3,2 ticots,ticotsord,tcp,ticlts,udp rusersd superuser 100003 3,2 tcp,udp nfs superuser 100005 3,2,1 ticots,ticotsord,tcp,ticlts,udp mountd superuser 100008 1 ticlts,udp walld superuser 100011 1 ticlts,udp rquotad superuser 100012 1 ticlts,udp sprayd superuser 100021 4,3,2,1 ticots,ticotsord,ticlts,tcp,udp nlockmgr superuser 100024 1 ticots,ticotsord,ticlts,tcp,udp status superuser 100026 1 ticots,ticotsord,ticlts,tcp,udp bootparam superuser 100029 2,1 ticots,ticotsord,ticlts keyserv superuser 100068 4,3,2 tcp,udp cmsd superuser 100078 4 ticots,ticotsord,ticlts kerbd superuser 100083 1 tcp,udp - superuser 100087 11 udp adm_agent superuser 100088 1 udp,tcp - superuser 100089 1 tcp - superuser 100099 1 ticots,ticotsord,ticlts pld superuser 100101 10 tcp,udp event superuser 100104 10 udp sync superuser 100105 10 udp diskinfo superuser 100107 10 udp hostperf superuser 100109 10 udp activity superuser . . 100227 3,2 tcp,udp - superuser 100301 1 ticlts niscachemgr superuser 390100 3 udp - superuser 1342177279 1,2 tcp - 14072
次の例では、サーバの特定トランスポートを使用している 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 サービスをチェックしています。
このコマンドは、ネットワーク上のパケットの監視によく使用されます。root として実行しなければなりません。クライアントとサーバの両方で、ネットワークハードウェアが機能しているかどうかを確認する方法としてよく使用されます。使用できるオプションは多数あります (snoop(1M) のマニュアルページ参照)。以下で、このコマンドの概要を説明します。
snoop [ -d device ] [ -o filename ] [ host hostname ]
-d device には、ローカルネットワークインタフェースを指定します。-o filename には、取り込んだすべてのパケットを保存するファイルを指定します。hostname には、表示するパケットが通過したホストを指定します。
-d device オプションは、複数のネットワークインタフェースがあるサーバで特に有効です。ホストの設定以外にも、使用できる式が多数あります。コマンド式を grep で組み合わせることでも、十分に使用できるデータを生成できます。
障害追跡をする場合は、パケットが通過したホストを確実に突き止めてください。また、エラーメッセージも調べてください。パケットをファイルに保存すると、データの検査が容易になります。
このコマンドを使用すると、プロセスがハングしたかどうかを確認できます。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 の障害追跡手順」 を参照してください。