O cliente NFS possui velocidades de leitura e gravação desequilibradas

Question

Eu tenho um NetApp como meu servidor nfs e dois servidores Linux como clientes nfs. O problema é que o mais recente dos dois servidores tem extremamente diferentes velocidades de leitura e gravação sempre que está fazendo leituras e gravações simultaneamente para o servidor nfs. Separadamente, as leituras e gravações ficam ótimas para esse novo servidor. O servidor mais antigo não tem esse problema.

Anfitrião antigo: carpa

Sun Fire x4150 com 8 núcleos, 32 GB de RAM

SLES 9 SP4

Driver de rede: e1000

me@carp:~> uname -a
Linux carp 2.6.5-7.308-smp #1 SMP Mon Dec 10 11:36:40 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux

Novo host: Pepper

HP ProLiant Dl360P Gen8 com 8 núcleos, 64 GB de RAM

CentOS 6.3

Driver de rede: tg3

me@pepper:~> uname -a
Linux pepper 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Vou pular para alguns gráficos que ilustram os testes de leitura / gravação. Heres pimenta e sua leitura / escrita desequilibrada:

eaquiestáacarpa,boaaparência:

Os testes

Aqui estão os testes de leitura / gravação que estou executando. Eu os executei separadamente e eles ficam ótimos em pimenta, mas quando executados juntos (usando o & ), o desempenho da gravação permanece sólido enquanto o desempenho de leitura sofre muito. O arquivo de teste tem o dobro do tamanho da RAM (128 GB para pimenta e 64 GB para carpas).

# write
time dd if=/dev/zero of=/mnt/peppershare/testfile bs=65536 count=2100000 &
# read 
time dd if=/mnt/peppershare/testfile2 of=/dev/null bs=65536 &

O nome do host do servidor NFS é nfsc. Os clientes Linux têm uma NIC dedicada em uma sub-rede separada de qualquer outra coisa (ou seja, sub-rede diferente do IP primário). Cada cliente Linux monta um compartilhamento nfs do servidor nfsc para / mnt / hostnameshare.

nfsiostat

Aqui está uma amostra de 1 minuto durante o teste de simuladores de pimenta:

me@pepper:~> nfsiostat 60

nfsc:/vol/pg003 mounted on /mnt/peppershare:

   op/s         rpc bklog
1742.37            0.00
read:             ops/s            kB/s           kB/op         retrans         avg RTT (ms)    avg exe (ms)
                 49.750         3196.632         64.254        0 (0.0%)           9.304          26.406
write:            ops/s            kB/s           kB/op         retrans         avg RTT (ms)    avg exe (ms)
                1642.933        105628.395       64.293        0 (0.0%)           3.189         86559.380

Ainda não tenho nfsiostat na velha carpa hospedeira, mas estou trabalhando nisso.

/ proc / mounts

me@pepper:~> cat /proc/mounts | grep peppershare 
nfsc:/vol/pg003 /mnt/peppershare nfs rw,noatime,nodiratime,vers=3,rsize=65536,wsize=65536,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.x.x.x,mountvers=3,mountport=4046,mountproto=tcp,local_lock=none,addr=172.x.x.x 0 0

me@carp:~> cat /proc/mounts | grep carpshare 
nfsc:/vol/pg008 /mnt/carpshare nfs rw,v3,rsize=32768,wsize=32768,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,timeo=60000,retrans=3,hard,tcp,lock,addr=nfsc 0 0

Configurações da placa de rede

me@pepper:~> sudo ethtool eth3
Settings for eth3:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 4
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: off
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
        Link detected: yes

me@carp:~> sudo ethtool eth1
Settings for eth1:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: umbg
        Wake-on: g
        Current message level: 0x00000007 (7)
        Link detected: yes

Configurações de descarregamento:

me@pepper:~> sudo ethtool -k eth3
Offload parameters for eth3:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off

me@carp:~> # sudo ethtool -k eth1
Offload parameters for eth1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on

Tudo isso em uma LAN com um comutador gigabit em full duplex entre os clientes nfs e o servidor nfs. Em outra nota, vejo um pouco mais de IO esperar na CPU por pimenta do que carpa, como esperado, já que suspeito que está esperando por operações do nfs.

Eu capturei pacotes com o Wireshark / Ethereal, mas não sou strong nessa área, então não tenho certeza do que procurar. Eu não vejo um monte de pacotes no Wireshark que estão destacados em vermelho / preto, então isso é tudo que eu procurei :). Este fraco desempenho do nfs se manifestou em nossos ambientes Postgres.

Quaisquer outras ideias ou dicas para solução de problemas? Deixe-me saber se posso fornecer mais informações.

UPDATE

Com o comentário do @ ehhite, experimentei dois perfis tuned-adm diferentes, mas sem alterações.

À direita da minha marca vermelha, há mais dois testes. A primeira colina é com o throughput-performance e a segunda é com enterprise-storage .

nfsiostat60doperfildearmazenamentocorporativo

nfsc:/vol/pg003mountedon/mnt/peppershare:op/srpcbklog1758.650.00read:ops/skB/skB/opretransavgRTT(ms)avgexe(ms)51.7503325.14064.2540(0.0%)8.64524.816write:ops/skB/skB/opretransavgRTT(ms)avgexe(ms)1655.183106416.51764.2930(0.0%)3.141159500.441

Atualização2

sysctl -a para pimenta

    

Answer 1

A adição da opção noac nfs mount no fstab foi o marcador de prata. O throughput total não mudou e ainda está em torno de 100 MB / s, mas minhas leituras e gravações estão muito mais equilibradas agora, o que eu tenho que imaginar será um bom presságio para o Postgres e outros aplicativos.

Vocêpodeverquemarqueiosváriostamanhosde"blocos" que usei ao testar, ou seja, as opções de montagem do tamanho do buffer rsize / wsize. Descobri que um tamanho de 8k tinha o melhor rendimento para os testes dd, surpreendentemente.

Estas são as opções de montagens do nfs que estou usando agora, por /proc/mounts :

nfsc:/vol/pg003 /mnt/peppershare nfs rw,sync,noatime,nodiratime,vers=3,rsize=8192,wsize=8192,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,noac,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.x.x.x,mountvers=3,mountport=4046,mountproto=tcp,local_lock=none,addr=172.x.x.x 0 0

FYI, a entrada do homem da opção noac :

ac / noac

Selects whether the client may cache file attributes. If neither option is specified (or if ac is specified), the client caches file attributes.

To improve performance, NFS clients cache file attributes. Every few seconds, an NFS client checks the server's version of each file's attributes for updates. Changes that occur on the server in those small intervals remain undetected until the client checks the server again. The noac option prevents clients from caching file attributes so that applications can more quickly detect file changes on the server.

In addition to preventing the client from caching file attributes, the noac option forces application writes to become synchronous so that local changes to a file become visible on the server immediately. That way, other clients can quickly detect recent writes when they check the file's attributes.

Using the noac option provides greater cache coherence among NFS clients accessing the same files, but it extracts a significant performance penalty. As such, judicious use of file locking is encouraged instead. The DATA AND METADATA COHERENCE section contains a detailed discussion of these trade-offs.

Eu li opiniões divergentes sobre o cache de atributo na web, então meu único pensamento é que é uma opção que é necessária ou que funciona bem com um servidor NetApp NFS e / ou clientes Linux com novos kernels (> 2.6.5). Não vimos esse problema no SLES 9, que tem um kernel 2.6.5.

Eu também leio opiniões mistas sobre rsize / wise, e geralmente você pega o padrão, que atualmente para meus sistemas é 65536, mas 8192 me deu os melhores resultados de testes. Também faremos alguns benchmarks com postgres, então veremos como esses vários tamanhos de buffer se comportam.