rsync com servidor multi-core deve ir mais rápido do que vai. Estou errado?

Question

Estou lançando um comando rsync simples entre dois servidores. Ambos os servidores possuem duas interfaces eth na ligação. Quando envio um arquivo grande de um servidor para outro com o rsync, alcanço uma taxa de transferência de 130M / s.

Mas, e eis o problema, quando envio um diretório com muitos arquivos pequenos, a transferência é de 1M / s no seu melhor.

Eu verifiquei as duas cargas de CPU (8cpu i7) e elas estão com 10% no máximo.

Sabendo que o que faz com que toda a transferência fique mais lenta é o abrir / fechar dos arquivos, e isso 'teoricamente' vai para a cpu, eu entendo que isso pode ser facilmente ajustado. Mas eu não sei como afinar isso.

Alguma dica sobre como fazer o rsync usar todas as CPUs?

    

Answer 1

Seu problema não tem (quase) nada a ver com a CPU.

A transferência de arquivos grandes geralmente é rápida, já que isso pode ser feito com E / S sequencial.

A transferência de muitos arquivos pequenos requer toneladas de potência no lado do armazenamento, já que requer E / S aleatória. Tempos de busca reduzidos, discos rígidos rápidos, muito cache e um sistema de arquivos projetado para um grande número de arquivos são obrigatórios. CPU não ajuda lá, pelo menos não muito, assim como você está observando. A CPU e o sistema operacional estão apenas aguardando a conclusão da E / S de disco.

Tudo o que mais CPU / núcleos mais rápidos podem fazer, eles podem acabar esperando por E / S mais rápido. : -)

    

Answer 2

A latência de muitas operações de E / S aleatórias é pequena:

• acessar e procurar tempos de sistema de arquivos e discos rígidos
• tempos de comparação do rsync

Na minha experiência, o rsync é uma ferramenta muito boa para manter as coisas sincronizadas, mas não é uma ferramenta muito boa para enviar todos os dados o mais rápido possível. Use quando a largura de banda ou a capacidade de armazenamento não deixar outras opções. Se você puder arcar com todos os arquivos e transferir em um blob, você pode esperar um aumento no desempenho (tempo total do relógio de parede usado para concluir a operação), se houver arquivos suficientes.

    

Answer 3

Há muita sobrecarga de rede / disco ao lidar com muitos arquivos pequenos usando o rsync. Com arquivos pequenos o suficiente, seu fator de aceleração pode ser menor que 1.

Preste atenção no fator de aceleração usando -v. Se o seu fator de aceleração estiver abaixo de 1, mesmo quando você já sabe que está em sincronia, você está passando por muita sobrecarga. A CPU não é o gargalo.

    

Answer 4

O que Janne disse: você é vinculado a E / S, não vinculado à CPU. Inicialize o topo (ou melhor, no topo / htop), observe como pouca CPU é realmente usada ao transferir arquivos pequenos. Observe também que seus processos estão no estado 'D', aguardando que os dados estejam disponíveis para eles.

Além disso, não acredito que o rsync seja otimizado para vários núcleos; a maior parte do que faz é sequencial, e exigiria um trabalho muito inteligente para torná-lo mais rápido a esse respeito.

No entanto, ele provavelmente tira proveito de até 2 núcleos se você usar o ssh como um transporte. Ele será gerado como um processo separado e fará toda a sua criptografia e, possivelmente, o trabalho de compactação em um thread separado do processo principal de rsync. Esse processo tem um pouco de tarefas intensivas de CPU: cálculo de CRC e hashing MD5 (acredito que é isso que ele usa).