느린 NFS, nfsstat -c : authrefrsh (일명 newcreds?) 란 무엇입니까?


10

(net-fs / nfs-utils-1.2.3-r1, 2.6.38.5-zen + 젠투)

인터넷 검색은 완전한 막 다른 골목 인 것 같습니다. 남자 nfsstat 는 그 주제에 대해 아무 것도 말하지 않습니다. 내가 얻을 수있는 가장 가까운 것은 아마도 이전에 " 새로운 신용 " 이 무엇인지 알아내는 것이었다 .

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가 무엇인지 정확히 알 수 없으며 (이 철자가 의도적으로 btw입니까?) 왜 내 경우에는 이렇게 증가합니까?


느린 NFS를 말할 때 NFS 성능이 더 빨라야한다고 생각하는 이유는 무엇입니까? 천천히 계량 할 수 있습니까? 시간이 WRT 성능에 중요합니까?
— Mike Pennington

"느린 NFS"는 NFS 트래픽이 가용 한 전체 대역폭을 차지하는 데 문제가 없어야한다는 것을 의미합니다. 대신 iftop은 tun0에서 한 자릿수 kB / sec의 트래픽 만 표시했습니다. binpkg 관련 이머전 실행 중에 PKGDIR에 2 천 개의 패키지를 stat'ing하여 Portage로 문제를 좁혔습니다. 이는 매우 느린 작동 인 것 같습니다. 지금까지 내가 알 수있는 최선의 해결책은 원격 워크 스테이션에서 squashfs 포티지를 정기적으로 업데이트하고 NFS 마운트 PKGDIR 대신 HTTP binhost를 통해 binpkg를 얻는 것입니다.
— lkraav 2018 년

이것에 대한 업데이트? 이전 SLES 9 서버와 비교할 때 최신 SLES 11 및 CentOS 6 서버에서 NFS 클라이언트 성능이 저하 된 것으로 나타났습니다. SLES 9 클라이언트는 더 빠르며, 또한 authrefrsh=0최신 OS는 1 톤을 보여줍니다 authrefrsh. 여기에 상관 관계가 있다고 생각하지만 이것이 무엇을 의미하는지 잘 모르겠습니다.
— Banjer

어떤 종류의 NFS 인증을하고 있습니까? AUTH_SYS?
— Bratchley

질문의 일부에 대답하기 위해 authrefrsh는 NFS 클라이언트가 호출 call_refresh()한 횟수 이며 기본적으로 RPC 서버 (포트 맵, rpcbind 등)로 나가서 서버에서 자격 증명을 확인합니다. 실제로 대기 시간을 일으키는 원인인지 파악해야합니다. 당신이하고 있다면 AUTH_SYS오버 헤드가 낮고 원인이되지 않을 것입니다.
— Bratchley

답변:


5

의견 의 Red Hat 기사 에서 솔루션은 말합니다

이것은 예상되는 동작입니다.

그다지 도움이되지는 않지만 발생하는 이유도 지적합니다.

nfs 인증이 수행되는 위치로 이동하는 sunrpc 패키지에서 커밋 a17c2153d2e271b0cbacae9bed83b0eaa41db7e1을 참조합니다. 전체 커밋을 복사 / 붙여 넣지는 않지만 대부분이 줄을 변경합니다.

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

제한된 이해는이 줄이 call_refresh ()가 발생하는 위치로 이동한다는 것입니다 (나중이 아니라 더 빠름). 이는 인증이 항상 사용됨에 따라 대부분의 모든 nfs 요청으로 인해 authrefrsh가 증가 함을 의미합니다.


1

나는 클라이언트 측에서 authrefrsh == 호출과 같은 것을 보았습니다 (vpn을 사용하지 않음). 통화 수가 증가한 다음 속도가 느려지고 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


유닉스 및 리눅스에 오신 것을 환영합니다! 일반적으로 우리는 사이트에서 스스로 답변을 얻을 수있는 답변을 좋아합니다.-링크는 훌륭하지만 링크가 끊기는 경우에도 도움이 될만한 충분한 정보가 있어야합니다. 자세한 내용을 포함하려면 답변을 수정하십시오. 자세한 내용은 FAQ 를 참조하십시오.
— slm

그들이 의미하는 것은 그것이 문제의 원인인지 확실하지 않기 때문에 확실하지 않다는 것입니다. "폭발"은 확실히 상황이 좋지 않음을 나타냅니다. 마찬가지로 이것은 대부분 못생긴 성능 문제와 병행하여 나타납니다.
— Florian Heigl
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.