Solaris のシステム管理 (資源管理とネットワークサービス)

その他のコマンド

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 または calls の平均値、および各週の calls の数がわかるので、問題を特定するのに役立ちます。badcalls 値は、クライアントからの不良メッセージ数を示しています。この値は、ネットワークのハードウェアに問題が発生したことを示す場合があります。

いくつかの接続では、ディスクに対する書き込みアクティビティが発生します。この数値の急激な上昇は障害の可能性を示すものなので、調査が必要です。NFS バージョン 2 の統計で注意が必要なのは、setattrwritecreateremoverenamelinksymlinkmkdir、および rmdir です。NFS バージョン 3 では、commit の値に特に注意します。ある NFS サーバーの commit レベルが、それと同等のサーバーと比較して高い場合は、NFS クライアントに十分なメモリーがあるかどうかを確認してください。サーバーの commit オペレーションの数は、クライアントにリソースがない場合に上昇します。

pstack

このコマンドを使用すると、各プロセスのスタックトレースが表示されます。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 の障害追跡の手順を参照してください。

rpcinfo

このコマンドは、システムで動作している 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 オプションを使用できます。

このコマンドを実行すると、次の項目を含むデータを生成することができます。

rpcinfo コマンドの使用

次の例では、サーバーで実行されている 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

このコマンドは、ネットワーク上のパケットの監視によく使用されます。snoop コマンドは、root で実行する必要があります。このコマンドは、クライアントとサーバーの両方で、ネットワークハードウェアが機能しているかどうかを確認する方法としてよく使用されます。使用できるオプションは多数あります。snoop(1M) のマニュアルページを参照してください。以下で、このコマンドの概要を説明します。

snoop [ -d device ] [ -o filename ] [ host hostname ]

-d device

ローカルネットワークのインタフェースを指定する 

-o filename

受信したすべてのパケットを指定したファイルに保存する 

hostname

特定のホストが送受信したパケットを表示する 

-d device オプションは、複数のネットワークインタフェースがあるサーバーで特に有効です。ホストの設定以外にも、使用できる式が多数あります。コマンド式を grep で組み合わせることでも、十分に使用できるデータを生成できます。

障害追跡をする場合は、パケットの発信元と送信先のホストが正しいことを確認してください。また、エラーメッセージも調べてください。パケットをファイルに保存すると、データを簡単に参照することができます。

truss

このコマンドを使用すると、プロセスがハングしたかどうかを確認できます。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 の障害追跡の手順 を参照してください。