Por que meus sistemas de arquivos XFS estão consumindo repentinamente mais espaço e arquivos esparsos?


62

Já corri XFS sistemas de arquivos como partições de dados / de crescimento para quase 10 anos em vários servidores Linux.

Percebi um fenômeno estranho com os servidores CentOS / RHEL recentes executando a versão 6.2+.

O uso estável do sistema de arquivos tornou-se altamente variável após a mudança para a revisão mais recente do sistema operacional do EL6.0 e EL6.1. Os sistemas inicialmente instalados com EL6.2 + exibem o mesmo comportamento; mostrando desvios na utilização do disco nas partições XFS (consulte a linha azul no gráfico abaixo).

Antes e depois. A atualização de 6.1 para 6.2 ocorreu no sábado. gráfico xfs

O gráfico de uso de disco do mesmo sistema do trimestre anterior, mostrando as flutuações da última semana. insira a descrição da imagem aqui

Comecei a verificar os sistemas de arquivos em busca de arquivos grandes e processos descontrolados (arquivos de log, talvez?). Descobri que meus maiores arquivos estavam relatando valores diferentes de due ls. Correr ducom e sem o --apparent-sizeinterruptor ilustra a diferença.

# du -skh SOD0005.TXT
29G     SOD0005.TXT

# du -skh --apparent-size SOD0005.TXT
21G     SOD0005.TXT

Uma verificação rápida usando o utilitário ncdu em todo o sistema de arquivos resultou em:

Total disk usage: 436.8GiB  Apparent size: 365.2GiB  Items: 863258

O sistema de arquivos está cheio de arquivos esparsos , com quase 70 GB de espaço perdido em comparação com a versão anterior do sistema operacional / kernel!

Examinei o Red Hat Bugzilla e alterei os logs para ver se havia algum relatório do mesmo comportamento ou novos anúncios sobre o XFS.

Nada.

Eu fui da versão 2.6.32-131.17.1.el6 do kernel para 2.6.32-220.23.1.el6 durante a atualização; nenhuma alteração no número da versão secundária.

Eu verifiquei a fragmentação do arquivo com a filefragferramenta. Alguns dos maiores arquivos da partição XFS tinham milhares de extensões. A execução da desfragmentação online xfs_fsr -vdurante um período lento de atividade ajudou a reduzir temporariamente o uso do disco (consulte quarta-feira no primeiro gráfico acima). No entanto, o uso aumentou assim que a atividade pesada do sistema foi retomada.

O que esta acontecendo aqui?


2
Mmm ... Piazza ....
Tom O'Connor

Respostas:


76

Rastreei esse problema em uma discussão sobre um commit na árvore de fontes XFS a partir de dezembro de 2010. O patch foi introduzido no Kernel 2.6.38 (e, obviamente, mais tarde foi portado em alguns kernels de distribuição Linux populares).

As flutuações observadas no uso do disco são resultado de um novo recurso; Pré-alocação dinâmica EOF especulativa do XFS .

Essa é uma ação para reduzir a fragmentação de arquivos durante as gravações de streaming, alocando especulativamente espaço à medida que o tamanho dos arquivos aumenta. A quantidade de espaço pré-alocado por arquivo é dinâmica e é principalmente uma função do espaço livre disponível no sistema de arquivos (para impedir totalmente a falta de espaço).

Segue esta programação:

freespace       max prealloc size
  >5%             full extent (8GB)
  4-5%             2GB (8GB >> 2)
  3-4%             1GB (8GB >> 3)
  2-3%           512MB (8GB >> 4)
  1-2%           256MB (8GB >> 5)
  <1%            128MB (8GB >> 6)

Esta é uma adição interessante ao sistema de arquivos, pois pode ajudar com alguns dos arquivos massivamente fragmentados com os quais eu lido.

O espaço adicional pode ser recuperado temporariamente, liberando o pagecache, dentries e inodes com:

sync; echo 3 > /proc/sys/vm/drop_caches

O recurso pode ser desativado completamente definindo um allocsizevalor durante a montagem do sistema de arquivos. O padrão para o XFS é allocsize=64k.

O impacto dessa mudança provavelmente será sentido pelos sistemas de monitoramento / limiar (como foi o caso), mas também afetou os sistemas de banco de dados e pode causar resultados imprevisíveis ou indesejados para máquinas virtuais e matrizes de armazenamento com provisionamento dinâmico (elas usarão mais espaço do que o esperado).

No geral, isso me pegou de surpresa porque não havia um anúncio claro da alteração do sistema de arquivos no nível de distribuição ou mesmo no monitoramento da lista de discussão do XFS .


Editar : o
desempenho em volumes XFS com esse recurso é drasticamente aprimorado. Estou vendo uma fragmentação <1% consistente em volumes que anteriormente exibiam até 50% de fragmentação. O desempenho de gravação aumenta globalmente!

Estatísticas do mesmo conjunto de dados, comparando o XFS herdado com a versão no EL6.3.

Velho:

# xfs_db -r -c frag /dev/cciss/c0d0p9
actual 1874760, ideal 1256876, fragmentation factor 32.96%

Novo:

# xfs_db -r -c frag /dev/sdb1
actual 1201423, ideal 1190967, fragmentation factor 0.87%

4
Um milhão de upvotes e meu reino para você
Joel E Salas

11
Obrigado! Nós apenas atualizou do Debian Squeeze para Ubuntu e tinha sido perguntando por du e ls foram mostrando tais valores muito diferentes para arquivos bastante largo (por exemplo, 50Mb vs 64Mb.)
Giles Thomas

11
@ewwhite Você desativou esse recurso para recuperar o espaço? Ou este artigo está apenas dizendo, ei, esse recurso foi o que estava causando a discrepância nos tamanhos relatados? Parece que "em sistemas de banco de dados ou VMs com thin provisioning, considere desativar isso", mas não tenho certeza do que você decidiu fazer.
JDS

2
@jds eu deixo ligado. Elimina a fragmentação e teve um aumento de desempenho em meus aplicativos.
Ewwhite

3
Oh, descoberta maravilhosa. Isso usava 750 GB em 35 GB de arquivos. Depois xfs_fsrde voltar para cerca de 35 GB. Eu vou ter que ficar de olho no que
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.