Otimizando o armazenamento de 10 a 20 milhões de arquivos no RAID5 (atualmente usando o LVM + XFS)

Question

Embora eu tenha pesquisado algumas das questões aqui, acho que cada situação é diferente e talvez exija uma solução totalmente diferente.

O que eu tenho agora:

• RAID5 de software Linux no HDD corporativo 4x4TB
• LVM no topo com alguns volumes
• O mais importante, o volume de armazenamento, um XFS de 10 TB
• Toda a configuração com parâmetros padrão no Debian Wheezy
• O volume é montado com opções 'noatime, nodiratime, allocsize = 2m'
• Cerca de 8 GB de RAM livre e usado para armazenamento em cache Eu acho, CPU Intel quad core com HT não muito usado

Este volume armazena principalmente cerca de 10 milhões de arquivos (no máximo 20M no futuro) entre 100K e 2M. Essa é uma distribuição mais precisa de intervalos de tamanho de arquivo (em K) e números no intervalo:

       4    6162
       8      32
      32      55
      64   11577
     128    7700
     256    7610
     512     555
    1024    5876
    2048    1841
    4096   12251
    8192    4981
   16384    8255
   32768   20068
   65536   35464
  131072  591115
  262144 3411530
  524288 4818746
 1048576  413779
 2097152   20333
 4194304      72
 8388608      43
16777216      21

Os arquivos são armazenados principalmente no nível 7 do volume, algo como:

/volume/data/customer/year/month/day/variant/file

Normalmente há arquivos de ~ 1-2K dentro dessas pastas, às vezes menos, outras vezes até 5-10K (casos raros).

OI / O não é tão pesado, mas eu experimento trava ao empurrá-lo um pouco mais. Por exemplo:

• O aplicativo que executa a maior parte da E / S é o NGINX para leitura e gravação
• Existem algumas leituras aleatórias de 1-2MB / s TOTAL
• Eu tenho algumas pastas onde os dados são gravados continuamente a uma taxa de 1-2MB / s TOTAL e todos os arquivos com mais de 1h devem ser removidos periodicamente das pastas

Executar o cron seguinte uma vez por hora trava por alguns bons segundos o servidor inteiro muitas vezes e pode até mesmo interromper o serviço (a gravação de novos dados) conforme os tempos limite de E / S são gerados:

find /volume/data/customer/ -type f -iname "*.ext" -mmin +60 -delete
find /volume/data/customer -type d -empty -delete

Também observo velocidades de gravação baixas (poucos MB / s) ao gravar arquivos nos intervalos acima. Ao escrever arquivos maiores, ele fica OK até que o cache de gravação seja preenchido (obviamente) e, em seguida, a velocidade cai e começa a desligar o servidor em ondas.

Agora, estou procurando uma solução para otimizar meu desempenho de armazenamento, pois tenho certeza de que não sou ideal em padrões e muitas coisas podem ser melhoradas. Embora não seja tão útil para mim, eu não abandonaria o LVM se ele não fornecer ganho significativo também porque, embora possível, eu não reinstalaria o servidor inteiro descartando o LVM.

Leia muito sobre XFS vs. ReiserFS vs. Ext4, mas estou bastante intrigado. Outros dos meus servidores em um volume RAID1 2TB muito menor, mas exatamente a mesma configuração e carga de trabalho significativamente mais pesada, desempenham bastante sem falhas.

Alguma idéia?

Como devo depurar / experimentar?

Obrigado.

    

Answer 1

Primeiro, o XFS é a escolha certa para esse tipo de cenário: com o XFS é quase impossível sair de inodes.

Para aumentar o desempenho da exclusão, tente o seguinte:

• use o agendador deadline de E / S, em vez de o (padrão) cfq
• use logbsize=256k,allocsize=64k como opções de montagem (além de nodiratime,noatime )

Para diminuir o impacto das exclusões em outras atividades do sistema, tente executar o script find usando ionice -c 2 -n 7

Relate seus resultados!

    

Answer 2

Concorde com Shodanshok que o prazo final é provavelmente uma boa ideia. Longe de convencido de que você deveria estar usando o XFS aqui.

find /volume/data/customer/ -type f -iname "*.ext" -mmin +60 -delete

O XFS costumava ser muito ruim com a exclusão de arquivos - foi-me dito que a maioria dos bugs nesta área foi resolvida, mas não foi feito nenhum benchmarking para confirmar isso.

it goes OK until write cache fills (obviously) and then speed drops and starts hanging the server in waves

Pendurado? Parece que você deveria ajustar suas taxas de páginas sujas (diminuir raio de fundo, aumentar taxa de bloqueio) você também deve mudar o dirty_expire_centisecs (para cima ou para baixo - veja o que o torna mais rápido!) e diminuir o dirty_writeback_centisecs se a carga geral e o uso da CPU forem aceitáveis .

Se as instruções 'find' estiverem processando a maior parte dos dados, ajustar o vfs_cache_pressure seria uma boa ideia. Novamente, a única maneira de descobrir o valor correto é por tentativa e erro, mas com um fanout muito alto e presumivelmente com pouca leitura dos arquivos de dados, diminuí-lo deve melhorar a eficácia do cache.

Observe que os instantâneos do LVM eliminarão a taxa de transferência de E / S.

---- as coisas acima se aplicam independentemente do sistema de arquivos que você escolher ----

A consideração mais importante quando você escolhe um sistema de arquivos é o quão robusto você precisa ser. Se estes são todos arquivos temporários, e você não se importa de perder todos eles no final de uma falha / não precisa de tempos de recuperação rápidos após uma interrupção, então você não deveria estar usando um sistema de arquivos de uso diário. Mas você não nos contou muito sobre os dados.

Observando a alta fanout ... o recurso dir_index do ext3 / 4 foi explicitamente adicionado para fornecer uma resolução mais rápida e mais eficiente quando um diretório contém um grande número de arquivos / alta rotatividade de arquivos. Eu não sei quão efetivo o XFS é neste cenário.

O ReiserFS não é mais bem suportado.

Existem várias outras coisas que você pode querer ver (incluindo UPS, bcache, dispositivos de diário dedicados), mas eu não teria uma desculpa para insira um livro sobre o assunto .