遅いNFS、nfsstat -c:authrefrsh(別名newcreds?)フィールドとは何ですか?


10

(net-fs / nfs-utils-1.2.3-r1、2.6.38.5-zen + Gentoo)

これをグーグルすることは完全な行き止まりのようです。man nfsstatはこの件については何も言わない。私が得ることができる最も近いものは、おそらく以前は「newcreds」であったものについて知ることでした。

newcreds認証情報を更新する必要があった回数。

私の問題は、私がいることであると考え、私はOpenVPNのオーバー基準以下NFSのパフォーマンスを見ていると私はすぐに、それはすべてはnfsstat Googleの検索結果よりも大幅に異なっている見ることができる唯一のことは、私の「呼び出し」フィールドは正確に「authrefrsh」に等しいので、非常に高いことです。すべての検索結果出力には、常にauthrefrshが0または非常に小さい数でした。他のいくつかの側面のデバッグに移る前に、これが何を意味するかを知ることができます。

監視された操作は、NFS共有ポーテージ上にパッケージを出現させています。動作中、emergeは大きなツリーをトラバースしますが、以前の経験では、私が見ているパフォーマンスは異常です。

$ watch -n 1 nfsstat -c

Every 1,0s: nfsstat -c                                Sat May 21 23:04:55 2011

Client rpc stats:
calls      retrans    authrefrsh
308565     2211       308565

Client nfs v3:
null         getattr      setattr      lookup       access       readlink
0         0% 172372   55% 17        0% 30485     9% 36057    11% 26831     8%
read         write        create       mkdir        symlink      mknod
25879     8% 107       0% 21        0% 0         0% 0         0% 0         0%
remove       rmdir        rename       link         readdir      readdirplus
16        0% 0         0% 11        0% 0         0% 0         0% 16668     5%
fsstat       fsinfo       pathconf     commit
3         0% 50        0% 25        0% 2         0%

私はauthrefrshが正確に何であるか(そしてこのスペル、それは意図的なところであるのか)を理解することができません。なぜ私の場合、このように増加するのですか?


遅いNFSと言うとき、NFSのパフォーマンスがより高速であると信じるようになるのは何ですか。遅いと定量化できますか?時刻はWRTパフォーマンスに影響しますか?
Mike Pennington、

「遅いNFS」とは、NFSトラフィックが利用可能な全帯域幅を問題なく使用できることを意味します。これは、VPN経由ではそれほど多くありません(100 kB /秒)。代わりにiftopがtun0で1桁kB /秒のトラフィックしか表示していませんでした。私は問題を、Portageがbinpkg関連のemerge run中に私のPKGDIRに数千のパッケージを記録していることに絞り込んだと信じています。これは非常に遅い操作のようです。これまでの説明から、最善の解決策は、リモートワークステーションでsquashfsポーテージを定期的に更新し、NFSマウントのPKGDIRではなくHTTP binhostを介してbinpkgsを取得することです。
lkraav

これに関する更新はありますか?古いSLES 9サーバーと比較して、新しいSLES 11サーバーとCentOS 6サーバーではNFSクライアントのパフォーマンスが低下していることに気付きました。SLES 9クライアントの方が高速であり、また表示されますがauthrefrsh=0、新しいOS は大量のを表示しauthrefrshます。ここには相関関係があると思いますが、これが何を意味するのかはよくわかりません。
Banjer 2013

どのタイプのNFS認証を行っていますか?AUTH_SYS
Bratchley 2013年

ただし、質問の一部に答えるために、authrefrshは、NFSクライアントが呼び出した回数です。call_refresh()これは、基本的にRPCサーバー(ポートマップ、rpcbindなど)に送信され、サーバーで資格情報を検証します。それが実際にレイテンシの原因であるかどうかを把握する必要があります。あなたがやっているならAUTH_SYS、オーバーヘッドは低く、原因ではないでしょう。
Bratchley 2013年

回答:


5

ソリューションのコメントのRed Hat記事から

これは予想される動作です。

あまり役に立たないが、それが起こる理由も指摘する。

これは、nfs認証が行われる場所に移動するsunrpcパッケージのcommit a17c2153d2e271b0cbacae9bed83b0eaa41db7e1を参照します。コミット全体をコピーして貼り付けることはしませんが、ほとんどの場合、これらの行が変更されます。

-struct rpc_cred *cred = task->tk_msg.rpc_cred;
+struct rpc_cred *cred = task->tk_rqstp->rq_cred;

私の限られた理解は、この行がcall_refresh()が発生する場所に移動することです(後でではなく、より早く)。これは、認証が常に使用されるため、ほとんどすべてのnfs要求によってauthrefrshが増加することを意味します。


1

私は同じことを見ています(vpnを使用していない)-クライアント側でのauthrefrsh ==呼び出し。呼び出しの数が増えてから遅くなり、authrefrshの数が追いつくように思えます。

クライアントRPC統計:

calls      retrans    authrefrsh
261697     0          261697

私も非常に高いiowaitを見ています:

dd if=/dev/zero of=/mnt/omoikane/testfile bs=16k count=2048

(iostatから:)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          4.04    0.00    4.04   91.92    0.00    0.00

私はwiresharkで異常なものを見ることができません-私はnfs3とtcpを使用しています。


1

このリンクから私が理解していることから、authrefresh =呼び出しは問題を示していません。

https://bugzilla.redhat.com/show_bug.cgi?id=785931


UnixとLinuxへようこそ!一般的に、私たちはサイト上の回答がそれ自体で立つことができることを望んでいます-リンクは素晴らしいですが、そのリンクが壊れた場合でも、回答はまだ役立つのに十分な情報が必要です。詳細を含めるには、回答を編集することを検討してください。詳細については、FAQを参照してください
slm

彼らが意味することは、それが問題の原因であるか、それが原因で上昇しているのか確信が持てないということです。「急上昇」は間違いなく問題があることを示しています。同様に、これは主に醜いパフォーマンスの問題と並行して見られます。
Florian Heigl 2016年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.