
Situação: Temos um servidor Ubuntu que hospeda três VMs usando KVM. Todos os convidados, bem como o host, precisam acessar os mesmos arquivos em uma determinada subpasta de /var . Assim, a subpasta é exportada via NFS. Nosso problema é que o convidado pode ler/gravar no diretório com apenas metade da velocidade do host. A tabela de exportação fica assim
alice@host:~$ cat /etc/exports
/home/videos 192.168.10.0/24(rw,sync,no_root_squash)
onde o host possui IP 192.168.10.2 e as VMs 192.168.10.1{1..3}. /home/videos é um link simbólico para aquela subpasta em /var. Em particular, é /var/videos/genvids.
Esta é a linha relevante do fstab da VM:
192.168.10.2:/home/videos /mnt/nfs nfs auto,noatime,rsize=4096,wsize=4096 0 0
O disco rígido tem uma taxa de dados sustentada de aproximadamente 155 MB/s, que é verificada pelas saídas de hdparm -tT e também de dd:
alice@host:~$ dd if=/home/videos/4987_1359358478.mp4 of=/dev/null bs=1024k count=300
300+0 records in
300+0 records out
314572800 bytes (315 MB) copied, 2.04579 s, 154 MB/s
Dentro de uma VM as coisas parecem diferentes:
bob@guest:~$ dd if=/mnt/nfs/4959_3184629068.mp4 of=/dev/null bs=1024k count=300
300+0 records in
300+0 records out
314572800 bytes (315 MB) copied, 4.60858 s, 68.3 MB/
Ajustar o tamanho do bloco ao tamanho da página do sistema de arquivos não teve efeito satisfatório:
bob@guest:~$ dd if=/mnt/nfs/4925_1385624470.mp4 of=/dev/null bs=4096 count=100000
100000+0 records in
100000+0 records out
409600000 bytes (410 MB) copied, 5.77247 s, 71.0 MB/s
Consultei várias páginas sobre desempenho do NFS, mais relevante oPerguntas frequentes sobre NFSParte B, e o respectivoAjuste de desempenhoComo. A maioria das dicas não se aplica. Os demais não melhoraram os resultados.Lá são tópicos aquique lidam com desempenho de disco e KVM. No entanto, eles não cobrem o aspecto do NFS.Essethread sim, mas a velocidade da rede não parece ser o fator limitante em nosso caso.
Para dar uma visão completa, este é o conteúdo do etab de exportações com links simbólicos resolvidos e todas as opções de exportação ativas mostradas:
alice@host:~$ cat /var/lib/nfs/etab
/var/videos/genvids 192.168.10.0/24(rw,sync,wdelay,hide,nocrossmnt,secure,
no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,
anonuid=65534,anongid=65534)
O que também me incomoda nesse contexto - e o que não entendo - é a saída do procfile do nfsd:
alice@host:~$ cat /proc/net/rpc/nfsd
...
th 8 0 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
...
Para a terceira coluna e além, eu esperaria valores diferentes de zero após a leitura do disco nas VMs. No entanto, o nfsstat me diz que realmente houve operações de leitura:
alice@host:~$ nfsstat
...
Server nfs v3:
null getattr ...
9 0% 15106 3% ...
read write ...
411971 95% 118 0% ...
...
Então, o assunto é bastante complexo e gostaria de saber onde mais procurar ou se existe uma solução fácil para isso.
Responder1
Acontece que o problema foi mais fácil de resolver do que o esperado. Ajustando otamanhoetamanhoopção no fstab da VM funcionou. A respectiva linha agora é
192.168.10.2:/home/videos /mnt/nfs nfs auto,noatime,rsize=32768,wsize=32768 0 0
Para mim isso não era óbvio, pois eu esperava o melhor desempenho se os valores detamanhoetamanhoatendem ao tamanho do bloco do disco (4096) e não são maiores que o MTU da NIC (9000). Aparentemente, essa suposição estava errada.
É notável que a taxa de dados sustentada exata do disco depende do próprio arquivo: Para dois arquivos semelhantes de tamanho 9 GB observei taxas entre 155 MB/s (arquivo 1) e 140 MB/s (arquivo 2). Portanto, uma taxa de dados reduzida com um arquivo ainda pode resultar em uma taxa de dados total com outro arquivo.