Eu tenho um servidor de backup Ubuntu 16.04 com disco rígido de 8x10 TB por meio de um backplane SATA 3.0. Os 8 discos rígidos são montados em um RAID6, um sistema de arquivos EXT4 está em uso. Este sistema de arquivos armazena uma enorme quantidade de arquivos pequenos com muitas operações SEEK, mas baixa taxa de transferência de E / S. De fato, existem muitos arquivos pequenos de diferentes servidores que são capturados instantaneamente via rsnapshot todos os dias (vários INODES direcionam para os mesmos arquivos. Eu tenho um desempenho muito ruim, pois o sistema de arquivos (rede de 60 TB) excedeu 50% de uso. No momento, o uso é de 75% e um

du -sch /backup-root/

leva vários dias (!). A máquina possui 8 núcleos e 16G de RAM. A RAM é totalmente utilizada pelo cache do sistema de arquivos do sistema operacional, 7 dos 8 núcleos sempre ociosos por causa do IOWAIT.

Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          5af205b0-d622-41dd-990e-b4d660c12bd9
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              912203776
Block count:              14595257856
Reserved block count:     0
Free blocks:              4916228709
Free inodes:              793935052
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        768
Flex block group size:    16
Filesystem created:       Wed May 31 21:47:22 2017
Last mount time:          Sat Apr 14 18:48:25 2018
Last write time:          Sat Apr 14 18:48:18 2018
Mount count:              9
Maximum mount count:      -1
Last checked:             Wed May 31 21:47:22 2017
Check interval:           0 (<none>)
Lifetime writes:          152 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       513933330
Default directory hash:   half_md4
Directory Hash Seed:      5e822939-cb86-40b2-85bf-bf5844f82922
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke journal_64bit
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00c0b9d5
Journal start:            30179

Não tenho experiência com esse tipo de uso do sistema de arquivos. Que opções eu tenho para ajustar isso. Qual sistema de arquivos teria melhor desempenho com esse cenário? Existem opções para envolver a RAM em outras opções de armazenamento em cache que não a do OS-build-in?

Como você lida com grandes quantidades de arquivos pequenos em montagens RAID grandes?

Obrigado Sebastian

Eu tenho uma configuração semelhante (embora menor), com discos de 12x 2 TB em uma matriz RAID6, usada para a mesma finalidade ( rsnapshotservidor de backup).

Primeiro, é perfeitamente normal du -hslevar tanto tempo em um sistema de arquivos tão grande e usado. Além disso, é duresponsável por hardlinks, que causam uma carga considerável e explosiva na CPU, além da carga óbvia de E / S.

Sua lentidão se deve ao fato de os metadados do sistema de arquivos estarem localizados em blocos muito distantes (em termos de LBA), causando muitas buscas. Como um disco normal de 7,2K RPM fornece cerca de 100 IOPS, é possível ver quantas horas, se não dias, são necessárias para carregar todos os metadados.

Algo que você pode tentar (não destrutivamente) melhorar a situação:

• certifique-se de não ter mlocate/slocateindexado seu /backup-root/(você pode usar o recurso de remoção de poda para evitar isso) ou a lixeira do cache de metadados prejudicará gravemente o tempo de backup;
• pela mesma razão, evite correr duem /backup-root/. Se necessário, execute duapenas na subpasta específica interessada;
• abaixe vfs_cache_pressuredo valor padrão (100) para um valor mais conservador (10 ou 20). Isso instruirá o kernel a preferir o cache de metadados, ao invés do cache de dados; por sua vez, isso deve acelerar a rsnapshot/rsyncfase de descoberta;
• você pode tentar adicionar um dispositivo de armazenamento em cache de metadados, por exemplo, via lvmcache ou bcache . Esse dispositivo de metadados deve obviamente ser um SSD;
• aumentar sua RAM disponível.
• enquanto você estiver usando o ext4, esteja ciente dos problemas de alocação de inodes (leia aqui por exemplo). Isso não está diretamente correlacionado ao desempenho, mas é um fator importante ao ter tantos arquivos em um sistema de arquivos ext.

Outras coisas que você pode tentar - mas são operações destrutivas:

• use XFS com ambos -ftypee -finobtconjunto de opções;
• use o ZFS no Linux (ZoL) com ARC compactado e primarycache=metadataconfiguração (e, talvez, um L2ARC para cache somente leitura).

Este sistema de arquivos armazena uma enorme quantidade de arquivos pequenos com muitas operações SEEK, mas baixa taxa de transferência de E / S.

🎉

Isso é coisa que pega muita gente hoje em dia. Infelizmente, FSes convencionais não escalam bem aqui. Provavelmente, posso dar-lhe alguns conselhos quando se trata da instalação que você já possui: EXT4 sobre RAID-6 em HDDs :

1. Mais vm.vfs_cache_pressureabaixo, digamos 1. Ele mudaria o viés de cache para preservar mais metadados (inode, dentry) em vez dos dados em si e deve ter um efeito positivo na redução do número de pesquisas
2. Adicione mais RAM . Embora possa parecer estranho para um servidor que não executa nenhum aplicativo piggy, lembre-se: a única maneira de reduzir as buscas é manter mais metadados em um armazenamento mais rápido, já que você tem 16 GB apenas, parece que deve ser relativamente fácil aumentar a quantidade de RAM
3. Como eu disse, o EXT4 não é uma boa escolha para o caso de uso que você possui, mas ainda é possível usar alguns dos recursos que ele apresenta para aliviar a dor:
   • O diário externo é suportado para que você possa tentar adicionar SSD (melhor espelhado) e colocar o diário lá. Confira " ext4: advertências externas do diário "
   • Tente alternar o modo de diário para "todos os dados sendo registrados" montando comdata=journal
4. Tente mover arquivos fora do escopo do FS único . Por exemplo, se você possui o LVM-2 aqui, pode criar volumes de tamanho menor e usá-los por um tempo; quando estiver cheio, crie outro e assim por diante.
   • Se você não possui LVM-2, pode tentar fazer isso com / dev / loop, mas não é tão conveniente e provavelmente com menos desempenho

UPD. : como acabou sendo o RAID-6 do Linux Software RAID (LSR), aqui vai o item adicional:

5. O LSR tem opções de ajuste próprias que muitas pessoas parecem ignorar
   • Cache de distribuição , que pode ser definido assim ao máximo: echo 32768 | sudo tee /sys/devices/virtual/block/md*/md/stripe_cache_size- Mas faça isso com cuidado (use um valor menor, se necessário), pois o tamanho é múltiplo e depende do tamanho do pedaço que você escolher, será necessária uma quantidade diferente de RAM
   • O diário externo que também pode estar nos SSDs espelhados ( mas atualmente o dispositivo MD criado sem o diário não pode ser convertido para usar um ).

- Isso é provavelmente a maior parte do que pode ser aprimorado sem re-design do zero.

Eu tenho um desempenho muito ruim, pois o sistema de arquivos (60TB líquido) excedeu 50% de uso. No momento, o uso é de 75%

Esse é um problema muito sério, porque esse alto nível de ocupação de espaço em disco só piora a fragmentação. E mais fragmentação significa mais buscas. Já não se pergunta por que deu desempenho mais ou menos aceitável antes de atingir 50%. Muitos manuais têm recomendações claras para não permitir que os FSs cresçam para trás de 75 a 80%.

O RAID6 não ajuda muito nesse caso, algo como o ZFS pode permitir acesso a metadados e diretórios muito mais rápido, mantendo as velocidades iguais.

RAID-6 distribui unidades, portanto, todas as E / S vão para todas as unidades. Isso é bastante ineficiente com muitos arquivos pequenos. No entanto, este provavelmente não é o seu principal problema, que é ...

O Ext4 não é adequado para grandes sistemas de arquivos com milhões de arquivos. Use o XFS . Eu tenho sistemas de arquivos XFS executando até 1,2 PB e com até 1 bilhão de arquivos, não há problema. Basta usar o XFS .

Obrigado a todos que responderam à minha pergunta.

Isto é, como eu resolvi:

Antes de tudo, adicionei a quantidade máxima de RAM à placa. Infelizmente, a placa suporta apenas até 64 GB de RAM. Eu observei o comportamento após a expansão, e foi decepcionante. Embora toda a RAM disponível tenha sido usada para o IO Cache, o desempenho do RSNAPSHOT-Backup não melhorou de forma mensurável.

Então eu tive que puxar a maça grande. Adicionei dois discos NVME de 1 TB e os montei em um RAID 1. O RAID 6, composto de 8x 10 TB de HDDs, foi desmontado em um RAID 1 (consistindo em 2x 10TB HDD, ext4) e um RAID 5 (6x10TB HDD). O RAID 1 agora contém o sistema operacional e a cópia de trabalho dos servidores (que são sincronizados 4 vezes por dia nesta unidade).

O RAID5 agora é um dispositivo suportado pelo BCACHE, suportado pelo NVME-RAID 1 e formatado com ext4. Esta unidade contém as cópias RSNAPSHOT. Todas as noites, os arquivos são sincronizados do RAID1 para o RAID5, o que reduz pela metade a taxa de transferência IO do RAID5 em comparação com o antigo RAID6, que continha as cópias de trabalho E os instantâneos de backup. Graças ao BCache, nem todos os arquivos são gravados literalmente nos discos, mas todas as alterações em um bloco são gravadas uma vez, mesmo que contenha várias alterações de arquivo único. Isso diminuiu ainda mais as IOps nos HDDs.

Finalmente, mudei minha configuração do RSnapshot. Anteriormente, havia 31 instantâneos diários e 18 instantâneos mensais, o que resultou em 49 gerações de backup. Agora, eu tenho o design clássico 7d / 4w / 12m / 1y, que reduz a quantidade de gerações de backup para 24.

Após essas alterações (e com a RAM de 64 GB mencionada acima), a duração de um instantâneo diminuiu de ~ 20 horas para 1,5 horas. Os dispositivos BCache têm uma taxa de acerto no cache de 82% (após 6 semanas de operação regular).

Missão cumprida. Obrigado a todos por seus pensamentos e sugestões.