Diferenças do cliente NFSv3 no desempenho de leitura / gravação

Question

Estou cuidando de alguns servidores que fazem uso relativamente pesado de um arquivador NFS.

Na hora certa, um único servidor envia cerca de 2k leituras + 2k escritas por segundo para o arquivador. De acordo com o nfsiostat nesses momentos, os RTTs de leitura e gravação aumentam dos usuais 5-10ms para 50-100ms para ambos os r / w. O tempo médio de execução de acordo com o nfsiostat é drasticamente diferente para leituras e gravações: lê ca 200ms, escreve entre 100-200s.

Agora, a partir do pouco, eu entendo que o tempo médio do exec no nfsiostat é essencialmente o tempo do kernel RTT + (enfileiramento RPC, etc.). Falando sobre o RPC - Eu vejo exatamente o mesmo comportamento no RH5.8 (RPC backlog ca 5k no crunch) e RH6.3 (RPC backlog 0 o tempo todo).

Então - pergunta: qual poderia ser a razão para o tempo de execução de leitura / gravação do NFS ser tão diferente?

(As chamadas do NFS são feitas pelo aplicativo proprietário para o qual eu não tenho muita visibilidade. O mesmo se aplica ao arquivador (terceirizado da NetApp). O rastreio do kernel provavelmente não será uma opção)

Muito obrigado antecipadamente.

EDIT : para esclarecer e porque recebo algumas respostas sobre o desempenho do NFS em geral - a única parte que realmente me interessa é: de acordo com o nfsiostat doco RTT é "... a duração do tempo em que o kernel do cliente envia a solicitação RPC até o momento em que recebe a resposta. " e o Avg Exe é "... a duração do tempo que o cliente NFS faz a solicitação de RPC para seu kernel até que a solicitação de RPC seja concluída, isso inclui o tempo de RTT acima." ( link ).

Meu (talvez ingênuo) entendimento é que depois do RTT o servidor está pronto, fora da equação. Então, o que o cliente NFS faz que o Avg Exe é tão diferente para leituras / gravações quando o RTT é o mesmo?

    

Answer 1

Com base no cenário descrito, é possível que existam vários fatores contribuintes. As opções sync e async podem ter um impacto significativo no desempenho, assim como a opção nolock ao montar o NFS.

O desempenho também pode ser potencialmente afetado pelos problemas de propriedade e permissões de arquivos relacionados às ACLs dos arquivos e / ou uso das opções root_squash e no_root_squash durante a montagem. Embora se este fosse o caso, provavelmente haveria evidência disso em registros em algum lugar.

Também pode haver problemas ao mover arquivos para dentro e fora da memória. Dependendo da seqüência de operações e da quantidade de memória física e virtual, pode haver muito thrash ocorrendo também.

Se o tráfego estiver em andamento e as operações de arquivo não forem limpas corretamente / suspensas / demoradas demais para concluir os procedimentos de gravação, o número de arquivos abertos no momento pode começar a pressionar o limite suportado pelo kernel. executando:

cat /proc/sys/fs/file-max

Se esse valor for baixo no servidor ou no cliente NFS, talvez valha a pena aumentá-lo para ver se o desempenho melhora. Dependendo do ambiente de rede, a implementação de certas políticas de QoS pode ter um impacto no desempenho (embora provavelmente não seja muito provável).