Existe uma alternativa mais rápida ao cp para copiar arquivos grandes (~ 20 GB)?

40

Sou estudante de graduação e o grupo em que trabalho mantém um cluster Linux. Cada nó do cluster possui seu próprio disco local, mas esses discos locais são relativamente pequenos e não estão equipados com backup automático. Portanto, o grupo possui um servidor de arquivos com muitos TBs de espaço de armazenamento. Sou um iniciante no Linux, portanto, não tenho certeza de quais são as especificações do servidor de arquivos em termos de velocidade, capacidade de rede, etc. Sei por experiência própria que os discos locais são significativamente mais rápidos que o servidor de arquivos em termos de E / S . Cerca de uma dúzia de pessoas usam o servidor de arquivos.

Usar cppara copiar um arquivo de ~ 20 GB do servidor de arquivos para um dos discos locais leva em média 11,5 minutos em tempo real (de acordo com time). Eu sei que essa cpoperação não é muito eficiente porque (1) timeme diz que o tempo do sistema para uma cópia desse tipo é de apenas ~ 45 segundos; e porque (2) quando examino topdurante a cópia, o % de CPU é bastante baixo (por inspeção, aproximadamente 0-10% em média).

Usar cppara copiar o mesmo arquivo de ~ 20 GB de uma pasta no disco local para outra pasta no mesmo disco local leva menos tempo - cerca de 9 minutos em tempo real (~ 51 segundos no tempo do sistema, de acordo com time). Então, aparentemente, o servidor de arquivos é um pouco mais lento que o disco local, como esperado, mas talvez não seja significativamente mais lento. Estou surpreso que copiar do local para o mesmo local não seja mais rápido que 9 minutos.

Preciso copiar ~ 200 arquivos grandes - cada ~ 20 GB - do servidor de arquivos para um dos discos locais. Então, minha pergunta é: Existe uma alternativa mais rápida cppara copiar arquivos grandes no Linux? (Ou há alguma bandeira dentro da cpqual eu possa usar que acelere a cópia?) Mesmo se eu pudesse, de alguma forma, economizar um minuto desse tempo de cópia, isso ajudaria imensamente.

Estou certo de comprar discos de hardware novos e mais rápidos, mas não tenho acesso a esses recursos. Também não sou administrador de sistema - sou apenas um usuário (iniciante) -, portanto, não tenho acesso a informações mais detalhadas sobre a carga que está nos discos. Sei que, embora cerca de uma dúzia de pessoas use o servidor de arquivos diariamente, sou a única pessoa que usa esse nó / disco local específico.

Andrew
fonte
29
Isso gera cerca de 29 MB / s, o que é bem rápido se você me perguntar. Eu não acho que exista algum comando que acelere isso, o "gargalo" provavelmente é a) a rede ou b) o servidor de arquivos.
tink
5
o toque é 100% correto. Eu nunca vi nada que possa melhorar isso. A única coisa que eu fiz no passado foi compactar os dados antes de enviá-los, mas isso significa que você está adicionando tempo com as etapas de compactação e descompactação, mas às vezes vale a pena se os dados forem um bom candidato a ser comprimido!
slm
3
Você também pode tentar dde rsynccomparar qual delas funciona mais rápido em seu ambiente
Raza
@ Salton Obrigado. Ainda não tentei dd, mas apenas tentei rsync. O tempo real foi de cerca de 11,5 minutos e o tempo do sistema foi de cerca de 1,5 minutos, de acordo com time.
21713 Andrew Andrew
2
Estou surpreso que ninguém tenha apontado que o disco local para a cópia de disco local poderia ser mais eficiente com a montagem de vários discos. Copiar de /dev/sda1para /dev/sdb1será mais rápido do que copiar de um local /dev/sda1para outro local /dev/sda1ou de outra partição, /dev/sdaporque o disco rígido não precisará fazer buscas adicionais entre leituras e gravações (assumindo discos rígidos tradicionais com discos giratórios e cabeças em movimento; SSD é obviamente diferente).
tripleee

Respostas:

53

O% de CPU deve estar baixo durante uma cópia. A CPU informa ao controlador de disco "captura dados dos setores X-Y no buffer de memória em Z". Então ele vai e faz outra coisa (ou dorme, se não houver mais nada). O hardware aciona uma interrupção quando os dados estão na memória. Então a CPU precisa copiá-lo algumas vezes e diz à placa de rede "transmitir pacotes nos locais de memória A, B e C". Depois, volta a fazer outra coisa.

Você está pressionando ~ 240mbps. Em uma LAN de gigabit, você deve conseguir pelo menos 800mbps, mas:

  1. Isso é compartilhado entre todos que usam o servidor de arquivos (e possivelmente uma conexão entre comutadores etc.)
  2. Isso é limitado pela velocidade que o servidor de arquivos pode lidar com a gravação, tendo em mente que a largura de banda de E / S do disco é compartilhada por todos que o utilizam.
  3. Você não especificou como está acessando o servidor de arquivos (NFS, CIFS (Samba), AFS etc.). Pode ser necessário ajustar sua montagem de rede, mas em algo semi-recente os padrões geralmente são bastante sãos.

Para rastrear o gargalo, iostat -kx 10será um comando útil. Ele mostrará a utilização em seus discos rígidos locais. Se você puder executar isso no servidor de arquivos, ele mostrará o quão ocupado o servidor de arquivos está.

A solução geral será acelerar esse gargalo, para o qual você não tem orçamento. Mas há alguns casos especiais em que você pode encontrar uma abordagem mais rápida:

  • Se os arquivos forem compactáveis ​​e você tiver uma CPU rápida, realizar uma compactação mínima em tempo real poderá ser mais rápido. Algo como lzopou talvez gzip --fastest.
  • Se você estiver alterando apenas alguns bits aqui e ali e depois enviar o arquivo de volta, apenas o envio de deltas será muito mais rápido. Infelizmente, rsyncnão vai ajudar muito aqui, pois ele precisará ler o arquivo dos dois lados para encontrar o delta. Em vez disso, você precisa de algo que acompanhe o delta à medida que altera o arquivo ... A maioria das abordagens aqui são específicas do aplicativo. Mas é possível que você possa montar algo com, por exemplo, mapeador de dispositivos (consulte o novo alvo da era dm ) ou btrfs.
  • Se você estiver copiando os mesmos dados para várias máquinas, poderá usar algo como o udpcast para enviá-los a todas as máquinas ao mesmo tempo.

E, como você observa que não é o administrador de sistemas, acho que isso significa que você tem um administrador de sistema. Ou pelo menos alguém responsável pelo servidor de arquivos e pela rede. Você provavelmente deve perguntar a ele / ela, eles devem estar muito mais familiarizados com as especificidades de sua configuração. Seu administrador de sistemas deve pelo menos ser capaz de informar qual taxa de transferência você pode esperar razoavelmente.

derobert
fonte
+1 para iostat -kx 10 :-)
n611x007
16

Essa poderia ser uma alternativa mais rápida e você não obstruirá a rede por dois dias: pegue um ou dois discos grandes USB (USB 3, se houver) ou FireWire, conecte-o ao servidor e copie os arquivos para O disco. Leve o disco para a sua máquina local. Copie os arquivos para a máquina.

Thomas Padron-McCarthy
fonte
23
O Sneakernet ( en.wikipedia.org/wiki/Sneakernet ) pode ser muito rápido: nunca subestime a largura de banda de uma caminhonete cheia de fitas rolando pela estrada.
SplinterReality
10

Sua definição de eficiente é inversa. Uma implementação mais eficiente desperdiça menos tempo de CPU. Na cópia local, você tem uma média de 74 MB / s de taxa de transferência (leitura + gravação), o que é tão bom quanto um único disco rígido obterá.

psusi
fonte
11
Opa Quando eu disse "eficiente", quis dizer "rápido".
18713 Andrew Andrew
10

Se você tiver acesso direto ao SSH (ou SFTP) (pergunte ao seu administrador de sistemas), poderá usar scpcom compressão ( -C):

scp -C you@server:/path/to/yourfile .

Obviamente, isso só será útil se o arquivo for compactável, e isso consumirá mais tempo de CPU, pois ele usará criptografia (porque está sobre SSH) e compactação.

Restabelecer Monica
fonte
Nesse caso, seria útil desativar a criptografia. Lembre-se de que estamos tentando tornar a cópia mais rápida .
lgeorget
3
@lgeorget Eu suspeito que a sobrecarga da criptografia não será significativa, considerando o quão lento os discos rígidos são. Eu considerei adicionar algo sobre -c none, mas isso parece não ser padrão .
Reintegrar Monica
11
Estamos lidando com arquivos ~ 20G, por isso é bastante ineficiente usar criptografia, se não for necessário.
lgeorget
11
A criptografia @lgeorget pode ser feita muito mais rapidamente do que a taxa de transferência que ele está obtendo, por isso não atrasará nada. Mas parece desnecessário passar pelo SSH aqui. Se você só precisa de compressão, certamente existem outras ferramentas?
Thomas
@ Thomas A vantagem do SSH é que, se você deveria ter acesso ao servidor remoto, é quase certo que ele esteja executando o SSH. Outra opção seria compactar o arquivo localmente, copiá-lo para o servidor e depois sshdescompactá-lo. #:
Reinstala Monica
8

A cpimplementação provavelmente não é um gargalo. Tente observar o uso de E / S iotopno servidor e no nó do cluster. Isso lhe dará uma idéia de onde você pode melhorar o desempenho.

Outra dica é evitar copiar os mesmos dados do mesmo host. Por exemplo, se você tiver um arquivo 20G idêntico para distribuir do servidor de arquivos pela rede para todos os nós do cluster, ele funcionará muito mais rápido se você copiar arquivos de maneira ponto a ponto, em vez de um servidor para todos os clientes. É um pouco mais complicado de implementar, mas você pode até tentar usar alguma linha de comando p2p como o hub de conexão direta.

Se dentro desses arquivos 20G, alguma parte é comum e algumas são específicas do nó do cluster, considere dividi-lo em partes comuns e específicas e depois distribua a parte comum da maneira p2p.

Michał Šrajer
fonte
11
Se você estiver em uma LAN, poderá fazer multicast em vez de ponto a ponto. O que deve ser mais rápido e menos carregado na rede.
derobert
8

A natureza / conteúdo desses arquivos pode fazer alguma diferença. Entendi que você precisa copiar 200 arquivos, ~ 20 GB cada, de um computador para outro, é isso?

Se esses arquivos forem compactáveis ​​ou com partes semelhantes / idênticas, você terá duas abordagens:

  • feche-os antes de copiar ou crie um túnel entre os computadores com o zip ativado. Portanto, se a rede for um gargalo, será um pouco mais rápido

  • se os arquivos forem muito semelhantes ou compartilham partes de conteúdo comum, tente usar o rsync . Passará algum tempo descobrindo o que é comum entre os arquivos e não precisará copiá-lo literalmente , porque o reconstruirá com base no que é comum.

editar

Você precisará copiar esses arquivos muitas vezes? (como uma cópia -> use esses arquivos -> altere algo nos arquivos do computador A -> copie os arquivos novamente para o computador B)

Nesse caso, o rsync será útil, porque tentará detectar o que é igual entre as versões e não copiará o que é inalterado.

E um terceiro método: se o acima estiver correto (alterações no arquivo, copie todos os arquivos novamente para o segundo computador), você pode tentar binary diffalterar apenas no segundo computador o que foi alterado no primeiro computador.

woliveirajr
fonte
6

Vejo o seguinte aqui, criptografia não é uma boa ideia, pois pode aumentar a quantidade de dados a serem transferidos.

Se você estiver copiando entre dois sistemas, é claro que o gargalo é a conexão entre os servidores.

Se você estiver copiando localmente, observe como o processo ocorre, ele é ÚNICO e, portanto, os utilitários padrão do Linux usam:

- for all blocks in a file
      read a block
      write a block

Não há simultaneidade para esta operação.

Para acelerar as coisas, você pode usar algo como isto:

  buffer -i infile -o outfile -m size-of-shared-memory-default-1MByte

Consulte a página do manual buffer (1) para obter mais informações.

O comando buffer configura dois processos para executar o processo de cópia simultaneamente: um para leitura e outro para gravação, e usa um buffer de memória compartilhada para comunicar os dados entre os dois processos. O buffer de memória compartilhada é seu buffer circular clássico que impede a substituição de dados não gravados e a gravação de dados já gravados. Eu usei esse programa para reduzir cerca de 10 a 20% do tempo de cópia nas transferências do disco para a fita.

mdpc
fonte
Na verdade, há simultaneidade em "ler um bloco / escrever um bloco" porque "escrever um bloco" na verdade apenas o coloca no buffer do kernel, e o kernel lida com a gravação real do bloco em segundo plano (pelo menos até que você comece a ficar sem de RAM). Ou se você estiver usando O_DSYNC / O_SYNC por algum motivo.
derobert
3

Por que não tentar um algoritmo de propagação P2P, se você precisar atualizar todo o cluster ao mesmo tempo?

https://github.com/lg/murder é o que o twitter usa

Existe o BTSync que você pode tentar também.

Gui13
fonte
1

Se você estiver copiando os mesmos conjuntos de arquivos frequentemente do computador local para o servidor, com pequenas alterações aqui e ali. Você pode acelerar a transferência usando o rsync ou um DVCS (por exemplo, hg ou git).

git ou hg podem acompanhar e detectar deltas e apenas transferi-los. No caso de usar um git, como os dois lados têm um histórico completo do repositório, descobrir o delta é muito barato.

O rsync usa uma forma de algoritmo de soma de verificação rolante para detectar deltas sem o conhecimento prévio do que está do outro lado. Embora seja necessário mais trabalho para o rsync calcular os deltas, ele não precisa armazenar o histórico inteiro do arquivo.

Lie Ryan
fonte
1

Convém tentar compactar todos os arquivos em um único arquivo morto (não precisa ser compactado). Na minha experiência, copiar esse arquivo é mais rápido do que copiar um grande número de arquivos individuais

Munim
fonte
3
Boa observação genérica, mas como a pergunta diz "~ 200 arquivos grandes - cada ~ 20 GB", não acredito que isso possa ser considerado uma resposta real para esse problema.
manatwork
ah ah manatwork .. eu não li claramente. Eu pensei que ele tinha 200 arquivos totalizando 20gb
Munim
0

Tente bbcp . Testes em nosso ambiente revelaram que o cp tinha algum tipo de governador incorporado. Apenas tome cuidado porque, quando você retira o governador, pode fazer uma linha vermelha no servidor e causar uma interrupção. No nosso caso, estávamos colocando o servidor offline para fazer a cópia, então mais rápido era melhor. Isso melhorou o tempo de transferência de várias horas.

James Shewey
fonte
0

Verifique se os arquivos de destino não existem antes de copiar.

Às vezes, é surpreendente quanto tempo é gasto, apenas copiando no mesmo host (sem rede envolvida).

Veja minha resposta para outra pergunta cp aqui . Para encurtar a história, substituir um arquivo existente é muito mais lento do que truncá-lo ou desvinculá-lo primeiro e depois copiá-lo. O último é 8x mais rápido para um arquivo de 1,2 GB.

Pierre D
fonte