Cópia lenta entre diretórios NFS/CIFS no mesmo servidor

Question

Hmm... notei alguns problemas e acho que encontrei uma ou duas provas fumegantes. Mas, primeiro farei algumas perguntas e farei suposições sobre suas prováveis respostas. Apresentarei alguns dados que a princípio parecerão irrelevantes, mas prometo que valerá a pena a leitura. Então, por favor, espere por isso... :-)

Presumo que no raid10 você tenha quatro unidades total stripe + redundante.
E que você está usando o autorid do Linux (em vez de um controlador de ataque de hardware).
Também estou assumindo que todas as portas SATA podem transferir independentemente umas das outras em velocidade total de transferência, bidirecionalmente, e que todas as portas SATA têm velocidade igualmente alta. Ou seja, se você tiver um único adaptador/controlador SATA, ele será totalmente capaz de executar todos os discos conectados a ele na velocidade nominal.
Também presumo que você tenha as unidades + controlador de especificação SATA mais recentes. Ou seja, 6,0 Gb/s. Isso é 600 MB/seg. Para sermos conservadores, vamos supor que obtemos metade disso, ou 300 MB/s
O cliente para servidor é limitado pela NIC (a 100 MB/s), portanto, não pode sobrecarregar as unidades o suficiente.
Para ir mais rápido que o NIC, ao fazer NFS para NFS, presumo que você esteja usando localhost, para poder ir além das velocidades limitadas do NIC (que acho que você disse que fez ligação para mostrar que isso não é um problema )

PROBLEMA 1. Suas taxas de transferência relatadas, mesmo para locais rápidos, parecem baixas. Com discos tão rápidos, eu esperaria mais de 150 MB/s. Eu tenho um sistema raid0 de 3 discos que faz apenas 3,0 Gb/s [adaptador limitado] e posso obter 450 MB/s distribuídos. Seus discos/controlador têm o dobro da velocidade do meu, então, eu esperaria [por causa da distribuição] que você obtivesse 300 MB/s e não apenas 150 MB/s para local para local. Ou talvez até 600 MB/seg [menos a sobrecarga de FS, que pode reduzir pela metade para fins de discussão]

Pelas informações do seu zpool, percebi que a configuração do seu disco é Western Digital e é:

espelho-0
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0
espelho 1
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0

Agora vamos comparar isso com suas informações do iostat. Pode ser bom ter informações do iostat em todas as unidades para todos os testes, mas acredito que posso diagnosticar o problema apenas com o que você forneceu
sdb e sdd estão no limite
Como você observou, isso éestranho. eu esperariatodosunidades para ter uso/estatísticas balanceadas em um raid10. Esta é a [minha] arma fumegante.
Combinando os dois. As unidades maximizadas são um modelo ligeiramente diferente daquelas que não o são. Presumo que a ordem do zpool seja sda/sdb sdc/sdd [mas pode ser revertida]
sda/sdc são 68AX9N0
sdb/sdd são 68EUZN0

QUESTÃO #2. Em uma pesquisa no Google sobre WD20EFRX + 68AX9N0 + 68EUZN0, encontrei esta página:http://forums.whirlpool.net.au/archive/2197640

Parece que as unidades 68EUZN0 podem estacionar suas cabeças após cerca de 8 segundos, enquanto as outras são mais inteligentes sobre isso [ou vice-versa].

Portanto, dado o cache NFS + cache FS + cache SSD, as unidades subjacentes podem ficar ociosas e estacionar. Meu palpite é que a camada extra de cache do NFS é o que o leva ao limite.

Você pode testar isso variando as opções de sincronização do FS, talvez a sincronização seja melhor que a assíncrona. Além disso, se você puder, eu executaria novamente os testes com o cache SSD desativado. A ideia é garantir que o estacionamento nãonãoocorrer e ver os resultados.

Conforme mencionado na página da web, existem alguns utilitários que podem ajustar o intervalo de atraso do estacionamento. Se essa for a opção, pesquise bem.

ATUALIZAR:

Seu problema pode ser visto como um problema de rendimento através de uma rede store-and-forward [com entrega garantida]. Observe, eu estounãofalando sobre a NIC ou equiv.

Considere que uma operação de E/S é como um pacote contendo uma solicitação (por exemplo, leitura/gravação, buf_addr, buf_len) que é armazenada em uma estrutura. Este pacote/estrutura de solicitação é passado entre as várias camadas de cache: NFS, ZFS, driver de dispositivo, controlador SATA, disco rígido. Em cada ponto, você tem um horário de chegada na camada e um horário de saída quando a solicitação é encaminhada para a próxima camada.

Neste contexto, a velocidade real de transferência do disco, quando a transferência realmente acontece, é análoga à velocidade do link. Quando a maioria das pessoas considera os discos, elas consideram apenas a velocidade de transferência e não quando a transferência foi realmente iniciada.

Em um roteador de rede, os pacotes chegam, mas nem sempre são encaminhados imediatamente, mesmo que o link de saída esteja livre. Dependendo da política do roteador, o roteador pode atrasar um pouco o pacote, esperando que mais pacotes cheguem de outras fontes [ou da mesma fonte se for UDP], para que o roteador possa agregar os pacotes menores em um pacote grande que possa ser transmitido no link de saída com mais eficiência.

Para discos, esse “atraso” pode ser caracterizado por uma determinada política de cache da camada FS. Em outras palavras, se uma solicitação chegar a uma camada no tempo T, em vez de sair da camada em T+1 e chegar à próxima camada em T+1, ela poderá partir/chegar em T+n. Uma camada de cache FS pode fazer isso, para que possa buscar otimização/classificação de pedidos.

O comportamento que você está vendo é muito semelhante a um soquete TCP que reduziu sua janela devido ao congestionamento.

Acho importante dividir os testes. No momento, você está lendo e escrevendo. E você não sabe qual é o fator limitante/gargalo. Acho que seria útil dividir os testes em leitura ou gravação. Um programa de benchmark decente provavelmente fará isso. O que estou defendendo é uma versão mais sofisticada de [estes são apenas exemplos aproximados, não os argumentos exatos a serem usados]:

Para gravação, tempo dd if=/dev/zero of=/whatever_file count=64g
Para leitura, tempo dd if=/whatever of=/dev/null count=64g

A razão para 64 GB é que isso representa 2x a sua memória RAM física e elimina os efeitos do cache de bloco. Execute o comando de sincronização entre os testes.

Aplique isso no FS local e repita no NFS.

Além disso, faça olerteste em cada um de /dev/{sda,sdb,sdc,sdd}

Faça iostat durante esses testes.

Observe que fazer o teste de leitura no disco físico bruto fornece uma linha de base/máximo de quão rápido o hardware pode realmente funcionar. As leituras brutas do dispositivo devem aproximar-se das capacidades máximas das especificações de transferência das suas unidades. A velocidade de gravação esperada deve ser semelhante para um disco rígido. Se não, por que não? Todos os discos devem ser testados aproximadamente na mesma velocidade. O que estou procurando aqui é o motivo pelo qual apenas dois discos atingiram o limite máximo em seus testes anteriores.

Fazendo as contas, com 32 GB e assumindo uma velocidade máxima de transferência de 600 MB/seg, levaria no mínimo 50 segundos para preencher/liberar isso. Então, qual é o tempo limite do parque definido?

Além disso, você pode variar um pouco as coisas, reduzindo a quantidade de memória RAM física que o kernel permitirá através do parâmetro mem= boot. Tente algo como mem=8g para ver que efeito isso tem. Existem também algumas entradas /proc que podem ajustar a política de liberação de cache da camada de bloco.

Além disso, meus FSes são ext4 e montados com noatime. Você pode querer considerarzfs set atime=off ...

Além disso, observe o log do sistema. Às vezes, uma unidade relata um erro de detecção e o sistema a reconfigura para usar uma velocidade de transferência mais baixa.

Além disso, dê uma olhada nos dados SMART das unidades. Você vê algo incomum? Tentativas suaves excessivas em uma determinada unidade (por exemplo).

Como eu disse, o desempenho do disco local é muito menor do que eu esperava. Acho que esse problema precisa ser resolvido primeiro, antes de abordar todo o sistema com o NFS. Se todos os discos raid tivessem utilização equilibrada e estivessem dentro do limite, eu ficaria menos preocupado com isso.

Meu sistema [que também possui discos WDC] não está configurado para NFS (eu uso muito o rsync). Tenho algumas coisas urgentes que preciso fazer nos próximos 1-2 dias. Depois disso, terei tempo para experimentar [eu também ficaria curioso].

ATUALIZAÇÃO #2:

Boa captura sobre o problema de desequilíbrio do ZFS. Isso ajuda a explicar meu "problema nº 1". Istopoderexplique também a instabilidade do NFS se as operações de rebalanceamento de alguma forma confundiram o NFS em relação à latência/tempo, causando o comportamento de "janela TCP/retirada" - não uma probabilidade super alta, mas uma possibilidade, no entanto.

Com o teste rsync, não há necessidade/desejo de usar o NFS. Se você puder fazer ssh no servidor, rsynceNFS são redundantes. Com o NFS, basta usar cp, etc. Para fazer o rsync, vá diretamente para o ZFS subjacente via ssh. Isso funcionará mesmo sem uma montagem NFS [aqui está a configuração do rsync que eu uso]:

exportar RSYNC_SSH="/usr/bin/ssh"
exportar SSH_NOCOMPRESS=1
rsync /wherever1 servidor:/zfsmount/qualquer que seja

Fazer isso localhost ou vinculado pode obter o desempenho esperado (sem o problema de desequilíbrio do ZFS). Nesse caso, isso claramente restringe o problema ao NFSem si.

Eu examinei algumas fontes do kernel para NFS. Pelo pouco que olhei, não gostei do que vi em relação à pontualidade. O NFS começou na década de 80, quando os links eram lentos, então ele [ainda] tem muito código para tentar conservar a largura de banda da NIC. Isto é, apenas “comprometa-se” [com] uma ação quando for absolutamente necessário. Não necessariamente o que queremos. Na minha fantástica analogia com a política do roteador de rede, o cache do NFS parece ser aquele com o atraso "T+n".

Eu recomendo fazer o que puder para desabilitar o cache do NFS e fazer com que ele passe sua solicitação ao ZFS o mais rápido possível. Deixe o ZFS ser o inteligente e o NFS o "tubo burro". O cache NFS só pode ser de natureza genérica (por exemplo, ele nem saberá que o armazenamento de apoio é um RAID ou muito sobre as características especiais do FS base no qual está montado). O ZFS possui conhecimento profundo do RAID e dos discos que o compõem. Assim, o cache do ZFS pode ser muito mais inteligente nas escolhas.

Eu diria que tente fazer com que o NFS faça uma montagem sincronizada - isso pode resolver o problema. Além disso, vi algo sobre noatime, então ative essa opção também. Pode haver outras opções de ajuste/montagem do NFS. Esperançosamente, se o NFS for o suspeito usual, ele poderá ser reconfigurado para funcionar bem o suficiente.

Se, por outro lado, nenhuma opção colocar o NFS em risco, o rsync sobre o ssh seria uma alternativa viável? Qual é o caso de uso real? Parece que você está usando o NFS como um canal para grandes transferências em massa que precisam de alto desempenho (em vez de [digamos] apenas como um ponto de montagem automática para diretórios pessoais do usuário). Isso é para coisas como backup de cliente para servidor, etc?

Answer 1

Hmm... notei alguns problemas e acho que encontrei uma ou duas provas fumegantes. Mas, primeiro farei algumas perguntas e farei suposições sobre suas prováveis respostas. Apresentarei alguns dados que a princípio parecerão irrelevantes, mas prometo que valerá a pena a leitura. Então, por favor, espere por isso... :-)

Presumo que no raid10 você tenha quatro unidades total stripe + redundante.
E que você está usando o autorid do Linux (em vez de um controlador de ataque de hardware).
Também estou assumindo que todas as portas SATA podem transferir independentemente umas das outras em velocidade total de transferência, bidirecionalmente, e que todas as portas SATA têm velocidade igualmente alta. Ou seja, se você tiver um único adaptador/controlador SATA, ele será totalmente capaz de executar todos os discos conectados a ele na velocidade nominal.
Também presumo que você tenha as unidades + controlador de especificação SATA mais recentes. Ou seja, 6,0 Gb/s. Isso é 600 MB/seg. Para sermos conservadores, vamos supor que obtemos metade disso, ou 300 MB/s
O cliente para servidor é limitado pela NIC (a 100 MB/s), portanto, não pode sobrecarregar as unidades o suficiente.
Para ir mais rápido que o NIC, ao fazer NFS para NFS, presumo que você esteja usando localhost, para poder ir além das velocidades limitadas do NIC (que acho que você disse que fez ligação para mostrar que isso não é um problema )

PROBLEMA 1. Suas taxas de transferência relatadas, mesmo para locais rápidos, parecem baixas. Com discos tão rápidos, eu esperaria mais de 150 MB/s. Eu tenho um sistema raid0 de 3 discos que faz apenas 3,0 Gb/s [adaptador limitado] e posso obter 450 MB/s distribuídos. Seus discos/controlador têm o dobro da velocidade do meu, então, eu esperaria [por causa da distribuição] que você obtivesse 300 MB/s e não apenas 150 MB/s para local para local. Ou talvez até 600 MB/seg [menos a sobrecarga de FS, que pode reduzir pela metade para fins de discussão]

Pelas informações do seu zpool, percebi que a configuração do seu disco é Western Digital e é:

espelho-0
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0
espelho 1
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0

Agora vamos comparar isso com suas informações do iostat. Pode ser bom ter informações do iostat em todas as unidades para todos os testes, mas acredito que posso diagnosticar o problema apenas com o que você forneceu
sdb e sdd estão no limite
Como você observou, isso éestranho. eu esperariatodosunidades para ter uso/estatísticas balanceadas em um raid10. Esta é a [minha] arma fumegante.
Combinando os dois. As unidades maximizadas são um modelo ligeiramente diferente daquelas que não o são. Presumo que a ordem do zpool seja sda/sdb sdc/sdd [mas pode ser revertida]
sda/sdc são 68AX9N0
sdb/sdd são 68EUZN0

QUESTÃO #2. Em uma pesquisa no Google sobre WD20EFRX + 68AX9N0 + 68EUZN0, encontrei esta página:http://forums.whirlpool.net.au/archive/2197640

Parece que as unidades 68EUZN0 podem estacionar suas cabeças após cerca de 8 segundos, enquanto as outras são mais inteligentes sobre isso [ou vice-versa].

Portanto, dado o cache NFS + cache FS + cache SSD, as unidades subjacentes podem ficar ociosas e estacionar. Meu palpite é que a camada extra de cache do NFS é o que o leva ao limite.

Você pode testar isso variando as opções de sincronização do FS, talvez a sincronização seja melhor que a assíncrona. Além disso, se você puder, eu executaria novamente os testes com o cache SSD desativado. A ideia é garantir que o estacionamento nãonãoocorrer e ver os resultados.

Conforme mencionado na página da web, existem alguns utilitários que podem ajustar o intervalo de atraso do estacionamento. Se essa for a opção, pesquise bem.

ATUALIZAR:

Seu problema pode ser visto como um problema de rendimento através de uma rede store-and-forward [com entrega garantida]. Observe, eu estounãofalando sobre a NIC ou equiv.

Considere que uma operação de E/S é como um pacote contendo uma solicitação (por exemplo, leitura/gravação, buf_addr, buf_len) que é armazenada em uma estrutura. Este pacote/estrutura de solicitação é passado entre as várias camadas de cache: NFS, ZFS, driver de dispositivo, controlador SATA, disco rígido. Em cada ponto, você tem um horário de chegada na camada e um horário de saída quando a solicitação é encaminhada para a próxima camada.

Neste contexto, a velocidade real de transferência do disco, quando a transferência realmente acontece, é análoga à velocidade do link. Quando a maioria das pessoas considera os discos, elas consideram apenas a velocidade de transferência e não quando a transferência foi realmente iniciada.

Em um roteador de rede, os pacotes chegam, mas nem sempre são encaminhados imediatamente, mesmo que o link de saída esteja livre. Dependendo da política do roteador, o roteador pode atrasar um pouco o pacote, esperando que mais pacotes cheguem de outras fontes [ou da mesma fonte se for UDP], para que o roteador possa agregar os pacotes menores em um pacote grande que possa ser transmitido no link de saída com mais eficiência.

Para discos, esse “atraso” pode ser caracterizado por uma determinada política de cache da camada FS. Em outras palavras, se uma solicitação chegar a uma camada no tempo T, em vez de sair da camada em T+1 e chegar à próxima camada em T+1, ela poderá partir/chegar em T+n. Uma camada de cache FS pode fazer isso, para que possa buscar otimização/classificação de pedidos.

O comportamento que você está vendo é muito semelhante a um soquete TCP que reduziu sua janela devido ao congestionamento.

Acho importante dividir os testes. No momento, você está lendo e escrevendo. E você não sabe qual é o fator limitante/gargalo. Acho que seria útil dividir os testes em leitura ou gravação. Um programa de benchmark decente provavelmente fará isso. O que estou defendendo é uma versão mais sofisticada de [estes são apenas exemplos aproximados, não os argumentos exatos a serem usados]:

Para gravação, tempo dd if=/dev/zero of=/whatever_file count=64g
Para leitura, tempo dd if=/whatever of=/dev/null count=64g