Como acelerar o rsync / tar de grandes Maildir?

Question

Eu tenho um Maildir muito grande que estou copiando para uma nova máquina (acima de 100BASE-T) com o rsync. O progresso é lento. MUITO DEVAGAR. Como 1 MB / s lento. Eu acho que isso é porque é um monte de pequenos arquivos que estão sendo lidos em uma ordem que essencialmente é aleatória com relação ao local onde os blocos são armazenados no disco, causando uma tempestade de busca em massa. Eu recebo resultados semelhantes ao tentar tar o diretório. Existe uma maneira de obter rsync / tar para ler na ordem de blocos de disco ou superar esse problema?

Editar: Eu tentei tar cf / dev / zero Maildir / e no sistema antigo, isso levou 30 minutos! No novo sistema, quando o rsync finalmente terminou, o mesmo teste demorou 18 minutos. Despejar o mesmo diretório no sistema antigo levou 8 minutos e, no novo sistema, despejar -0f / dev / zero -b 1024 / home / psusi / Maildir / terminou em apenas 30 segundos.

    

Answer 1

Acabei escrevendo um pequeno script python para calcular a correlação entre nomes de diretório e inodes, inodes e blocos de dados e nomes de diretórios para blocos de dados. Acontece que o ext4 tende a ter uma correlação bastante fraca entre a ordem em que os nomes de arquivos aparecem no diretório e onde eles são armazenados no disco. Depois de discuti-lo na lista de discussão ext4, verifica-se que este é o resultado dos índices de diretório hash usados para acelerar pesquisas em diretórios grandes. Os nomes são armazenados em ordem de hash, o que efetivamente embaralha sua ordem em relação a qualquer outra coisa.

Parece-me e pelo menos um outro comentarista que isso é uma deficiência no fs que deve ser corrigido. Ted Ts'o (o mantenedor de ext.) Acha que seria muito difícil fazer isso no fs, e que boas ferramentas (como rsync e tar) devem ter a opção de ordenar o diretório pelo número do inode antes de ler os arquivos.

Portanto, parece que as solicitações de aprimoramento de recursos precisam ser arquivadas para rsync e tar.

    

Answer 2

Poucos pontos a considerar:

• Quantos arquivos estamos falando? find /path/to/your/maildir/ | wc -l deve fornecer uma indicação aproximada. Centenas de milhares devem estar bem. Centenas de milhões podem sugerir que você precise remover, arquivar e geralmente limpar.

• O disco está lento? Há muitos benchmarks disponíveis como o abrangente bonnie++ até o benchmarker rápido e simples do Utilitário de Disco. Corra um e veja se você está sofrendo.

  • Isso pode causar problemas de hardware - substituir por algo mais rápido
  • Problemas no sistema de arquivos - você está usando algo conhecido por ser muito lento em IOPS de leitura aleatória alta?

Mas, em última análise, tar ring e, em seguida, a transferência deve dar a você a melhor taxa de transferência geral, pois você precisa estar lá para configurar a transferência assim que gerar o tar. / p>     

Answer 3

Tente definir a desativação do rastreamento atime ou o uso de um tempo relativo na nova partição de disco. Isso limitará a sobrecarga. Mudar de um sistema de arquivos sem journaling como ext2 para um sistema de arquivos journaling como ext3 ou ext4 terá alguns resultados de performance

Quando movi o Maildirs, fiz um rsync preparatório para colocar todos os diretórios no lugar antes do tempo. Então, havia apenas atualizações para fazer.

Quando você estiver pronto para fazer o movimento real, você pode querer garantir que os diretórios estejam estáveis.

• coloque o daemon SMTP no modo somente fila,
• desativar a execução da fila pelo daemon SMTP e
• desativa o acesso pelo usuário.

Reative após a conclusão da movimentação do arquivo.

EDIT: Eu acho que você identificou o problema. O tar e o rsync percorrerão os diretórios. Devido a alterações normais de arquivo no Maildir, os arquivos de cada diretório acabarão espalhados pelo disco. Uma ferramenta como dump leria a partição em ordem de blocos, mas replicaria o problema para a nova partição. Um segundo rsync deve correr muito mais rápido que o segundo.