Executar um rm -rf em uma grande árvore de diretórios leva horas

20

Estamos usando o rsnapshot para backups. Ele mantém muitos instantâneos do arquivo de backup, mas exclui os antigos. Isso é bom. No entanto, leva cerca de 7 horas para fazer rm -rfuma grande árvore de diretórios. O sistema de arquivos é XFS. Não sei ao certo quantos arquivos existem, mas provavelmente chega a milhões.

Existe alguma maneira de acelerar? Existe algum comando que faz o mesmo rm -rfe não leva horas e horas?

— Rory
fonte

11

Eu usei find . -delete -name directorye é muito mais rápido que rm -rf.

— Paolo

38

Não.

rm -rffaz um percurso recursivo em profundidade do seu sistema de arquivos, chamando unlink()todos os arquivos. As duas operações que fazem com que o processo ocorra lentamente são opendir()/ readdir()e unlink(). opendir()e readdir()dependem do número de arquivos no diretório. unlink()depende do tamanho do arquivo que está sendo excluído. A única maneira de tornar isso mais rápido é reduzir o tamanho e o número de arquivos (que eu suspeito que não seja provável) ou alterar o sistema de arquivos para um com melhores características para essas operações. Eu acredito que o XFS é bom para unlink () em arquivos grandes, mas não é tão bom para grandes estruturas de diretório. Você pode achar que ext3 + dirindex ou reiserfs é mais rápido. Não tenho certeza de quão bem o JFS se sai, mas tenho certeza de que há muitos benchmarks de desempenho diferente do sistema de arquivos.

Edit: Parece que o XFS é péssimo em excluir árvores , então mude definitivamente seu sistema de arquivos.

— David Pashley
fonte

11

Alguns anos atrás, notei um desempenho terrível usando o reiserfs em um caso de uso semelhante.

— knweiss

11

Post maravilhoso!

— Wzzrd

2

É quase acabou de dizer "não" :)

— David Pashley

2

Concordo com tudo aqui, exceto na sua declaração, que desvincula a velocidade de depender do tamanho do arquivo. O link desvincular apenas remove o link para o arquivo e não faz nada com o conteúdo real. Não deve haver diferença discernível entre arquivos de tamanho diferente (você pode testar isso sozinho).

— Kamil Kisiel

@KamilKisiel Você está certo em dizer unlinkque não faz nada com o conteúdo real, mas para executar uma unlinkchamada do sistema, o código do sistema de arquivos ainda tem mais trabalho a fazer se o link removido for o último para o arquivo e se ele não estiver aberto no momento. É claro que isso depende do sistema de arquivos, mas pode haver uma diferença muito discernível quando o arquivo removido é enorme.

— Jlliagre 5/09/16

22

Como alternativa, mova o diretório para o lado, recrie-o com o mesmo nome, permissões e propriedade e reinicie os aplicativos / serviços que se preocupam com esse diretório.

Você pode "rm nice" o diretório original em segundo plano sem precisar se preocupar com uma interrupção prolongada.

— Greg Work
fonte

Isso poderia funcionar, já que um mv é muito, muito rápido.

— Rory

Sim - funciona bem. Eu usei essa técnica várias vezes para "consertar" caixas de correio baseadas em maildir em que um cliente de email perdeu o cérebro e deixou uma bagunça no disco. O maior diretório (único) que eu consertei dessa maneira tinha cerca de 1,5 ou 2 milhões de arquivos IIRC. O tempo de inatividade total para o usuário final foi de aproximadamente 3 minutos, a maioria aguardando a morte dos processos do cliente de email e do imap.

— 28468 Greg Work

7

Verifique se você tem as opções de montagem corretas definidas para o XFS.

Usando -ologbufs = 8, logbsize = 256k com o XFS provavelmente triplicará seu desempenho de exclusão.

— James
fonte

2

+1 para esta dica ... Também é necessário habilitar contadores preguiçosos para outro aumento de desempenho.

— Hurikhan77 21/09/09

11

Alguma explicação sobre essas configurações seria útil para futuros leitores.

— Aron Rotteveel

5

Se você estiver executando a rm efetivamente no nível do arquivo, isso levará um longo tempo. É por isso que os instantâneos baseados em bloco são tão bons :).

Você pode tentar dividir o rm em áreas separadas e tentar fazê-lo em paralelo, no entanto, talvez eu não espere que ele melhore. Sabe-se que o XFS tem problemas para excluir arquivos e, se isso é uma grande parte do que você faz, talvez seja um sistema de arquivos diferente para isso.

— James
fonte

As capturas instantâneas baseadas em bloco não são exclusivamente boas nesse caso. Vários sistemas de arquivos - WAFL e ZFS vêm imediatamente à mente - também fornecem bom desempenho para a exclusão de instantâneos. Eles tratam os instantâneos como objetos do sistema de arquivos de primeira classe. Portanto, em vez de iterar (lentamente) milhões de arquivos para determinar quais blocos liberar, eles precisam apenas procurar a lista de bloqueios associada ao instantâneo.

— 30511 Keith Smith

Hmm. Eu provavelmente pareci ser muito contrário acima. O pôster original deve estar usando Linux, e realmente não existe um sistema de arquivos Linux comprovado que faça instantâneos - embora btrfs e nilfs pareçam interessantes para o futuro. Por uma questão prática, eu concordo --- é melhor usar instantâneos baseados em blocos.

— 30511 Keith Smith

+1 para a dica dividir e paralelizar a carga de trabalho: o xfs exerce sua força em cargas de trabalho paralelas.

— Hurikhan77 21/09/09

5

É bom usar o ionice para operações intensivas de IO, independentemente do sistema de arquivos usado.
Eu sugiro este comando:

ionice -n7 nice rm -fr dir_name

Ele será útil para operações em segundo plano no servidor com carga pesada de E / S.

— ash108
fonte

2

Sei que isso é antigo, mas pensei em dar uma sugestão. Você está excluindo esses arquivos sequencialmente, a execução de operações paralelas de rm pode acelerar as coisas.

http://savannah.nongnu.org/projects/parallel/ parallel pode ser comumente usado no lugar de xargs

por isso, se você está excluindo todos os arquivos em deltedir

find -t f deletedir | parallel -j 10 rm

Isso deixaria você com apenas estruturas de diretório vazias para excluir.

Nota: Você provavelmente ainda atingirá as limitações do sistema de arquivos, conforme observado acima.

— Nick Anderson
fonte

Qual é a vantagem de usar paralelo sobre xargs?

— Rory

1

Uma opção alternativa aqui seria separar os dados de tal maneira que você possa descartar e reconstruir o sistema de arquivos real em vez de executar a rm?

— Moo
fonte

3

Eu acho que o rsnapshot usa links físicos como parte do recurso de manter vários snapshots com eficiência. Então, se o interlocutor está usando esse recurso usando sistemas de arquivos separados não vai funcionar (como você pode não hard-ligação sobre um limite de sistema de arquivos)

— David Spillett

0

Que tal diminuir a gentileza do comando? Gostar:

nice -20 rm -rf /path/to/dir/

— RainyRat
fonte

5

O gargalo não é o agendador, é o sistema de arquivos, eu diria.

— Manuel Faux

No caso improvável de o agendador ser o gargalo, você acabaria pressionando o subsistema de E / S com mais força, tornando o servidor ainda menos utilizável durante a operação.

— David Mackintosh