その他のコマンド
NFS の障害追跡には以下のコマンドを使用します。
nfsstat
このコマンドを使用すると、NFS と RPC 接続について統計情報を収集できます。構文は次のとおりです。
nfsstat [ -cmnrsz ] |
-c を指定すると、クライアント側の情報が表示され、-m を指定すると、NFS マウントされた各ファイルシステムの統計が表示されます。-n では、クライアントとサーバーの両方の NFS 情報が表示され、-r では、RPC の統計が表示されます。-s を指定すると、サーバー側の情報が表示され、-z を指定すると、統計がゼロに設定されます。コマンド行にオプションを指定しないと、-cnrs が使用されます。
新しいソフトウェアやハードウェアを処理環境に追加した場合、サーバー側の統計を収集することが、デバッグにたいへん役立ちます。このコマンドを週に最低 1 度は実行し、履歴を作成するようにしてください。統計を保存しておくと、以前の効率のよい記録になります。
nfsstat コマンドの使用
# 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 の数や 1 週間あたりの calls 数がわかるので、障害が発生した時点を突き止めのに役立ちます。badcallsの値は、クライアントからの不良メッセージの数を表すもので、ネットワーク上のハードウェアにおける問題を突き止められます。
いくつかの接続では、ディスクに対する書き込みアクティビティが発生します。この数値の急激な上昇は障害の可能性を示すものなので、調査が必要です。NFS バージョン 2 の場合、特に注意しなければならない接続は、 setattr、write、create、remove、rename、link、symlink、mkdir、および rmdir です。 NFS バージョン 3 の場合には、commit の値に特に注意します。ある NFS サーバーの commit レベルが、それと同等のサーバーと比較して高い場合は、NFS クライアントに十分なメモリーがあるかどうかを確認してください。サーバーの commit オペレーションの数は、クライアントにリソースがない場合に上昇します。
pstack
このコマンドを使用すると、各プロセスにおけるスタックトレースが表示されます。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 における障害追跡の手順」 を参照してください。
rpcinfo
このコマンドは、システムで動作している 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 サービスの所有者
rpcinfo コマンドの使用
次の例では、サーバーで実行している 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 サービスをチェックしています。
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 における障害追跡の手順」 を参照してください。
- © 2010, Oracle Corporation and/or its affiliates