ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
![]() |
Oracle Solaris のシステム管理 (ネットワークサービス) Oracle Solaris 11 Information Library (日本語) |
パート II ネットワークファイルシステムへのアクセス (トピック)
6. ネットワークファイルシステムへのアクセス (リファレンス)
NFS version 4 におけるファイルシステムの共有解除と再共有
NFS version 4 におけるファイルシステムの名前空間
NFS version 4 における OPEN 共有サポート
NFS version 4 での ACL と nfsmapid
マウント時の -public オプションと NFS URL の意味
NFS version 4 におけるクライアント側フェイルオーバー機能
Web ブラウザの使用と比較した場合の WebNFS の制約
autofs のナビゲーションプロセス開始法 (マスターマップ)
autofs がクライアント用のもっとも近い読み取り専用ファイルを選択する方法 (複数ロケーション)
autofs のネットワークナビゲート法の変更 (マップの変更)
NFS のトラブルシューティングには次のコマンドを使用します。
このコマンドを使用すると、NFS と RPC 接続について統計情報を収集できます。このコマンドの構文は次のとおりです。
nfsstat [ -cmnrsz ]
クライアント側の情報を表示します
NFS マウントされた各ファイルシステムの統計を表示します
クライアント側とサーバー側の両方で、NFS の情報が表示されるように指定します
RPC 統計を表示します
サーバー側の情報を表示します
統計をゼロに設定するように指定します
コマンド行にオプションを指定しないと、-cnrs が使用されます。
新しいソフトウェアやハードウェアを処理環境に追加した場合、サーバー側の統計を収集することが、デバッグにたいへん役立ちます。このコマンドを週に最低 1 度は実行し、履歴を作成するようにしてください。統計を保存しておくと、以前のパフォーマンスの有効な記録となります。
次の例を参照してください。
# nfsstat -s Server rpc: Connection oriented: calls badcalls nullrecv badlen xdrcall dupchecks dupreqs 719949194 0 0 0 0 58478624 33 Connectionless: calls badcalls nullrecv badlen xdrcall dupchecks dupreqs 73753609 0 0 0 0 987278 7254 Server NFSv2: calls badcalls referrals referlinks 25733 0 0 0 Server NFSv3: calls badcalls referrals referlinks 132880073 0 0 0 Server NFSv4: calls badcalls referrals referlinks 488884996 4 0 0 Version 2: (746607 calls) null getattr setattr root lookup readlink read 883 0% 60 0% 45 0% 0 0% 177446 23% 1489 0% 537366 71% wrcache write create remove rename link symlink 0 0% 1105 0% 47 0% 59 0% 28 0% 10 0% 9 0% mkdir rmdir readdir statfs 26 0% 0 0% 27926 3% 108 0% Version 3: (728863853 calls) null getattr setattr lookup access 1365467 0% 496667075 68% 8864191 1% 66510206 9% 19131659 2% readlink read write create mkdir 414705 0% 80123469 10% 18740690 2% 4135195 0% 327059 0% symlink mknod remove rmdir rename 101415 0% 9605 0% 6533288 0% 111810 0% 366267 0% link readdir readdirplus fsstat fsinfo 2572965 0% 519346 0% 2726631 0% 13320640 1% 60161 0% pathconf commit 13181 0% 6248828 0% Version 4: (54871870 calls) null compound 266963 0% 54604907 99% Version 4: (167573814 operations) reserved access close commit 0 0% 2663957 1% 2692328 1% 1166001 0% create delegpurge delegreturn getattr 167423 0% 0 0% 1802019 1% 26405254 15% getfh link lock lockt 11534581 6% 113212 0% 207723 0% 265 0% locku lookup lookupp nverify 230430 0% 11059722 6% 423514 0% 21386866 12% open openattr open_confirm open_downgrade 2835459 1% 4138 0% 18959 0% 3106 0% putfh putpubfh putrootfh read 52606920 31% 0 0% 35776 0% 4325432 2% readdir readlink remove rename 606651 0% 38043 0% 560797 0% 248990 0% renew restorefh savefh secinfo 2330092 1% 8711358 5% 11639329 6% 19384 0% setattr setclientid setclientid_confirm verify 453126 0% 16349 0% 16356 0% 2484 0% write release_lockowner illegal 3247770 1% 0 0% 0 0% Server nfs_acl: Version 2: (694979 calls) null getacl setacl getattr access getxattrdir 0 0% 42358 6% 0 0% 584553 84% 68068 9% 0 0% Version 3: (2465011 calls) null getacl setacl getxattrdir 0 0% 1293312 52% 1131 0% 1170568 47%
このリストは、NFS サーバーの統計の例です。最初の 5 行は RPC に関するもので、残りの部分は NFS のアクティビティーのレポートです。どちらの統計でも、badcalls または calls の平均値、および各週の calls の数がわかるので、問題を特定するのに役立ちます。badcalls 値は、クライアントからの不良メッセージ数を示しています。この値は、ネットワークのハードウェアに問題が発生したことを示す場合があります。
いくつかの接続では、ディスクに対する書き込みアクティビティーが発生します。この数値の急激な上昇は障害の可能性を示すものなので、調査が必要です。NFS version 2 の統計で注意が必要なのは、setattr、write、create、remove、rename、link、symlink、mkdir、および rmdir です。NFS version 3 と version 4 では、commit の値に特に注意します。ある NFS サーバーの commit レベルが、それと同等のサーバーと比較して高い場合は、NFS クライアントに十分なメモリーがあるかどうかを確認してください。サーバーの commit オペレーションの数は、クライアントにリソースがない場合に上昇します。
このコマンドを使用すると、各プロセスのスタックトレースが表示されます。pstack コマンドは、必ずプロセスの所有者、または root として実行してください。pstack を使用して、プロセスがハングアップした場所を判断します。使用できるオプションは、確認するプロセスの PID だけです。proc(1) のマニュアルページを参照してください。
次の例では、実行中の nfsd プロセスを確認しています。
# /usr/bin/pgrep nfsd 243 # /usr/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 ]
rpcbind 処理の統計テーブルを表示します
登録されているすべての RPC プログラムを簡易リストで表示します
特定のトランスポートまたはプロトコルを使用するサービスの情報を表示します
TCP を使用する RPC プログラムを検索します
UDP を使用する RPC プログラムを検索します
サービスに使用するトランスポートまたはプロトコルを選択します
必要な情報の取得元のサーバーのホスト名を選択します
情報の取得対象の RPC プログラムを選択します
hostname を指定しないと、ローカルホスト名が使用されます。progname の代わりに RPC プログラム番号が使用できますが、ユーザーが覚えやすいのは番号よりも名前です。NFS version 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 portmapper superuser 100001 4,3,2 udp6,udp,ticlts rstatd superuser 100003 4,3,2 tcp,udp,tcp6,udp6 nfs 1 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 1 100011 1 udp6,udp,ticlts rquotad superuser 100021 4,3,2,1 tcp,udp,tcp6,udp6 nlockmgr 1 100024 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 status superuser 100068 5,4,3,2 ticlts - superuser 100083 1 ticotsord - superuser 100133 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser 100134 1 ticotsord - superuser 100155 1 ticotsord smserverd superuser 100169 1 ticots,ticotsord,ticlts - superuser 100227 3,2 tcp,udp,tcp6,udp6 nfs_acl 1 100234 1 ticotsord - superuser 390113 1 tcp - superuser 390435 1 tcp - superuser 390436 1 tcp - superuser 1073741824 1 tcp,tcp6 - 1
次の例では、サーバーの特定トランスポートを選択して、RPC サービスの情報を収集する方法について説明しています。最初の例では、TCP で実行されている mountd サービスをチェックしています。2 番目の例では、UDP で実行されている NFS サービスをチェックしています。
% 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
このコマンドは、ネットワーク上のパケットの監視によく使用されます。snoop コマンドは、root で実行する必要があります。このコマンドは、クライアントとサーバーの両方で、ネットワークハードウェアが機能しているかどうかを確認する方法としてよく使用されます。使用できるオプションは多数あります。snoop(1M) のマニュアルページを参照してください。次で、このコマンドの概要を説明します。
snoop [ -d device ] [ -o filename ] [ host hostname ]
ローカルネットワークのインタフェースを指定します
受信したすべてのパケットを指定したファイルに保存します
特定のホストが送受信したパケットを表示します
-d device オプションは、複数のネットワークインタフェースがあるサーバーで特に有効です。ホストの設定以外にも、使用できる式が多数あります。コマンド正規表現を grep で組み合わせることでも、十分に使用できるデータを生成できます。
トラブルシューティングをする場合は、パケットの発信元と送信先のホストが正しいことを確認してください。また、エラーメッセージも調べてください。パケットをファイルに保存すると、データを簡単に参照することができます。
このコマンドを使用すると、プロセスがハングアップしたかどうかを確認できます。truss コマンドは、必ずプロセスの所有者、または root として実行してください。このコマンドに指定できるオプションは多数あります。truss(1) のマニュアルページを参照してください。次で、このコマンドの構文を説明します。
truss [ -t syscall ] -p pid
追跡するシステムコールを選択します
追跡するプロセスの PID を指定します
syscall には、追跡するシステムコールをコンマで区切って指定することもできます。また、syscall の指定を ! で始めると、そのシステムコールは追跡されなくなります。
次の例は、プロセスが新しいクライアントからの接続要求を待っていることを示しています。
# /usr/bin/truss -p 243 poll(0x00024D50, 2, -1) (sleeping...)
これは正常な反応です。新規接続の要求が行われた後でも反応が変わらない場合、そのプロセスはハングアップしている可能性があります。「NFS サービスを再起動する方法」の指示に従ってハングアップの問題を解決してください。ハングアップしたプログラムによって問題が発生しているかどうかを確実に判断するには、「NFS のトラブルシューティングの手順」を参照してください。