Baixo desempenho de gravação do NFS


20

Eu tenho duas máquinas conectadas com 10Gbit Ethernet. Deixe um deles ser servidor NFS e outro será cliente NFs.

Testar a velocidade da rede através de TCP com uma iperftaxa de transferência de ~ 9,8 Gbit / s em ambas as direções, para que a rede esteja OK.

Testando o desempenho do disco do servidor NFS:

dd if=/dev/zero of=/mnt/test/rnd2 count=1000000

O resultado é de ~ 150 MBytes / s, portanto, o disco funciona bem para gravação.

O servidor /etc/exportsé:

/mnt/test 192.168.1.0/24(rw,no_root_squash,insecure,sync,no_subtree_check)

O cliente monta esse compartilhamento no local /mnt/testcom as seguintes opções:

node02:~ # mount | grep nfs
192.168.1.101:/mnt/test on /mnt/test type nfs4 (rw,relatime,sync,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.102,local_lock=none,addr=192.168.1.101)

Se eu tentar baixar um arquivo grande (~ 5 GB) na máquina cliente do compartilhamento NFS, obtive um desempenho de ~ 130-140 MBytes / s, que é próximo ao desempenho do disco local do servidor, portanto é satisfatório.

Mas quando tento fazer upload de um arquivo grande para o compartilhamento NFS, o upload começa em ~ 1,5 Mbytes / s, aumenta lentamente até 18-20 Mbytes / s e para de aumentar. Às vezes, o compartilhamento é interrompido por alguns minutos antes do início do upload, ou seja, o tráfego entre hosts fica próximo de zero e, se eu executar ls /mnt/test, ele não retorna durante um ou dois minutos. Em seguida, o lscomando retorna e o upload é iniciado na velocidade inicial de 1,5 Mb / s.

Quando a velocidade de upload atinge o máximo (18-20 Mbytes / s), eu corro iptraf-nge mostra ~ 190 Mbit / s de tráfego na interface de rede, para que a rede não seja um gargalo aqui, assim como o disco rígido do servidor.

O que eu tentei:

1. Configure um servidor NFS em um terceiro host que esteja conectado apenas a uma NIC Ethernet de 100Mbit. Os resultados são analógicos: o DL mostra bom desempenho e utilização quase total da rede de 100Mbit, o upload não é mais rápido que centenas de kilobytes por segundo, deixando a utilização da rede muito baixa (2,5 Mbit / s, de acordo com iptraf-ng).

2. Tentei ajustar alguns parâmetros do NFS:

  • sync ou async

  • noatime

  • não hard

  • rsizee wsizesão máximos nos meus exemplos, então tentei diminuí-los em várias etapas até 8192

3. Tentei alternar as máquinas cliente e servidor (configure o servidor NFS no antigo cliente e vice-versa). Além disso, existem mais seis servidores com a mesma configuração, então tentei montá-los entre si em diferentes variações. Mesmo resultado.

4. MTU = 9000, MTU = 9000 e agregação de link 802.3ad, agregação de link com MTU = 1500.

5. ajuste de sysctl:

node01:~ # cat /etc/sysctl.conf 
net.core.wmem_max=16777216
net.core.rmem_max=16777216
net.ipv4.tcp_rmem= 10240 873800 16777216
net.ipv4.tcp_wmem= 10240 873800 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.core.netdev_max_backlog = 5000

Mesmo resultado.

6. Monte a partir do host local:

node01:~ # cat /etc/exports
/mnt/test *(rw,no_root_squash,insecure,sync,no_subtree_check)
node01:~ # mount -t nfs -o sync localhost:/mnt/test /mnt/testmount/

E aqui eu obtenho o mesmo resultado: o download de /mnt/testmount/é rápido, o upload para /mnt/testmount/é muito lento, não mais rápido que 22 MBytes / se há um pequeno atraso antes do início da transferência. Isso significa que a pilha de rede funciona perfeitamente e o problema está no NFS?

Tudo isso não ajudou, os resultados não diferiram significativamente da configuração padrão. echo 3 > /proc/sys/vm/drop_cachesfoi executado antes de todos os testes.

A MTU de todos os NICS em todos os três hosts é 1500, nenhum ajuste de rede não padrão executado. O switch Ethernet é o Dell MXL 10 / 40Gbe.

O SO é o CentOS 7.

node01:/mnt/test # uname -a
Linux node01 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Que configurações estou faltando? Como fazer o NFS escrever rapidamente e sem travar?


11
Você tem um caso de teste bastante completo, mas eu tentaria montar no próprio servidor e escrever a partir daí, para descobrir se a pilha NFS ou a rede está com falha. Além disso, tente alternar entre o servidor e o cliente (exportar do cliente, montar no servidor) e também usar um cliente completamente diferente. rastrear os processos servidor / cliente não revelou nada?
Dalibor Karlović

@ DaliborKarlović Tentei todos, exceto o strace, e adicionei informações à pergunta. A montagem do localhost funciona devagar, portanto a pilha e o comutador de rede parecem não estar com defeito. Eu uso o NFS no espaço do kernel e Operation not permittedtentei anexar o strace ao processo do NFS.
Sergey

Suponho que isso significa que você pode descartar completamente a pilha de rede (mas você precisaria anexar strace a ela para ter certeza). Você deve poder rastrear qualquer processo como usuário root se não for atingido por um determinado bug .
Dalibor Karlović

@ DaliborKarlović Certamente eu tento strace como raiz. Sou capaz de me conectar a qualquer processo do espaço do usuário, mas não do kernelspace. Mas que informações posso obter de sua saída? Suponho que produzirá centenas de milhares de linhas de saída se eu anexá-lo ao NFS e começar a carregar. Devo prestar atenção aos valores de retorno diferentes de zero?
Sergey

Você está certo, eu não estava pensando em ser um processo de não-usuário. Eu esperaria ver o que estava fazendo enquanto "trava" no início da transferência; pode ser algo trivial como uma pesquisa reversa de DNS configurada incorretamente.
Dalibor Karlović

Respostas:


3

Você usa a opção de sincronização na sua declaração de exportação. Isso significa que o servidor só confirma operações de gravação depois que elas são realmente gravadas no disco. Como você tem um disco giratório (ou seja, sem SSD), isso requer, em média, pelo menos 1/2 rotação do disco por operação de gravação, que é a causa do abrandamento.

Usando a configuração assíncrona, o servidor reconhece imediatamente a operação de gravação para o cliente quando é processada, mas ainda não gravada no disco. Isso é um pouco mais confiável, por exemplo, no caso de uma falha de energia quando o cliente recebeu uma confirmação por uma operação que não ocorreu. No entanto, ele oferece um grande aumento no desempenho de gravação.

(edit) Acabei de ver que você já testou as opções async vs sync. No entanto, tenho quase certeza de que essa é a causa do seu problema de degradação do desempenho - uma vez tive exatamente a mesma indicação com uma configuração idencitcal. Talvez você teste novamente. Você deu a opção assíncrona na instrução de exportação do servidor E na operação de montagem no cliente ao mesmo tempo?


+1 A explicação mais provável é que a sincronização não foi desativada corretamente.
David Schwartz

2

Pode ser um problema relacionado ao tamanho e latência do pacote. Tente o seguinte:

O relatório confirma seus resultados.


Tentei jumbo frames com MTU = 9000, mas os resultados foram os mesmos. Eu também tentei a agregação de links com o 802.3ad, novamente sem alterações. Então, reverti todas essas configurações para chegar o mais próximo possível do estado padrão. Também tentei ajustar isso net.core.*e net.ipv4.*sysctls, mas talvez tenha feito muito poucas experiências. OK, vou fazer mais alguns testes e reportarei.
Sergey

Tentei mais uma vez ajustar os sysctls no servidor e no cliente, mas isso não ajudou.
Sergey

Você já tentou usar o UDP como protocolo de transporte?
shodanshok

Eu tentei o UDP (proto = udp nas opções de montagem), mas funciona até 1-2 MBytes / s mais lento que o TCP. O resultado foi a mesma montagem do host local e do host remoto.
Sergey

2

http://veerapen.blogspot.com/2011/09/tuning-redhat-enterprise-linux-rhel-54.html

A configuração do planejador Linux em sistemas com RAID de hardware e a alteração do padrão de [cfq] para [noop] oferecem melhorias de E / S.

Use o comando nfsstat, para calcular a porcentagem de leituras / gravações. Defina a taxa de cache do controlador RAID para corresponder.

Para cargas de trabalho pesadas, você precisará aumentar o número de threads do servidor NFS.

Configure os threads nfs para gravar sem demora no disco usando a opção no_delay.

Diga ao kernel do Linux para liberar o mais rápido possível, para que as gravações sejam mantidas o menor possível. No kernel do Linux, a frequência de write-back de páginas sujas pode ser controlada por dois parâmetros.

Para gravações mais rápidas em disco, use a opção data = journal do sistema de arquivos e evite atualizações nos tempos de acesso aos arquivos, que por si só resultam em dados adicionais gravados no disco. Esse modo é o mais rápido quando os dados precisam ser lidos e gravados no disco ao mesmo tempo em que superam todos os outros modos

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.