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

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.

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.

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.

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á.

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.

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.

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.

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.

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.

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.

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

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.

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.