NFS lento, nfsstat -c: di cosa tratta in dettaglio il campo authrefrsh (aka newcreds?)?

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

Googling questo sembra essere un vicolo cieco completo. man nfsstat non dice molto sull'argomento. Il più vicino che potevo ottenere era scoprire ciò che probabilmente era in precedenza " newcreds ".

newcreds Numero di volte in cui è stato necessario aggiornare le informazioni di autenticazione.

Il mio problema è che penso di vedere prestazioni NFS scadenti su OpenVPN e l'unica cosa che posso immediatamente vedere che è significativamente diversa da tutti i risultati di Google nfsstat, è che il mio campo "chiamate" equivale esattamente a "authrefrsh" ed è quindi molto alto . Tutti gli output dei risultati della ricerca hanno sempre avuto authrefrsh come 0 o un numero molto basso. Prima di passare al debug di alcuni altri aspetti, potrei usare per scoprire cosa significa questo.

Operazione controllata sta emergendo un pacchetto su portage condiviso con NFS. emerge attraversa un grande albero durante il suo funzionamento, ma l'esperienza precedente dice che le prestazioni che sto vedendo sono anormali.

$ 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%

Non riesco a capire esattamente cosa sia authrefrsh (e questa ortografia, è intenzionale tra l'altro?) E perché sta aumentando così nel mio caso?

gentoo nfs openvpn

— lkraav
fonte

Quando dici NFS lento, cosa ti porta a credere che le prestazioni NFS dovrebbero essere più veloci? Puoi quantificare lentamente? L'ora del giorno è importante per le prestazioni WRT?

— Mike Pennington,

"Slow NFS" significa che il traffico NFS non dovrebbe avere problemi ad assorbire l'intera larghezza di banda disponibile, che su VPN non era molto (100 kB / sec). Invece iftop mi stava mostrando il traffico di una sola cifra kB / sec su tun0. Credo di aver ridotto il problema a Portage, indicando un paio di migliaia di pacchetti nel mio PKGDIR durante le esecuzioni emergenti relative a binpkg, il che sembra un'operazione estremamente lenta. Da quello che posso dire fino ad ora, la soluzione migliore potrebbe essere quella di aggiornare regolarmente il portage di squashfs sulle workstation remote e ottenere binpkgs su binhost HTTP, invece di PKGDIR montato su NFS.

— lkraav,

Qualche aggiornamento su questo? Ho notato prestazioni client NFS più scarse con i nuovi server SLES 11 e CentOS 6 rispetto ai nostri vecchi server SLES 9. I client SLES 9 sono più veloci e mostrano anche authrefrsh=0, mentre i nuovi sistemi operativi ne mostrano un sacco authrefrsh. Penso che ci sia una correlazione qui, ma non sono sicuro di cosa significhi tutto ciò.

— Banjer,

Che tipo di autenticazione NFS stai facendo? AUTH_SYS?

— Bratchley

Per rispondere a una parte della tua domanda, authrefrsh è il numero di volte che il client NFS ha chiamato, call_refresh()che in pratica viene inviato al server RPC (portmap, rpcbind, ecc.) E convalida le sue credenziali con il server. Dobbiamo capire se è in realtà la causa della latenza. Se lo stai facendo, AUTH_SYSil sovraccarico è basso e non sarebbe la causa.

— Bratchley

Risposte:

Dalla articolo Red Hat nei commenti la soluzione dice

Questo è un comportamento previsto.

Non molto utile, ma indica anche il motivo per cui accade.

Fa riferimento a commit a17c2153d2e271b0cbacae9bed83b0eaa41db7e1 nel pacchetto sunrpc che si sposta dove avviene l'autenticazione nfs. Non copierò / incollerò l'intero commit ma cambierà principalmente queste righe.

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

La mia comprensione limitata è che questa linea si sposta dove accade call_refresh () (prima piuttosto che dopo). Questo a sua volta significa che la maggior parte di tutte le richieste nfs farà aumentare l'autentrsh poiché l'autenticazione viene sempre utilizzata.

— Rothgar
fonte

Sto vedendo la stessa cosa (non usando vpn) - authrefrsh == chiamate sul lato client. Mi sembra che il numero di chiamate aumenti, quindi rallenta e il numero di authrefrsh raggiunge.

Statistiche rpc client:

calls      retrans    authrefrsh
261697     0          261697

Vedo anche iowait molto alto:

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

(da iostat :)

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

Non riesco a vedere nulla di insolito in WireShark: sto usando nfs3 e tcp.

— Andy
fonte

Da quello che ho capito da questo link, authrefresh = Calls non indica un problema.

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

— Gene O
fonte

Benvenuti in Unix e Linux! In genere ci piace che le risposte sul sito siano in grado di resistere da sole - I collegamenti sono fantastici, ma se quel collegamento si rompe la risposta dovrebbe avere abbastanza informazioni per essere ancora utile. Si prega di considerare la modifica della risposta per includere ulteriori dettagli. Vedi le FAQ per maggiori informazioni.

— slm

ciò che significano è che non sono sicuri che sia la causa del problema o che stiano semplicemente salendo a causa di esso. "skyrocketing" indica sicuramente che le cose non vanno bene. allo stesso modo questo è per lo più visto in parallelo con problemi di perf brutti.

— Florian Heigl,