Sou um estudante de graduação e o grupo no qual trabalho mantém um cluster Linux. Cada nó do cluster tem 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 TB de espaço de armazenamento. Sou relativamente novato no Linux, então 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 do que o servidor de arquivos em termos de E / S . Cerca de uma dúzia de pessoas usam o servidor de arquivos.
Usar cp para copiar um arquivo de aproximadamente 20 GB do servidor de arquivos para um dos discos locais leva cerca de 11,5 minutos em tempo real em média (de acordo com time). Eu sei que esta cp operação não é muito eficiente porque (1) time me diz que o tempo do sistema para tal cópia é 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 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 significativamente mais lento. Estou surpreso que copiar do local para o mesmo local não é mais rápido do que 9 minutos.
Eu preciso copiar ~ 200 arquivos grandes – cada um ~ 20 GB – do servidor de arquivos para um dos discos locais. Portanto, minha pergunta é: Existe uma alternativa mais rápida para cp para copiar arquivos grandes no Linux? (Ou há algum sinalizador em cp que eu possa usar e que acelere a cópia?) Mesmo se eu pudesse economizar um minuto nesse tempo de cópia, ajudar imensamente.
Tenho certeza de que comprarei discos de hardware novos e mais rápidos, mas não tenho acesso a esses recursos. Também não sou um administrador de sistema – sou apenas um usuário (novato) – – portanto, não tenho acesso a informações mais detalhadas sobre a carga que está nos discos. Eu sei que embora cerca de uma dúzia de pessoas usem o servidor de arquivos diariamente, eu sou a única pessoa usando este nó / disco local em particular.
Comentários
Resposta
% CPU deve estar baixa durante uma cópia. A CPU diz ao controlador de disco “pegue 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 dispara uma interrupção quando os dados estão na memória. Em seguida, a CPU tem que copiá-lo algumas vezes e diz à placa de rede “transmita pacotes nas localizações de memória A, B e C”. Em seguida, ele volta a fazer outra coisa.
Você está pressionando ~ 240 Mbps.Em uma LAN gigabit, você deve ser capaz de fazer pelo menos 800mbps, mas:
- Isso é compartilhado entre todos que usam o servidor de arquivos (e possivelmente uma conexão entre switches, etc.)
- Isso é limitado pela velocidade com 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 usam.
- Você não especificou como você está acessando o servidor de arquivos (NFS, CIFS (Samba), AFS, etc.). Você pode precisar ajustar a montagem de sua rede, mas em qualquer coisa pela metade recente, os padrões são geralmente bastante lógicos.
Para rastrear o gargalo, iostat -kx 10 vai 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 quão ocupado está o servidor de arquivos.
A solução geral será acelerar esse gargalo, para o qual obviamente 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ê tem uma CPU rápida, fazer uma compactação mínima durante o uso pode ser mais rápido. Algo como
lzopou talvezgzip --fastest. - Se você estiver apenas alterando alguns bits aqui e ali e, em seguida, enviando o arquivo de volta, apenas o envio de deltas será muito mais rápido. Infelizmente,
rsyncnão ajudará 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 monitore o delta conforme você altera o arquivo … A maioria das abordagens aqui são específicas do aplicativo. Mas é possível que você possa manipular algo com, por exemplo, mapeador de dispositivos (consulte o novo destino da era dm ) ou btrfs. - Se você estiver copiando os mesmos dados para múltiplas máquinas, pode usar algo como udpcast para enviá-los a todas as máquinas de uma vez.
E, já que você notou que não é o administrador do sistema, suponho que isso significa que você tem um administrador do sistema. Ou pelo menos alguém responsável pela rede & do servidor de arquivos. Você provavelmente deve perguntar a ele / ela / eles, eles devem estar muito mais familiarizados com as especificações de sua configuração. Seu (s) administrador (es) de sistema devem pelo menos ser capazes de dizer qual taxa de transferência você pode razoavelmente esperar.
Comentários
- +1 para iostat -kx 10 🙂
Resposta
Esta poderia, possivelmente, ser uma alternativa mais rápida, e você não obstruirá a rede por dois dias: Pegue um ou dois discos USB grandes (USB 3 se você tiver) ou FireWire, conecte-os a o servidor e copie os arquivos para o disco. Leve o disco para sua máquina local. Copie os arquivos para a máquina.
Comentários
- Sneakernet ( en.wikipedia.org/ wiki / Sneakernet ) pode ser muito rápido: nunca subestime a largura de banda de uma caminhonete cheia de fitas voando pela estrada.
Resposta
Se você tiver acesso SSH (ou SFTP) direto (pergunte ao administrador do sistema), 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, pois ele usará criptografia (porque é sobre SSH) e compactação.
Comentários
- Nesse caso, seria útil desativar a criptografia. Lembre-se de que estamos tentando tornar a cópia mais rápida .
- @lgeorget Eu suspeito que a sobrecarga da criptografia ‘ não será significativa , considerando como os discos rígidos são lentos. Considerei adicionar algo sobre
-c none, mas que parece não ser o padrão . - Estamos ‘ lidando com arquivos ~ 20G, então é bastante ineficiente usar criptografia se não for necessário.
- @lgeorget A criptografia pode ser feito muito mais rápido do que a taxa de transferência que ele ‘ está obtendo, portanto, não ‘ não diminuirá nada. Mas parece desnecessário passar pelo SSH aqui. Se você apenas precisa de compressão, certamente há outras ferramentas?
- @Thomas A vantagem do SSH é que se você ‘ deve ter acesso ao servidor remoto, então, ‘ certamente está executando SSH. Outra opção seria compactar o arquivo localmente, copiá-lo para o servidor,
sshe descompactá-lo.
Resposta
Sua definição de eficiente é ao contrário. Uma implementação mais eficiente desperdiça menos tempo de cpu. Na cópia local, você tem em média cerca de 74 MB / s de taxa de transferência (leitura + gravação), o que é quase tão bom quanto um único disco rígido pode obter.
Comentários
- Ops.Quando eu disse ” eficiente, ” quis dizer ” rápido. ”
Resposta
O cp a implementação provavelmente não é um gargalo. Tente observar o uso de IO por meio de 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, funcionará muito mais rápido se você copiar arquivos 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 hub de conexão direta.
Se dentro desses arquivos 20G, alguma parte é comum e alguns são específicos do nó do cluster, considere dividir em partes comuns e específicas e, em seguida, distribuir a parte comum de maneira p2p.
Comentários
- Se você ‘ em uma LAN, você deve ser capaz de fazer multicast em vez de ponto a ponto. O que deve ser mais rápido e menos carga na rede.
Resposta
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 forem compactáveis ou com partes semelhantes / idênticas, você tem duas abordagens:
-
compactá-los antes de copiar ou criar um túnel entre os computadores com zip habilitado. Então, se a rede é o gargalo, será um pouco mais rápido r
-
se os arquivos forem muito semelhantes ou compartilharem algum conteúdo comum entre eles, tente usar o rsync . Vai levar algum tempo para encontrar o que é comum entre os arquivos e não vai precisar copiá-lo literalmente , porque vai reconstruir com base no que é comum.
edit
Você precisará copiar esses arquivos muitas vezes ?? (como uma cópia -> usar esses arquivos -> alterar algo nos arquivos no computador A -> copie os arquivos novamente para o computador B)
Nesse caso, o rsync será útil, pois tentará detectar o que é igual entre as versões e não copiará o que não foi alterado.
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 alguns binary diff para apenas alterar no segundo computador o que foi alterado no primeiro computador.
Resposta
Vejo o seguinte aqui, a criptografia não é um boa ideia, pois isso pode AUMENTAR a quantidade de dados a serem transferidos.
Se você estiver copiando entre dois sistemas, o gargalo é, obviamente, t A conexão entre os servidores.
Se você estiver copiando localmente, veja como o processo vai, é um SINGLE encadeado, portanto, utilitários Linux padrão 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 assim:
buffer -i infile -o outfile -m size-of-shared-memory-default-1MByte Veja a página de 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 é o buffer circular clássico que evita a sobregravação de dados não gravados e a gravação de dados já gravados. Usei este programa para cortar cerca de 10-20% do tempo de cópia nas transferências do disco para a fita.
Comentários
- 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 do bloco real no fundo (pelo menos, até você começar a ficar sem RAM). Ou se você estiver usando O_DSYNC / O_SYNC por algum motivo.
Resposta
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
Há “s BTSync que você também pode tentar.
Resposta
Se você estiver copiando os mesmos conjuntos de arquivos freqüentemente de seu computador local para o servidor com pequenas alterações aqui e ali. Você pode acelerar a transferência usando rsync ou DVCS (por exemplo, hg ou git).
git ou hg podem acompanhar e detectar deltas e apenas 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 exija mais trabalho para o rsync calcular os deltas, ele não precisa armazenar o todo histórico do arquivo.
Resposta
Você pode tentar compactar todos os arquivos em um único arquivo (não precisa ser compactado). Na minha experiência, copiar aquele arquivo é mais rápido do que copiar um grande número de arquivos individuais
Comentários
- Boa observação genérica, mas como diz a pergunta “~ 200 arquivos grandes – cada um com ~ 20 GB”, não ‘ não acredito que isso possa ser considerado uma resposta real para este problema.
- @manatwork ah .. eu não ‘ li claramente. Achei que ele tinha 200 arquivos totalizando 20 GB
Resposta
Tente bbcp . O teste em nosso ambiente revelou que o cp tinha algum tipo de f construído em governador. Apenas tome cuidado porque ao remover o governador, você pode colocar uma linha vermelha no servidor e causar uma interrupção. No nosso caso, estávamos desligando o servidor para fazer a cópia, então mais rápido era melhor. Isso melhorou o tempo de transferência em várias horas.
Resposta
Certifique-se de que o alvo os arquivos não existem antes de serem copiados.
Às vezes, é surpreendente quanto tempo é gasto, mesmo apenas copiando no mesmo host (sem rede envolvida).
Veja minha resposta a outra questão cp aqui . Resumindo, substituir um arquivo existente é muito mais lento do que truncá-lo ou desvinculá-lo primeiro, e depois copiando. O último é 8x mais rápido para um arquivo de 1,2 GB.
ddersyncpara comparar qual funciona mais rápido em seu ambientedd, mas acabei de tentarrsync. O tempo real foi de cerca de 11,5 minutos e o tempo do sistema foi de cerca de 1,5 minutos, de acordo comtime./dev/sda1para/dev/sdb1será mais rápido do que copiar de um local em/dev/sda1para outro local em/dev/sda1ou outra partição em/dev/sdaporque o disco rígido ganhou ‘ t tem que fazer buscas adicionais entre leituras e gravações (assumindo discos rígidos tradicionais com discos giratórios e cabeças móveis; SSD é obviamente diferente).