Como evitar a remoção de subárvore (`rm -rf`) de outros processos para a E / S de disco?


8

Temos um diretório de cache Nginx muito grande (vários GB) para um site ocupado, que ocasionalmente precisamos limpar todos de uma vez. Eu resolvi isso no passado, movendo a pasta de cache para um novo caminho, criando uma nova pasta de cache no caminho antigo e depois rm -rfinserindo a pasta de cache antiga.

Ultimamente, no entanto, quando preciso limpar o cache em uma manhã movimentada, a E / S de deixa de lado os rm -rfprocessos de acesso ao disco do meu servidor, pois o Nginx e o servidor para o qual ele se relaciona exigem muita leitura. Eu posso assistir a média de carga subir enquanto as CPUs permanecem ociosas e rm -rfabsorvem 98-99% do disco IO iotop.

Eu tentei ionice -c 3ao invocar rm, mas parece não ter um efeito apreciável no comportamento observado.

Existe alguma maneira de domar rm -rfcompartilhar mais o disco? Preciso usar uma técnica diferente, a qual seguirá as dicas ionice?

Atualizar:

O sistema de arquivos em questão é um armazenamento de instância do AWS EC2 (o disco principal é o EBS). A /etc/fstabentrada fica assim:

/dev/xvdb       /mnt    auto    defaults,nobootwait,comment=cloudconfig 0       2

Você provavelmente também deve mencionar o sistema de arquivos que está usando e como (opções de montagem).
Cristian Ciupitu 15/10

Atualizada. Além disso, caso isso importe, isso é no Ubuntu 12.04.
David Eyk

Observe que o desempenho de E / S no Amazon EBS pode ser muito ruim. Consulte perfcap.blogspot.com/2011/03/…, que recomenda um máximo de 100 iops a longo prazo, com rajadas de curto prazo (1 minuto) até 1000. Parece que seu caso é muito mais alto do que em um minuto, daí o problema.
Moshe Katz

Certo, é por isso que estamos usando um armazenamento de instância, não o EBS, para o cache. Veja meu comentário de atualização. Desculpe se isso não estava claro.
David Eyk

Desculpe o atraso, mas você poderia investigar cgroups e o controlador blkio: kernel.org/doc/Documentation/cgroups/blkio-controller.txt
AndreasM

Respostas:


3

Todos os dados coletados nesta página. Abaixo estão algumas opções para excluir um grande diretório de arquivos. Confira o artigo para obter detalhes de como isso foi produzido.

% Do tempo decorrido do sistema do comando CPU cs1 * (Vol / Invol)
rsync -a - exclua vazio / a 10,60 1,31 95% 106/22
find b / -type f -delete 28,51 14,46 52% 14849/11
encontre c / -type f | xargs -L 100 rm 41,69 20,60 54% 37048/15074
encontre d / -type f | xargs -L 100 -P 100 rm 34,32 27,82 89% 929897/21720
rm -rf f 31,29 14,80 47% 15134/11

* cs1 é contexto alterna voluntário e involuntário


Embora isso possa teoricamente responder à pergunta, seria preferível incluir aqui as partes essenciais da resposta e fornecer o link para referência.
Tom O'Connor

Fascinante! Eu vou tentar.
David Eyk

rsyncestá funcionando agora. Talvez seja muito cedo para dizer, e pode ser ajudado que eu não o esteja executando no meio de uma manhã movimentada, mas o servidor ainda responde e a média de carga é gerenciável.
David Eyk

A invocação exata que estou usando:ionice -c 3 nice -19 rsync -a --delete /mnt/empty/ /mnt/nginx-cache-old
David Eyk 23/10

Bem, isso levou apenas 4 horas. ;) Vou aceitar esta resposta (desculpe @aferber), pois gosto da chamada direta e ela parece suscetível nicee ionice, ou pelo menos não destruiu o servidor como o rm -rffez.
David Eyk

9

A remoção de arquivos realiza apenas operações de metadados no sistema de arquivos, que não são influenciadas pelo ionice.

A maneira mais simples seria, se você não precisar do espaço em disco no momento, executar o rmhorário fora de pico.

A maneira mais complexa como o PODE trabalhar é espalhar as exclusões ao longo do tempo. Você pode tentar algo como o seguinte (observe que ele pressupõe que seus caminhos e nomes de arquivos NÃO contêm espaços!):

while find dir -type f | head -n 100 | xargs rm; do sleep 2; done
while find dir -type d -depth | head -n 100 | xargs rmdir; do sleep 2; done

Observe também que você não pode usar rm -fo primeiro comando, pois o loop não para (depende do código de saída de erro de rmquando não há argumento).

Você pode ajustá-lo modificando o número de exclusões por ciclo (100 no exemplo) e a duração do sono. No entanto, pode não funcionar realmente, pois o sistema de arquivos ainda pode agrupar as atualizações de metadados de maneira que você tenha problemas com a carga de IO. Você apenas tem que tentar.


A remoção de muitos arquivos leva muito tempo, então não há realmente nenhum período "fora do pico" que o abranja. :(
David Eyk 15/10

O whileloop parece fazer o truque quando head -n 50. 100 ainda estava aumentando lentamente a média de carga acima do crítico, o que me indica que havia muita contenção de recursos.
David Eyk

Cara, isso leva muito tempo para correr!
David Eyk

A localização ainda vai listar todos os arquivos no diretório e todos os subdiretórios para cada iteração do loop while. Você provavelmente poderia fazer melhor com algo como
Randy Orrison

1
A localização ainda vai listar todos os arquivos no diretório e todos os subdiretórios para cada iteração do loop while. Você provavelmente poderia fazer melhor com algo como find dir -type f -print0 | xargs -l50 -0 rmwait em que rmwait é um script que rm "$ @"; sleep 2. Observe o uso de -print0 e -0 para manipular nomes de arquivos com espaços. -l50 diz ao xargs para fazer apenas 50 por vez.
precisa

-1

Você pode emparelhá-lo com o comando "nice". ionice -c 3 nice -19 rm -rf /some/folder

Isso muda a prioridade do processo na máquina.


Infelizmente, niceparece ter tanto efeito quanto ionice, ou seja, nada apreciável.
David Eyk

@DavidEyk. Se nice e ionice não têm efeito "perceptível", significa que nada mais está disputando recursos de maneira apreciável, ou você simplesmente não está percebendo o efeito a olho nu. Você realmente deve compará-lo usando o iostat e o vmstat para ver o efeito real.
Michael Martinez

Acredito que o @aferber abordou isso em sua resposta: "A remoção de arquivos realiza apenas operações de metadados no sistema de arquivos, que não são influenciadas pela ionice". Eu já vi a disputa - meus processos de servidor estavam famintos pelo tempo de leitura enquanto a CPU rm -rfficava vazia e 99% ligada iotop.
David Eyk
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.