Velocidade de leitura / gravação de RAID diminui gradualmente

Question

Este é, na verdade, um servidor em casa, mas eu senti que era complicado o suficiente para não tê-lo no SuperUser e poderia facilmente se aplicar a uma situação profissional.

Eu tenho um servidor de arquivos rodando Debian (Lenny 5.0.4), e ele tem um XFS LVM no topo de um RAID 5 com o drive OS separado do RAID. Ele também está executando o apache, o samba e o postgresql. Nota: antes que os críticos do RAID5 me crucificassem, eu estou usando o RAID5 porque recebo mais retorno do espaço em disco e ainda tenho alguma tolerância a falhas.

Quando a caixa é iniciada (por meio de desligamento ou reinicialização), a leitura / gravação do compartilhamento samba elimina a conexão de rede gigabit. Com o tempo, isso lentamente degrada, eventualmente, se tornando < 10MB / s; no entanto, quando reinicializado, a velocidade retorna ao máximo da conexão.

Por que isso está acontecendo, e há uma maneira de 'limpar' o que está causando isso sem derrubar o servidor?

Obrigado antecipadamente!

EDIT: Para responder à pergunta do @LapTop006, a saída de cat / proc / mdstat é a mesma depois que ela é reinicializada e quando está lenta:

Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdd1[0] sda[5] sdb[4] sdf[3] sdg1[2] sde1[1]
  4883799680 blocks level 5, 64k chunk, algorithm 2 [6/6] [UUUUUU]

unused devices: <none>

De acordo com o comando frag do xfs_db:

actual 58969, ideal 23904, fragmentation factor 59.46%

EDIT 2: estou usando o kernel padrão do Debian. cat / etc / fstab gera isso para minha unidade do sistema operacional e raid:

# <file system>       <mount point>   <type>  <options>         <dump>  <pass>
/dev/sda1              /               ext3    errors=remount-ro   0       1
/dev/mapper/oomox-lvm  /raid           xfs     defaults            0       2

Para ser honesto, não sou exatamente o maior guru do Linux e não fiz o raid ou lvm via linha de comando (ou seja, mkfs_xfs); Eu usei a configuração da instalação baseada em UI do RAID quando você instalou o sistema operacional pela primeira vez, e usei apenas a linha de comando quando precisei adicionar unidades à matriz.

Quando começar a desacelerar novamente, postarei a saída do iostat.

EDIT 3:

Quando lenta ou rápida, a saída do iostat mostra bytes lidos e escritos igualmente entre todas as unidades. Eu também tentei definir

socket options = TCP_NODELAY

na configuração do samba de acordo com o conselho do @Avery Payne, mas ainda era lento. No entanto, pelo menos o problema foi reduzido, uma vez que apenas reiniciar o samba resolveu o problema. Isso é bem estranho, já que eu nunca tive esse problema até recentemente.

EDIÇÃO FINAL: Eu tentei a sugestão do @David Spillett de correr

time dd if=/dev/sda of=/dev/null

Para cada unidade, quando demora a ver se há alguma diferença para quando é rápida e não há. Então, o problema é claramente com o Samba.

Eu estou concedendo a resposta correta para @Avery Payne. Embora a resposta de @David Spillett tenha um ótimo esquema de técnicas de solução de problemas, tecnicamente @Avery Payne me apontou na direção mais correta de resolver esse problema. Vou postar se eu encontrar a solução final para isso.

Obrigado a todos!

    

Answer 1

When the box is started (via shutdown or reboot) reading/writing to it's samba share maxes out the gigabit network connection. Over time, this slowly degrades eventually becoming < 10MB/s; however, when rebooted the speed returns to maxing out the connection.

O problema provavelmente não está no sistema operacional ou no hardware, mas na sua configuração do Samba. Você tem suas opções de TCP definidas corretamente no Samba? Existem algumas opções que farão com que o acesso do cliente seja degradado, causando lentidão nos fluxos TCP ou sobrecarga adicional.

O seu RAID e fstab parecem bem.

Acompanhamento para comentar (s):

Em smb.conf você deve ter a seguinte linha em sua seção global:

socket options = TCP_NODELAY

Mais informações podem ser encontradas na seção Samba Performance Tuning de suas FAQs

link

    

Answer 2

Alguns pensamentos que podem ajudar você a decidir algumas coisas:

Você poderia ter um vazamento de memória em algum lugar que está resultando na troca de máquina como um louco depois de um tempo? Verifique free -m quando o problema é aparente.

Além disso, você poderia ter um problema com o software RAID decidir que precisa executar uma ressincronização? Verifique se há /proc/mdstat quando você está experimentando lentidão para verificar isso (embora eu não espere que isso seja resolvido por uma reinicialização - qualquer ressincronização desse tipo deve ser reiniciada após a reinicialização).

Você descartou problemas locais de E / S? Quão rápido o array executa para processos locais quando o problema é aparente. Se os processos locais não podem acessar o array em velocidades normais, então o Samba não é o problema (por outro lado, se eles podem quando os acessos de rede não podem suportar o contrário). Se as unidades parecerem lentas localmente, é possível procurar por mais evidências, verificando se a rede não está lenta , bem como nas unidades , executando testes simples com netcat e pv (consulte link ou procure por "netcat speedtest" para outros exemplos.

Poderia ser um problema de firmware com uma ou mais das suas unidades? Verifique se houve atualizações desse tipo do fabricante. Além disso, poderia ser apenas uma unidade que está jogando estranhamente. Quando o problema de velocidade se apresentar tente time dd if=/dev/sda of=/dev/null , repetindo para cada drive algumas vezes e obtendo uma média. Se uma unidade sair muito mais lenta que as outras, talvez tenha um problema e precise ser substituída (ou uma atualização de firmware, se houver algum problema conhecido).

Você descartou um problema na placa de rede (hardware ou driver)? Você poderia tentar trocá-lo por outra placa Gbit (com um chipset diferente) para ver se isso faz diferença.

Se o problema parece ser o Samba e não a matriz RAID, placa de rede ou qualquer outra coisa, é necessária uma reinicialização completa para corrigir o problema ou simplesmente reiniciar o Samba o suficiente? (Ou reiniciar o Samba e o winbindd se o servidor participar de um domínio dessa maneira?)

Uma nota lateral no comentário do seu RAID5:

O principal problema com o RAID5 é o desempenho de gravação, especialmente para números significativos de pequenas gravações. Isso pode matar o desempenho de um trabalho pesado de banco de dados, mas para uma função básica de servidor de arquivos (que sua situação parece) que gasta a maior parte do tempo realizando leituras em massa, ele tem pouco ou nenhum efeito perceptível na maior parte. Se você achar que o desempenho de gravação já é um problema, tente o novo driver RAID10 brilhante no modo de 3 unidades (desempenho de leitura semelhante ao RAID5 de 3 unidades _{^{(ou 2 unidades RAID0)}} mas escrever desempenho mais parecido com o de um RAID1 de 2 unidades, mantendo a mesma redundância que qualquer unidade pode morrer de cada vez). O driver RAID10 ainda pode ser classificado como "experimental" em todos os kernels, exceto os mais novos.

O outro problema com o RAID5 é quanto tempo leva para reconstruir o array se uma unidade for substituída. Eu duvido que o RAID10 de 3 drives seja melhor nesse aspecto.

Como ponto de referência: o RAID10 do Linux em três unidades é semelhante ao que os controladores RAID em alguns servidores IBM chamam de RAID1E.