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

Question

Sou estudante de pós-graduação e o grupo em que trabalho mantém um cluster do 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. Eu sou um relativamente novato em Linux, então não tenho certeza quais são as especificações do servidor de arquivos em termos de velocidade, capacidade de rede, etc. Eu sei por experiência que os discos locais são significativamente mais rápidos que o servidor de arquivos em termos de I / O . Cerca de uma dúzia de pessoas usam o servidor de arquivos.

O uso do cp para 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 esta operação cp não é muito eficiente porque (1) time me diz que a hora do sistema para tal cópia é de apenas ~ 45 segundos; e porque (2) quando examino top durante a cópia, % CPU é bastante baixo (por inspeção, aproximadamente 0-10% em média).

Usar cp para copiar o mesmo arquivo ~ 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 codificar%). 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 a cópia do local para o mesmo local não seja mais rápida do que 9 minutos.

Eu 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 para time para copiar arquivos grandes no Linux? (Ou existem sinalizadores dentro de cp que eu poderia usar, o que aceleraria a cópia?) Mesmo que eu pudesse de alguma forma tirar um minuto desse tempo de cópia, isso ajudaria imensamente.

Tenho certeza de que estou comprando discos de hardware novos e mais rápidos, mas não tenho acesso a esses recursos. Eu também não sou um administrador de sistemas - eu sou apenas um usuário (novato) - então não tenho acesso a informações mais detalhadas sobre a carga que está nos discos. Eu sei que, enquanto cerca de uma dúzia de pessoas usam o servidor de arquivos diariamente, eu sou a única pessoa que usa esse nó / disco local específico.

    

Answer 1

% CPU deve ser baixo durante uma cópia. A CPU diz ao controlador de disco "pegue os dados dos setores X-Y no buffer de memória em Z". Então 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. Em seguida, a CPU precisa copiá-lo algumas vezes e informa à placa de rede "transmitir pacotes nos locais de memória A, B e C". Então volta a fazer outra coisa.

Você está empurrando ~ 240mbps. Em uma LAN gigabit, você deve ser capaz de fazer pelo menos 800mbps, mas:

1. É compartilhado entre todos que usam o servidor de arquivos (e possivelmente uma conexão entre switches, etc.)
2. Isso é limitado pela velocidade com que o servidor de arquivos pode manipular a gravação, tendo em mente que a largura de banda de E / S do disco é compartilhada por todos que a usam.
3. Você não especificou como está acessando o servidor de arquivos (NFS, CIFS (Samba), AFS etc.). Você pode precisar ajustar sua montagem de rede, mas em qualquer coisa que seja meio recente, os padrões geralmente são bastante sensatos.

Para rastrear o gargalo, iostat -kx 10 será um comando útil. Ele mostrará a utilização em seus discos rígidos locais. Se você puder executá-lo no servidor de arquivos, ele informará o nível de ocupação do servidor de arquivos.

A solução geral será acelerar esse gargalo, o que obviamente você não tem orçamento para. Porém, 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, fazer uma compactação mínima on-the-fly poderá ser mais rápido. Algo como lzop ou talvez gzip --fastest .
• Se você está apenas alterando alguns bits aqui e ali e enviando o arquivo de volta, somente o envio de deltas será muito mais rápido. Infelizmente, rsync não ajuda muito aqui, pois será necessário ler o arquivo em ambos os 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 é específica do aplicativo. Mas é possível que você possa manipular algo, por exemplo, mapeador de dispositivos (veja o novo alvo da era dm ) ou btrfs.
• Se você estiver copiando os mesmos dados para máquinas múltiplas , poderá usar algo como o udpcast para enviá-los para todas as máquinas de uma só vez.

E, desde que você note que não é o sysadmin, acredito que isso significa que você tem um administrador de sistema. Ou pelo menos alguém responsável pelo servidor de arquivos & rede. Você provavelmente deve perguntar a ele / ela / eles, eles devem estar muito mais familiarizados com as especificidades da sua configuração. Seu (s) administrador (s) deve (m) pelo menos ser capaz de dizer qual taxa de transferência você pode razoavelmente esperar.

    

Answer 2

Isso poderia, possivelmente, ser uma alternativa mais rápida, e você não vai entupir a rede por dois dias: pegue um ou dois discos USB (USB 3 se você tiver) ou FireWire, conecte-o ao servidor e copie os arquivos para o disco. Carregue o disco para sua máquina local. Copie os arquivos para a máquina.

    

Answer 3

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

    

Answer 4

Se você tiver acesso SSH (ou SFTP) direto (pergunte ao seu administrador de sistemas), você pode usar scp com compactação ( -C ):

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

Claro, isso só é útil se o arquivo for compactável, e isso usará mais tempo de CPU, já que ele estará usando criptografia (porque é mais do que SSH) e compactando.

    

Answer 5

A implementação cp provavelmente não é um gargalo. Tente observar o uso do IO via iotop no servidor e no nó do cluster. Isso lhe dará uma ideia 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 no modo ponto-a-ponto, em vez de clientes de um servidor para todos. É um pouco mais complicado de implementar, mas você pode até tentar usar alguma linha de comando p2p como hub de conexão direta.

Se dentro dos arquivos 20G, alguma parte for comum, e alguns forem específicos do nó do cluster, considere dividi-la em partes comuns e específicas e, em seguida, distribua a parte comum na maneira p2p.

    

Answer 6

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

Se esses arquivos são compactáveis ou com peças semelhantes / idênticas, você tem duas abordagens:

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

• Se os arquivos forem muito semelhantes ou compartilharem alguns conteúdos comuns entre eles, tente usar o rsync . Ele passará algum tempo procurando o que é comum entre os arquivos e não precisará copiá-lo literalmente , porque ele será reconstruído com base no que é comum.

editar

Você precisará copiar esses arquivos muitas vezes? (como uma cópia - > usar esses arquivos - > mudar alguma coisa nos arquivos do computador A - > copiar os arquivos novamente para o computador B)

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

E um terceiro método: se o acima está correto (mudanças no arquivo, então copie todos os arquivos novamente para o segundo computador) você poderia tentar algum binary diff apenas mudar no segundo computador o que foi alterado no primeiro computador.

    

Answer 7

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

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

Se você estiver copiando localmente, veja como o processo funciona, ele é SINGLE threaded, assim os utilitários padrão do Linux usam:

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

NÃO há concorrência para esta operação.

Para acelerar as coisas, você pode usar algo assim:

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

Consulte a página do manual do 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 este programa para cortar cerca de 10-20% do tempo de cópia em transferências de disco para fita.

    

Answer 8

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

link é o que o twitter usa

Há BTSync que você pode tentar também.

    

Answer 9

Se você estiver copiando os mesmos conjuntos de arquivos com frequência do seu 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 pode rastrear e detectar deltas e somente transferir esses deltas. No caso de usar um git, uma vez que ambos os lados têm histórico completo do repositório, descobrir o delta é muito barato.

O rsync usa uma forma de algoritmo de soma de verificação contínua para detectar deltas sem 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 todo o histórico do arquivo.

    

Answer 10

Você pode querer tentar empacotar todos os arquivos em um único arquivo (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

    

Answer 11

Experimente bbcp . Testes em nosso ambiente revelaram que o CP tinha algum tipo de governador embutido. Apenas tenha cuidado, porque quando você tirar o governador, você pode red-line seu 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 foi melhor. Isso melhorou o tempo de transferência várias horas.

    

Answer 12

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

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

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