Problemas de desempenho do NFS / DRBD / XFS

Question

temos um NFS instalado em cima do XFS e drbd que nos proporciona um desempenho horrível (cerca de 1MB / s de leitura / gravação, como mostrado em iostat / iotop) as propriedades do volume xfs são:

meta-data=/dev/drbd0             isize=256    agcount=4, agsize=52427198 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=209708791, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

e temos uma Dell Box com um controlador SAS1068E e 2 discos WD 1TB O volume está atualmente montado com as propriedades:

rw,noatime,nodiratime,attr2,nobarrier,logbufs=8,noquota 

O sistema de arquivos contém toneladas de arquivos pequenos, todos com cerca de 50-100k, espalhados na árvore de diretórios.

Nós tentamos brincar com ReadAhead Values (atualmente desativado) e as opções de montagem do xfs, mas nada pareceu bem-sucedido até agora.

Percebemos no iotop que o kdmflush é o processo que causa o iowait Alguma sugestão para melhorar o desempenho desta configuração?

    

Answer 1

A resposta curta é que o seu sistema de disco está lamentavelmente insuficiente para o que você está tentando fazer.

1 MB / seg é bastante típico do desempenho de E / S aleatório no RAID1 em discos SATA. EXEMPLO: veja a calculadora de invasão de iops anr do wmarow aqui . Colocando dois discos Barracuda ES.2 SATA em um RAID10 (efetivamente o mesmo que um RAID1), definir 100% de gravações com 0% de cache de gravação mostra uma estimativa de 0,57 MB / s de taxa de transferência. O desempenho no mundo real pode ser diferente, mas não será muito diferente.

O fato de você identificar o kdmflush como o processo responsável do kernel reforça isso - se o seu sistema de disco não for capaz de lidar com a carga, isso resultará em mais tempo gasto em iowait neste processo. O kdmflush é o processo de liberação do device-mapper, que lida com o trabalho adiado devido ao carregamento em outro lugar.

Existem algumas maneiras de melhorar isso - obtenha mais discos, obtenha discos melhores ou ative o cache de gravação no controlador.

Se você ativar o cache de gravação, também desejará obter uma BBU. A BBU pode não ser uma opção para o SAS1068E onboard, então você pode ter que obter um controlador PCI-e.

Eu vi um desempenho abismal com o DRBD quando os controladores RAID que eu estava usando (3ware 9550, eu acredito) não tinham o cache de gravação ativado. Seu carregamento de DRBD será principalmente IO aleatório, portanto, o cache de gravação terá um efeito significativo no desempenho.

O SAS1068E é muito baixo e também pode estar contribuindo para o problema. Se você tiver mais discos ou discos melhores, sugiro que você obtenha um controle melhor também.

Uma busca rápida no google revela um desempenho similarmente ruim com o mesmo controlador RAID de modelo que você está usando.

    

Answer 2

1 MB / s parece familiar. Em suma, o seu problema é menos XFS e mais na camada DRBD. Se a replicação de blocos no DRBD for lenta por algum motivo, é perfeitamente razoável que o kdmflush esteja causando muito IOWAIT. Essa velocidade parece que a conexão de rede entre os dois hosts DRBD não está sendo bem negociada.

Mais uma vez, um palpite, mas essa velocidade parece muito com uma conexão TCP sem o TCP Windows funcionando corretamente. Deve ser bastante óbvio em um rastreamento de rede, pois o tráfego será parecido com pacote, ack, pacote, ack, pacote, ack em vez de muitos pacotes e um ack.

Se o iotop estiver sendo executado em um cliente que esteja montando o compartilhamento NFS em vez do próprio servidor NFS, quando for dar uma olhada nessa conexão, bem como na conexão DRBD.

    

Answer 3

Use mais de uma rede de 10 Mbps para a sua replicação DRBD. Sua E / S de disco em um dispositivo DRBD é limitada à velocidade da rede (a menos que você use um protocolo diferente de C, que é o que você faz se quiser que seus dados sejam corrompidos e inúteis). Para testar se a sua rede está causando os problemas, desconecte o primário do secundário e sua taxa de E / S provavelmente irá disparar.