Por que há uma diferença de velocidade de gravação entre dd, cp, rsync e macOS Finder em uma unidade SMB3?

Tl; dr - Não conseguimos encontrar o motivo da velocidade de gravação limitada de 60 MB / s para o nosso NAS via SMB e AFP de dois clientes Mac diferentes. Em comparação: um laptop Windows 7 antigo na mesma rede grava 100 MB / seg.

Se você leu esta pergunta pela primeira vez, pule para a seção Atualização 4 . rsyncé a principal razão para a baixa velocidade, mesmo que não entendamos o porquê (para um único arquivo!).

Pergunta original: Encontre gargalo de velocidade SMB3 / NAS com Mac OS 10.11.5 e superior

Testamos via rsync --progress -a /localpath/test.file /nas/test.filemacOS e as informações de cópia do Windows.

O NAS é um DS713 + executando o DSM 6.0.2 atual (testado com 5.x também), com dois HGST Deskstar NAS SATA de 4 TB (HDN724040ALE640) em RAID1 com apenas componentes Ethernet de gigabit e novos cabos Ethernet (pelo menos Cat5e).

Os clientes Mac primeiro fizeram apenas 20 MB / s. Mas a aplicação da signing_required=nocorreção (descrita aqui ) elevou a velocidade de gravação para 60 MB / s via SMB2 e SMB3. O AFP também oferece cerca de 60 MB / s. O resultado varia em torno de 5 MB / s, dependendo do protocolo e do cliente (Mac).

O que já tentamos:

Rede

1. Desempenho de rede testado via iperf3. Resultado: 926 Mbit / s. Parece bom.
2. Tentei interfaces de rede de agregação de link duplo / ligado. Nenhuma mudança.
3. MTU aumentado para 6000 e 9000. Nenhuma alteração.
4. Verificou todos os cabos. Tudo bem, pelo menos, Cat5e, em boas condições.

Discos

1. Verificado O SMART parece saudável.
2. Velocidade de gravação testada diretamente no disco com dd if=/dev/zero of=write.test bs=256M count=4várias configurações bse count(128/8, 512M / 2, 1024/1). Resultado: cerca de 120 MB / s (dependendo do tamanho / contagem do bloco)

SMB / AFP

1. SMB2, SMB3 e AFP comparados entre si. Quase igual.
   Veja a atualização abaixo: Utilizou o método errado para descartar a implementação SMB do macOS. O SMB no Windows é mais rápido, novas configurações de SMB fornecidas com o macOS 10.11 e 10.12 podem ser o motivo.
2. Tentou ajustar as configurações SMB, incluindo as opções de soquete (seguindo esta instrução )
3. Tentei versão diferente das configurações de confirmação atrasada e rsync --sockopts=TCP_NODELAY(comentários)

Nenhuma alteração significativa na velocidade de gravação. Verificamos duas vezes se a configuração estava realmente carregada e estávamos editando o smb.conf correto .

Sistema

1. CPU assistida e carga de RAM. Nada atinge o máximo. CPU em torno de 20%, RAM em torno de 25% durante a transferência.
2. Testou o mesmo NAS com o DSM 5.xx em uma configuração quase pronta. Nenhum software adicional instalado. Nota: Temos dois deles em locais diferentes. Eles estão sincronizados através do CloudSync da Synology. Mesmo resultado.
3. Desativou tudo o que era desnecessário, que poderia atrair recursos do sistema.

Achamos que essa é uma configuração padrão, sem adaptações sofisticadas, clientes ou componentes de rede. De acordo com as métricas que a Synology publica, o NAS deve executar de 40 MB / se 75 MB / s mais rapidamente. Mas simplesmente não conseguimos encontrar o gargalo.

Clientes / NAS

Os clientes Mac são um MacPro 5,1 (NIC com fio padrão, executando 10.12.3 (16D32)) e um MacBookPro10,1 (adaptador de rede Thunderbolt, executando 10.11.6) apenas a cerca de 2 m de cabo do NAS, executando o mesmo switch de gigabit como o laptop Windows no teste.

Temos dois desses NASes em locais diferentes e os resultados são idênticos. Os segundos em que o NAS é mais ou menos o padrão de fábrica (nem mesmo o software de terceiros instalado). Apenas dois discos formatados em RAID1, EXT4, sincronizando com o outro NAS via Synology CloudSync. Chegamos ao ponto de nos conectarmos diretamente ao NAS sem o switch, mesmo resultado.

Atualização importante

O método usado para descartar a implementação SMB do macOS / OS X estava errado. Testei-o através de uma máquina virtual, assumindo que usaria sua própria versão do SMB, mas obviamente o tráfego é entregue ao macOS, executando sua versão do SMB.

Usando um laptop Windows, agora consegui atingir uma média de 100 MB / s. Indicar a implementação / atualizações SMB que vem com 10.11 e 10.12 pode causar um desempenho ruim. Mesmo se signing_requiredestiver definido como no.

Seria ótimo se alguém pudesse apontar outras configurações que podem ter sido alteradas com as atualizações e podem afetar o desempenho.

Atualização 2 - novos insights

AndrewHenle apontou nos comentários que eu deveria investigar o tráfego em detalhes usando o Wireshark para obter mais informações.

Por isso, executei sudo tcpdump -i eth0 -s 65535 -w tcpdump.dumpno NAS enquanto transferia dois arquivos de teste, um com 512 MB e outro com 1 GB. E inspecionou o depósito com o Wireshark.

O que eu encontrei:

1. O OS X e o Windows parecem usar o SMB2, embora o SMB3 esteja ativado no NAS (pelo menos de acordo com o Wireshark).
2. O OS X parece ficar com o MTU . Os pacotes têm 1514 bytes, levando a muito mais sobrecarga de rede e pacotes enviados (visíveis nos despejos).
3. O Windows parece enviar pacotes de até 26334 bytes (se eu ler os dados corretamente! Por favor, verifique.) Mesmo se o MTU não permitir isso, já que está definido como 1500 no NAS, a configuração máxima será 9000 (a Synology também usa a configuração 1500 em seus testes).
4. Tentar forçar o macOS a usar o SMB3 adicionando smb_neg=smb3_onlyao /etc/nsmb.conf não funcionou ou, pelo menos, não levou a transferências mais rápidas.
5. A execução rsync --sockopts=TCP_NODELAYcom várias combinações de configurações de confirmação tardia do TCP (0 a 3) não teve efeito (Nota: executei o tcpdump com a configuração de confirmação padrão de 3).

Criei 4 despejos como arquivos .csv, 2 ao copiar 512 MB (teste-2.arquivo) e 2 ao copiar 1024 MB (test.file). Você pode fazer o download das exportações do Wireshark aqui (25,2 MB). Eles são compactados para economizar espaço e são nomeados de forma auto-explicativa.

Atualização 3 - saída smbutil

Saída smbutil statshares -aconforme solicitado por harrymc nos comentários.

==================================================================================================
SHARE                         ATTRIBUTE TYPE                VALUE
==================================================================================================
home
                              SERVER_NAME                   server-name._smb._tcp.local
                              USER_ID                       502
                              SMB_NEGOTIATE                 SMBV_NEG_SMB1_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB2_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB3_ENABLED
                              SMB_VERSION                   SMB_3.0
                              SMB_SHARE_TYPE                DISK
                              SIGNING_SUPPORTED             TRUE
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              LARGE_FILE_SUPPORTED          TRUE
                              OS_X_SERVER                   TRUE
                              QUERYINFO_NOT_SUPPORTED       TRUE
                              DFS_SUPPORTED                 TRUE
                              MULTI_CREDIT_SUPPORTED        TRUE

--------------------------------------------------------------------------------------------------

Nota sobre isso: tenho certeza de que SIGNING_SUPPORTEDestar trueaqui não significa que a configuração na configuração não funcione. Mas apenas isso é suportado pelo NAS. Eu verifiquei três vezes se a alteração da signing_requiredconfiguração na minha configuração afeta a velocidade de gravação (~ 20 MB / s quando ativado, ~ 60 MB / s quando desativado).

Atualização 4 - Samba Wars: Uma Nova Esperança

Parece um pouco embaraçoso, mas o principal problema aqui - novamente - parece ser a medida.

Acontece que rsync --progress -acusta cerca de 30 MB / s de velocidade de gravação. Escrever dddiretamente no compartilhamento e no uso de SMB time cp /local/test.file /NAS/test.fileé mais rápido, de cerca de 85 a 90 MB / se, aparentemente, a maneira mais rápida de copiar é o localizador do macOS, de cerca de 100 MB / s (que também é o método mais difícil de medir, pois não há indicador de tempo ou velocidade - quem precisa disso, certo? o_O). Medimos isso primeiro copiando um arquivo de 1 GB e depois um arquivo de 10 GB, usando um cronômetro.

O que tentamos desde a última atualização desta pergunta.

1. Copie do cliente Mac para o cliente Mac. Ambos possuem SSDs (o MacPro grava com 250 MB / s no próprio disco, o MacBook Pro com 300 MB / s). Resultado: escassos 65 MB / s através da ddgravação do MacBook Pro para o MacPro ( rsync25 MB / s). Ver os 25 MB / s foi o momento em que começamos a questionar o rsync. Ainda 65 MB / s são extremamente lentos. Portanto, a implementação SMB no macOS parece… bem, questionável.
2. Tentei diferentes configurações ack com dd e cp - sem sorte.
3. Finalmente, encontramos uma maneira de listar todas as opções disponíveis do nsmb.conf. É simples man nsmb.conf. Cuidado, a versão online está desatualizada!

Então, tentamos mais algumas configurações, entre elas:

notify_off=yes
validate_neg_off=yes
read_async_cnt=16
write_async_cnt=16
dir_cache_async_cnt=40
protocol_vers_map=4
streams=no
soft=yes

Nota: não smb_neg=smb3_onlyé - como eu já esperava - uma configuração válida. protocol_vers_map=4deve ser o equivalente válido.

De qualquer forma, nenhuma dessas configurações fez diferença para nós.

Novas perguntas em resumo

1. Por que o rsync é uma maneira tão cara de copiar um (1!) Arquivo. Não há muito o que sincronizar / comparar aqui, existe? O tcpdump também não indica possível sobrecarga.

2. Por que dde cpmais lento que o localizador do macOS ao transferir para um compartilhamento SMB? Parece que, ao copiar com o Finder, há significativamente menos reconhecimentos na comunicação TCP. (Novamente: a configuração de confirmação, por exemplo, delayed_ack=1não fez diferença para nós.)

3. Por que o Windows parece ignorar o MTU, enviando pacotes TCP significativamente maiores e, portanto, menos, resultando no melhor desempenho em comparação com tudo o que é possível via macOS.

É assim que os pacotes são no macOS (constantemente 1514)

"TCP","1514","[TCP segment of a reassembled PDU]"
"TCP","66","445  >  56932 [ACK] Seq=6603 Ack=35239 Win=4505 Len=0 TSval=520980697 TSecr=650208630"

E isso vindo do Windows (até 26334, variando em tamanho)

"SMB2","1466","Write Request Len:65536 Off:196608 File: test.file"
"TCP","26334","[TCP segment of a reassembled PDU]"
"TCP","7354","[TCP segment of a reassembled PDU]"
"TCP","54","445  >  49220 [ACK] Seq=6831 Ack=267030 Win=4074 Len=0"

Você pode baixar .csv completo aqui (25,2 MB), os nomes dos arquivos explicam o que foi copiado (SO, método de transferência e tamanho do arquivo).

1. pergunta semelhante, mas tem respostas interessantes, pode ser que você possa verificar esta discussão especialmente no comentário 5: https://bugzilla.samba.org/show_bug.cgi?id=8512#c5

Aqui cite "Peter van Hooft". Embora eu não tenha certeza de testar a base sobre o que / qual dist dist. e versão do rsync também. No entanto: 1. ele nos pensou em tentar --sparse flag, se possível, para aumentar o desempenho. 2. ele testou no protocolo NFS, mas encontrou o mesmo problema de velocidade; portanto, talvez não o motivo do protocolo (SMB2 / 3, AFP, etc.).

Usamos o rsync para copiar dados de um servidor de arquivos para outro usando montagens NFS3 em um link de 10Gb. Descobrimos que aumentar o tamanho do buffer (como um teste rápido) aumenta o desempenho. Ao usar --sparse, isso aumenta o desempenho com um fator de cinquenta, de 2MBps a 100MBps.

2. Aqui está outra inspeção interessante sobre o desempenho do rsync. https://lwn.net/Articles/400489/

O LWN.net concluiu que o problema de desempenho pode ser relevante para o kernel, mesmo o artigo publicado em 2010 e não podemos mudar no NAS ou no MacOS. No entanto, este artigo nos mostra que o problema do kernel pode causar o cálculo da soma de verificação (minha suposição).

Uma coisa é clara: eu devo atualizar o kernel no meu sistema Mythtv. Em geral, os kernels 2.6.34 e 2.6.35-rc3 oferecem melhor desempenho que o antigo kernel 2.6.27. Mas, mexendo ou não, o rsync ainda não consegue superar um simples cp que copie a mais de 100MiB / s. De fato, o rsync realmente precisa de muita energia da CPU para cópias locais simples. Na frequência mais alta, o cp precisava de apenas 0,34 + 20,95 segundos de tempo de CPU, comparado aos 70 + 55 segundos do rsync.

citar comentários também tem isso:

Observe que o rsync sempre verifica se cada arquivo transferido foi reconstruído corretamente no lado receptor, verificando uma soma de verificação de arquivo inteiro gerada à medida que o arquivo é transferido

atualização 1 : meu erro, esta descrição é para --checksum. verifique aqui: [Melhorou a descrição da opção --checksum.] PS, não tenho reputação suficiente para postar mais de 2 links.

mas não consigo encontrar a mesma descrição na página de manual do rsync, então acho que alguém está falando abaixo.

O Rsync localiza arquivos que precisam ser transferidos usando um algoritmo de "verificação rápida" (por padrão) que procura por arquivos que foram alterados em tamanho ou no horário da última modificação. Quaisquer alterações nos outros atributos preservados (conforme solicitado pelas opções) são feitas diretamente no arquivo de destino quando a verificação rápida indica que os dados do arquivo não precisam ser atualizados.

Portanto, compare com cp / tar / cat, se usarmos o rsync para copiar vários arquivos pequenos ou grandes, isso poderá causar problemas de desempenho. Mas devido a eu não ser capaz de ler o código-fonte do rsync, portanto, não posso confirmar que este é o motivo final.

minha ideia é continuar checando:

1. Qual versão do rsync o awenro está usando para teste? Você pode atualizar para a versão mais recente?
2. vamos ver qual saída quando usar --stats e -v com --debug = FLAGS

bandeiras

--stats Isso diz ao rsync para imprimir um conjunto detalhado de estatísticas sobre a transferência de arquivos, permitindo que você diga a eficácia do algoritmo rsync para seus dados.

--debug = FLAGS Esta opção permite que você tenha um controle refinado sobre a saída de depuração que deseja ver. Um nome de sinalizador individual pode ser seguido por um número de nível, com 0 significando silenciar essa saída, 1 sendo o nível de saída padrão e números mais altos aumentando a saída desse sinalizador (para aqueles que suportam níveis mais altos). Use --debug = help para ver todos os nomes de sinalizadores disponíveis , o que eles produzem e quais nomes de sinalizadores são adicionados para cada aumento no nível detalhado.

por fim, eu recomendaria ler este post suplementar para obter mais conhecimento.
"Como transferir grandes quantidades de dados pela rede" moo.nac.uci.edu/~hjm/HOWTO_move_data.html

Rsync / ssh criptografa a conexão smb não, se bem me lembro. Se for apenas um arquivo, um sistema poderá ler esse arquivo e o outro não. Observe também que, para ter MTU acima de 1514, você precisa habilitar os pacotes "gigantes" / "Jumbo Frames", o fato de que os pacotes precisam ser mais reduzidos pode implicar que haja sobrecarga para "reembalar" o pacote. A segunda coisa a se notar é que "gigantes" / "Jumbo Frames" precisam ser ativados nas duas extremidades E TUDO ENTRE.

1514 são os quadros Ethernet normais. Os quadros 6k-9k são chamados gigantes ou "Jumbo Frames", dependendo do sistema operacional / aplicativo

Eu média 80 MB / s entre o meu nas (um PC com VMs, uma das VM é o NAS) e minha estação (um pc) com sftp (usando sshfs) [gigantes não ativados] e o dispositivo no meio é um microtik 2011 (indo somente chip tru switch)

Lembre-se de que o MTU é negociado entre dois pontos e que, ao longo de um caminho, você pode ter vários MTU com capacidade diferente e que o MTU será o menor disponível.

edit: SMB não é muito eficiente para transferências de arquivos.