Performance nfs Weird: 1 thread melhor que 8, 8 melhor que 2!

5

Estou tentando determinar a causa do baixo desempenho do nfs entre duas máquinas virtuais Xen (cliente e servidor) em execução no mesmo host. Especificamente, a velocidade com a qual eu posso ler seqüencialmente um arquivo de 1 GB no cliente é muito menor do que seria esperado com base na velocidade de conexão de rede medida entre as duas VMs e na velocidade medida de leitura do arquivo diretamente no servidor. As VMs estão executando o Ubuntu 9.04 e o servidor está usando o pacote nfs-kernel-server.

De acordo com vários recursos de ajuste do NFS, alterar o número de threads do nfsd (no meu caso, threads do kernel) pode afetar o desempenho. Normalmente, este conselho é enquadrado em termos de aumentar o número do padrão de 8 em servidores muito usados. O que eu encontro na minha configuração atual:

RPCNFSDCOUNT=8 : (padrão): 13,5 a 30 segundos para gerar um arquivo de 1 GB no cliente, de modo que 35 a 80 MB / s

RPCNFSDCOUNT=16 : 18s para catar o arquivo 60MB / s

RPCNFSDCOUNT=1 : 8-9 segundos para catar o arquivo (!!?!) 125MB / s

RPCNFSDCOUNT=2 : 87s para catar o arquivo 12MB / s

Devo mencionar que o arquivo que estou exportando está em um SSD RevoDrive montado no servidor usando o PCI-passthrough do Xen; no servidor eu posso catar o arquivo em segundos (> 250MB / s). Estou lançando caches no cliente antes de cada teste.

Eu realmente não quero deixar o servidor configurado com apenas um thread, como eu estou supondo que não funcionará tão bem quando houver vários clientes, mas eu posso estar entendendo mal como isso funciona. Eu repeti os testes algumas vezes (mudando a configuração do servidor no meio) e os resultados são bastante consistentes. Então, minha pergunta é: por que o melhor desempenho é com 1 thread?

Algumas outras coisas que tentei mudar, com pouco ou nenhum efeito:

  • aumentando os valores de / proc / sys / net / ipv4 / ipfrag_low_thresh e / proc / sys / net / ipv4 / ipfrag_high_thresh para 512K, 1M do padrão 192K, 256K

  • aumentando o valor de / proc / sys / net / core / rmem_default e / proc / sys / net / core / rmem_max para 1M do padrão de 128K

  • montagem com opções do cliente rsize = 32768, wsize = 32768

A partir da saída do sar -d, eu entendo que os tamanhos reais de leitura indo para o dispositivo subjacente são pequenos (< 100 bytes), mas isso não causa um problema ao ler o arquivo localmente no cliente.

O RevoDrive na verdade expõe dois dispositivos "SATA" / dev / sda e / dev / sdb, em seguida, o dmraid pega um fakeRAID-0 distribuído entre eles que eu montei em / mnt / ssd e então vinculei-o a / export / ssd. Fiz testes locais no meu arquivo usando os dois locais e vejo o bom desempenho mencionado acima. Se as respostas / comentários pedirem mais detalhes, eu os adicionarei.

    
por Joe 21.12.2010 / 00:30

1 resposta

1

Quando uma solicitação do cliente é enviada, ela é transferida para um dos encadeamentos e o resto dos encadeamentos é solicitado a fazer operações de leitura antecipada. A maneira mais rápida de ler um arquivo é fazer um thread fazer isso sequencialmente ... Então, para um arquivo isso é um exagero, e os threads estão, na essência, fazendo mais trabalho para eles mesmos. Mas o que é verdadeiro para um arquivo de 1 leitura de cliente não será necessariamente verdadeiro quando você implantar no mundo real, portanto, siga a fórmula para basear o número de segmentos e o número de leituras de especificações de largura de banda / cpu.

    
por 04.01.2011 / 12:17