Não é uma solução, mas uma solução alternativa: você pode iniciar o rm com ionice -c3 . Se você puder reproduzir esse problema, poderá rastreá-lo com strace -tt -o rm.strace rm ... e contatar os desenvolvedores do ext4.
Eu encontrei este problema extremamente estranho em dois servidores agora, ambos executando o CentOS5, ambos ext4. Um é um SSD, o outro é um disco rígido regular, ambos SATA sem RAID.
O problema é o seguinte, quando executo rm -r em um diretório com um grande número de subdiretórios (> 1000), onde cada subdiretório possui um grande número de arquivos (> 1000), o disco onde esses diretórios residem irá bloquear de forma intermitente.
Isso pode ser visto no topo. Geralmente, o comando rm terá um uso da CPU de 50 a 60%, mas, de repente, cairá para zero por 10 a 15 segundos antes de retornar para 50 a 60% por 3 a 4 segundos antes de voltar a zero. Durante o tempo em que o comando rm está em 0% cpu, até mesmo comandos simples como ls na unidade em questão serão interrompidos e nada aparecerá na tela até que o rm esteja rodando a 50-60% novamente.
Quando o rm está rodando a 0%, no topo, eu também recebo 0.0% wa.
Como você pode imaginar, essa suspensão constante do disco torna o processamento extremamente lento. Eu hesito em colocar a culpa em um disco defeituoso porque já vi esse comportamento em dois sistemas diferentes.
Alguém tem alguma ideia?
EDIT: Também quero salientar que quando rm está rodando a 0.0% cpu, jbd2 / sdc1-8 ainda está ativo no disco em questão.
Não é uma solução, mas uma solução alternativa: você pode iniciar o rm com ionice -c3 . Se você puder reproduzir esse problema, poderá rastreá-lo com strace -tt -o rm.strace rm ... e contatar os desenvolvedores do ext4.
Em primeiro lugar,
No sistema de arquivos ssd, você desejará ativar a opção desprezível . por exemplo,
# mount -t ext4 -o discard /dev/ssd_dev /mnt/storage/location
Você pode ler sobre isso aqui (RedHat Ajuste SSD)
Por fim, convém revisar os tamanhos dos seus blocos como discos rígidos e tamanhos de SSDs diferentes. Mas se você não quiser reinstalar o sistema, então eu acho que uma remontagem com a opção de desconforto deve fazer o truque.
Atualizado: O rm lento pode ser atribuído à barreira de gravação do sistema de arquivos, conforme explicado aqui
Felicidades, Danie
A exclusão de milhões de arquivos resulta em milhões de transações. Isso vai preencher rapidamente o diário. As barracas que você está vendo são causadas pela publicação do jornal.
O uso de um diário maior deve permitir que mais transações sejam colocadas em lote antes da exibição, portanto, você deverá ver menos estolinhas como essa.
O tamanho do diário padrão é normalmente de 128 MB. Você pode usar tune2fs -J size=512 em um fs limpo e não montado para quadruplicar o tamanho do diário
Descobri que, ao usar a opção recursiva para remover um grande número de arquivos, é melhor escrever um script bash simples usando um loop for para remover arquivos individualmente. Algo semelhante a:
for f in /path/to/dir/*
do
# if file, delete it
[ -f "$f" ] && rm "$f"
done
Tags performance rm storage linux