Configurando o sistema de arquivos NTFS para desempenho

Question

Temos um aplicativo que planeja armazenar em torno de 1,1 TB de arquivos XML com tamanho médio de 8,5 KB.

Estes representam 18 meses de dados, com cerca de 200.000 novos arquivos sendo criados todos os dias.

Cada arquivo será escrito apenas uma vez e terá 3% de chance de ser lido por um pequeno número (< 10) de vezes nos 18 meses seguintes.

Quais opções de NTFS estão abertas para nós que ajudarão no desempenho?

Os atuais na nossa lista são:

• Desabilitando a criação do nome 8.3
• Limitando o número de arquivos em um diretório (número ainda em debate ...)

Editar

Com relação à fragmentação: estamos planejando usar tamanhos de cluster de 2k para eficiência no uso de espaço em disco. Cada arquivo será gravado apenas uma vez (ou seja, sem edições de arquivo). Os arquivos serão excluídos após 18 meses, todos os dias.

Portanto, não acreditamos que a fragmentação seja um problema significativo.

    

Answer 1

Eu também adicionaria:

Desativar a desfragmentação de disco. Altere o tamanho do bloco para 16kb para que cada arquivo seja gravado em um único bloco.

Racional para isso:

Você está querendo gravar 1,7 GB de dados por dia, em 200.000 arquivos. Supondo que esses arquivos sejam escritos em um dia de 24 horas, isso significa cerca de três arquivos por segundo. Isso não parece ser um problema significativo para um único disco SATA, então meu palpite é que você tem outros problemas assim como o desempenho do disco.

(ou seja, você tem memória suficiente? ou você está paginando a memória para o disco também?)

No entanto

1. Os sistemas de arquivos do Windows NTFS, por padrão, tentam desfragmentar os sistemas de arquivos em segundo plano. Desfragmentação de disco irá matar desempenho enquanto você está desfragmentando o disco. Como o desempenho parece já ser um problema, isso só estará piorando as coisas para você.

2. Existe um equilíbrio entre o uso de tamanhos pequenos de cluster e o desempenho de E / S na gravação de arquivos grandes. Os arquivos e a tabela de alocação de arquivos não estarão no mesmo setor no disco, portanto, ter blocos alocados enquanto você grava arquivos fará com que a cabeça do disco tenha que se movimentar constantemente. Usando um tamanho de cluster que é capaz de armazenar 95% dos seus arquivos em um cluster cada, irá melhorar o seu desempenho de gravação de E / S.

3. Como outras pessoas apontaram, usar um pequeno tamanho de cluster de 2k causará fragmentação ao longo do tempo. Pense nisso assim, durante os primeiros 18 meses você estará escrevendo arquivos em disco vazio limpo, mas o sistema operacional não sabe que, uma vez fechado, nenhum dado será adicionado a cada arquivo, então ele tem deixado alguns blocos disponíveis no disco. Encerre cada arquivo caso esse arquivo seja estendido posteriormente. Muito antes de preencher o disco, você descobrirá que o único espaço livre está nos espaços entre outros arquivos. Não só isso, quando está selecionando uma lacuna para o seu arquivo, o sistema operacional não sabe se você está escrevendo um arquivo de 5 blocos ou um arquivo de 2 blocos, por isso não pode fazer uma boa escolha sobre onde salvar seu arquivo. p>

No final do dia, a engenharia trata de lidar com necessidades conflitantes e da escolha da solução de menor custo para essas necessidades de balanceamento. Meu palpite é que comprar um disco rígido maior é provavelmente mais barato do que comprar discos rígidos mais rápidos.

    

Answer 2

Desativar o carimbo de data e hora do último acesso e reservar espaço para a MFT.

• Hacks de desempenho do NTFS
• Desativar o carimbo de hora do último acesso do NTFS

Answer 3

Para elaborar meu comentário sobre a resposta de Ptolomeu ...

Ao configurar o tamanho do bloco para que uma grande maioria de todos os arquivos esteja contida em um bloco, você obtém eficiências de E / S. Com um tamanho de bloco de 2K e um tamanho de arquivo médio de 8,5K, 50% das suas operações de I / O serão para 5 blocos ou mais. Ao definir um tamanho de bloco de 16K, parece que a grande maioria das gravações seria de um único bloco; o que tornaria esses 3% de leituras muito mais eficientes quando acontecem.

Uma coisa a considerar é o backup de E / S. Se você estiver fazendo o backup dos dados, todos os arquivos serão lidos pelo menos uma vez e suas entradas de diretório serão controladas em cada passagem de backup. Se você pretende fazer isso, considere a E / S de backup em seus projetos.

Advertências: se o seu sistema de armazenamento subjacente é aquele que já faz alguma virtualização de armazenamento (como um disco matriz HP EVA ou outros arrays dessa classe), isso não importa muito. A fragmentação desse tipo não será notada, pois os dados já existem fisicamente em uma natureza altamente fragmentada nos drives reais. Nesse caso, o tamanho do bloco de 2k é bom e não afeta muito o desempenho. Ainda haverá ganhos de desempenho selecionando um tamanho de bloco grande o suficiente para manter a maioria dos tamanhos de arquivo esperados, mas a magnitude não será tão significativa.

    

Answer 4

Tarde para essa festa, mas pode beneficiar outras pessoas, então ...

O tamanho do cluster, primeiro e mais importante, você precisaria examinar a distribuição dos tamanhos dos arquivos, para otimizar os resíduos de espaço em disco e de baixa fragmentação para redimensionar os clusters próximos a esse tamanho , não geral avg - por exemplo: se a maioria dos arquivos cair próximo a 2k, um tamanho de cluster de 2k seria ideal, se próximo a 4k, então um cluster de 4k seria ideal, e assim por diante; Se os tamanhos dos arquivos otoh forem distribuídos de maneira uniforme / aleatória, o melhor que você pode fazer é aproximar o tamanho médio do arquivo para o tamanho do cluster ou armazenar arquivos em partições com diferentes tamanhos de clusters para diferentes tamanhos de arquivo, mas você d precisa de suporte a software / fs para isso.

    

Answer 5

Você também pode querer olhar para o RAID para o seu design. Existem várias formas de RAID, mas você faria bem em olhar para o RAID 5, o que permitiria que você gravasse arquivos em unidades diferentes ao mesmo tempo, mas os dados ainda estariam em um volume ... Isso dá a você vários benefícios:

1) Você está criando um backup como você vai. Isso permite que você tenha uma falha de unidade e você pode recuperar. O RAID 1 criaria uma cópia espelhada, mas 5 envolveria striping - o RAID 1 só lhe daria o benefício desse backup ... embora 5 estivesse mais envolvido e você precisaria de mais unidades para configurá-lo (mínimo de 3, versus os 2 necessários para o RAID 1), você tem outros benefícios.

2) O striping também aumenta o desempenho, porque você pode escrever vários arquivos de uma só vez (estimado 3 por segundo, acima ...), o striping permitiria que os arquivos fossem "distribuídos" ao longo dos discos, e apenas tomando parte do fardo. Quanto mais discos envolvidos, mais leve será o fardo por disco, mas haverá um ponto em que você atingirá um limite de desempenho versus custo ...

3) Se você fizer backup dos dados, o backup poderá ocorrer sem prejudicar o desempenho de gravação - dependendo do tamanho do cache dos discos, é claro, e da forma de backup ... mas, na maioria das vezes, , você não precisaria desligar para invocar os backups.

Além disso, a maneira como você tem o sistema configurado, parece até que os backups seriam mais fáceis para você - você só precisa fazer backup dos dados de 24 horas de cada vez, já que o arquivo não está sendo modificado posteriormente. Você poderia até escrever um trabalho em lotes que comprime os dados se você estivesse preocupado com o espaço ocupado pelos arquivos ... XML é principalmente texto, então as taxas de compressão seriam altas, e a descompressão raramente seria necessária, em apenas 3% dos arquivos ... para que você possa incluir a compactação na unidade sem temer o tempo de descompressão. Isso também reduziria os tamanhos de bloco necessários e poderia aumentar ainda mais a eficiência do sistema, com a CPU envolvida na compactação dos dados e não apenas sendo o intermediário de dados. (IE. Se tudo o que você fizesse fosse armazenar dados, seria um desperdício do bom processador da CPU naquele sistema ... mas se estivesse usando ciclos de clock "desperdiçados", compactando os dados e distribuindo com mais eficiência para as unidades, melhor ainda!)

Com a compactação, seus blocos de 2K provavelmente armazenariam seus arquivos de 8.5K sem problemas. Adicione striping e backup de RAID, junto com uma CPU pesada, memória suficiente para não armazenar em cache nenhum programa em execução (se algum cache for usado), e você estará a caminho de um bom sistema para o que você está procurando fazer.

    

Answer 6

Este é um utilitário simples para aumentar o desempenho do NTFS desativando alguns recursos do NTFS que não são usados até agora (ou não tão importantes).

link

rem execute as an Administrator

rem based on http://www.windowsdevcenter.com/pub/a/windows/2005/02/08/NTFS_Hacks.html
ram based on https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc938961(v=technet.10)

rem http://archive.oreilly.com/cs/user/view/cs_msg/95219 (some installers need 8dot3 filenames)
rem disable 8dot3 filenames
ram Warning: Some applications such as incremental backup utilities rely on this update information and do not function correctly without it.
fsutil behavior set disable8dot3 1

rem increase ntfs mtz size
fsutil behavior set mftzone 2

rem disable last access time on all files
fsutil behavior set disablelastaccess 1

echo now you can reboot