Os requisitos e restrições:
- 50:50 leitura: taxa de gravação
- Os arquivos que estão sendo gravados variam de tamanho maior que o tamanho do bloco e são muito maiores que o tamanho do bloco.
- As solicitações individuais variam de 128 KB a 4 MB
- No Linux
- O sistema de arquivos será bem grande, com 14 TB.
Desconhecidos que ajudariam:
- Se a E / S aleatória está ou não dentro dos arquivos, ou se é puramente baseada em arquivos inteiros sendo lidos e gravados em fragmentos de 128 KB-4 MB
- A frequência das atualizações de arquivos.
- Concorrência: a frequência de operações paralelas de leitura / gravação (operações de E / S).
E / S sequencial
Se a proporção de 50:50 é representada pela leitura e gravação de arquivos inteiros e arquivos bastante grandes, então seus padrões de acesso são mais sequenciais do que aleatórios no que diz respeito a um sistema de arquivos. Use um sistema de arquivos baseado em extensão para aumentar a sequencialidade em seu sistema de arquivos para melhor desempenho. Como os arquivos são muito grandes, a leitura antecipada fornecerá melhorias significativas no desempenho se for suportada pelo hardware (alguns controladores RAID fornecem isso).
E / S aleatória
Isso muda se você planeja fazer as atividades de leitura / gravação simultaneamente, e nesse ponto ele se torna significativamente aleatório. O mesmo se aplica se você estiver mantendo um grande número de arquivos abertos e lendo / gravando pequenas partes dentro desses arquivos como se fosse um banco de dados.
Um dos maiores equívocos em que me deparo é a ideia de que um sistema de arquivos desfragmentado tem melhor desempenho que um fragmentado ao lidar com E / S altamente aleatória. Isto é verdade apenas em sistemas de arquivos onde as operações de metadados sofrem muito com um sistema de arquivos fragmentado. Para níveis muito altos de fragmentação, sistemas de arquivos baseados em extensão podem realmente sofrer mais degradação do desempenho do que outros estilos de gerenciamento de blocos.
Dito isso, esse problema só se torna aparente quando os padrões e a taxa de acesso de E / S estão empurrando os discos para seus recursos máximos. Com 14 TB no sistema de arquivos, isso significa entre 7 e 50 eixos na matriz de armazenamento real, o que gera uma vasta gama de recursos; variando de 630 I / O Ops para unidades 7x 2TB 7.2K RPM a 9000 I / O Ops para unidades 50x 300GB 15K RPM. A matriz RAID de 7.2K RPM atingirá a saturação de E / S muito mais rapidamente do que a matriz RAID de 15K RPM.
Se a sua taxa de operações de E / S não está forçando seus limites de armazenamento, a escolha do sistema de arquivos deve se basear mais na flexibilidade geral de gerenciamento do que em ajustar os últimos poucos pontos percentuais de desempenho.
No entanto, se a sua E / S está realmente executando o seu armazenamento, isso é quando o ajuste começa a se tornar necessário.
XFS:
- Montar: defina 'allocsize' como não maior que 65536 (64MB), mas configure-a como alta. Isso melhora a velocidade de metadados para acessos de arquivos.
- Montar: defina 'sunit' para o tamanho da faixa da sua matriz RAID. Também pode ser definido no momento do formato.
- Montar: defina 'swidth' para o número de unidades na sua matriz RAID (ou N-1 para R5, N-2 para R6). Também pode ser definido no momento do formato.
- Formato: se você realmente precisar desse último ponto percentual, coloque o log do sistema de arquivos em um dispositivo de armazenamento completamente separado
-l logdev=/dev/sdc3
EXT4:
- Formato:
-E stridedefinido para o número de blocos (512b ou 4K dependendo da unidade) em uma única faixa de disco no RAID. - Formato:
-E stripe-widthdefinido como 'swidth' no XFS - Formato: Assim como no XFS, o último ponto percentual de desempenho pode ser espremido colocando o diário em um dispositivo de armazenamento completamente separado. %código%