Como posso ajustar o Windows Server 2012 R2 para lidar com a estrutura de arquivos NTFS com 50 milhões de arquivos?

6

Eu tenho um utilitário de desenvolvedor que usarei para gerar 50 milhões de arquivos. A estrutura de diretórios segue quatro níveis de profundidade. O nível superior contém 16 diretórios (anos 2000-2016), próximo nível - meses (1-12), próximo nível - dias (1 - 31) e, finalmente, arquivos - xml (até 85k cada). O diretório final pode ter mais de 3000 arquivos (não fiz as contas para descobrir como 50 Milhões se encaixarão nessa estrutura de diretórios).

Atualmente, estou executando o utilitário e tenho cerca de 1/3 do caminho (dias para executar). Como eu temia, atravessar qualquer parte da árvore de diretórios é uma experiência dolorosa. Leva vários segundos apenas dentro do explorador. Isso com hardware de nível de servidor. SAS 7200RPM (eu sei que isso não é rápido hoje em dia) 12 terabyte Raid 5 ou 10, alocado com 4 3.4ghz xeon cpus.

Como faço para aumentar a capacidade do Windows Server 2012 R2 de armazenar em cache alças de arquivos na memória? Eu não tenho o serviço NFS em execução.

M:\>defrag /a /v /h m:
Microsoft Drive Optimizer
Copyright (c) 2013 Microsoft Corp.

Invoking slab consolidation on DB MDF (M:)...


The operation completed successfully.

Post Defragmentation Report:

    Volume Information:
            Volume size                 = 12.99 TB
            Cluster size                = 64 KB
            Used space                  = 1.55 TB
            Free space                  = 11.44 TB

    Slab Consolidation:
            Space efficiency            = 100%
            Potential purgable slabs    = 1

M:\>
C:\Windows\system32>fsutil fsinfo ntfsinfo m:
NTFS Volume Serial Number :       0x9c60357c60355de8
NTFS Version   :                  3.1
LFS Version    :                  2.0
Number Sectors :                  0x000000067ffbefff
Total Clusters :                  0x000000000cfff7df
Free Clusters  :                  0x000000000b6bcb45
Total Reserved :                  0x0000000000000004
Bytes Per Sector  :               512
Bytes Per Physical Sector :       4096
Bytes Per Cluster :               65536
Bytes Per FileRecord Segment    : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length :           0x0000000320900000
Mft Start Lcn  :                  0x000000000000c000
Mft2 Start Lcn :                  0x0000000000000001
Mft Zone Start :                  0x00000000018f8780
Mft Zone End   :                  0x00000000018f9420
Resource Manager Identifier :     A47067E0-6356-11E6-8

C:\Windows\system32>

Rammap

metafile details: Total=2,882,220 K, Active=2,736,688 K, Standby=143,968 K, Modified=852 K, Modified no write=712 K.

O que mais seria interessante nesta página?

Neste momento, o servidor recebe 16G de memória. Eu poderia pedir muito mais.

C:\Windows\system32>fsutil.exe 8dot3name query m:
The volume state is: 1 (8dot3 name creation is disabled).
The registry state is: 2 (Per volume setting - the default).

Based on the above two settings, 8dot3 name creation is disabled on m:

C:\Windows\system32>
Contig v1.8 - Contig
Copyright (C) 2001-2016 Mark Russinovich
Sysinternals

m:\$Mft is in 80 fragments
m:\$Mft::$BITMAP is in 32 fragments

Summary:
     Number of files processed:      2
     Number unsuccessfully procesed: 0
     Average fragmentation       : 56 frags/file
NtfsInfo v1.2 - NTFS Information Dump
Copyright (C) 2005-2016 Mark Russinovich
Sysinternals - www.sysinternals.com


Volume Size
-----------
Volume size            : 13631357 MB
Total sectors          : 27917021183
Total clusters         : 218101727
Free clusters          : 184577826
Free space             : 11536114 MB (84% of drive)

Allocation Size
----------------
Bytes per sector       : 512
Bytes per cluster      : 65536
Bytes per MFT record   : 0
Clusters per MFT record: 0

MFT Information
---------------
MFT size               : 16210 MB (0% of drive)
MFT start cluster      : 49152
MFT zone clusters      : 33255616 - 33258848
MFT zone size          : 202 MB (0% of drive)
MFT mirror start       : 1

Meta-Data files
---------------
    
por D-Klotz 18.08.2016 / 20:43

1 resposta

6

Atualmente, você tem uma MFT de 0x320900000 = 13,431,209,984 bytes = 12 GiB em tamanho, com apenas 2GiB disso na memória. Mais RAM permitirá que você tenha mais disso na memória, se você quiser armazenar em cache mais dos metadados do sistema de arquivos "handles de arquivo".

Não importa qual sistema de arquivos você usa, haverá metadados e, dependendo dos padrões de uso do sistema de arquivos, é melhor investir em mais RAM E / OU armazenamento mais rápido . Se a quantidade de informações de metarquivo é irrealista para armazenar tudo na RAM e os padrões de uso de arquivo normalmente lidam com novos arquivos em vez de usar repetidamente um subconjunto menor de arquivos, é possível armazenar mais rápido como RAID 10 com muitos pares de espelhamento de discos SAS SSD e / ou 15K RPM mais rápidos, pode ser necessário para limitar o tempo de busca e aumentar a quantidade de IOPs disponíveis que o armazenamento pode suportar.

Lembre-se de que as configurações padrão do gerenciador de memória do Windows podem não se aplicar à sua situação e talvez seja necessário ajustar algumas configurações, especialmente se não estiver planejando ter memória RAM suficiente para caber toda a MFT na RAM. resto do sistema requer. Percebo que quase todos os seus dados de meta-arquivo estão marcados como Memória ativa, o que significa que o sistema de cache do Windows não tem permissão para descartá-los da RAM quando não estão sendo usados. Meu script do powershell em Uso de RAM em metarquivo do Windows Server 2008 R2 pode ser usado (mesmo no Server 2008 para 2012R2, e espero 2016) para definir os valores mínimos e máximos na quantidade de memória de metarquivo marcada como ativa e forçar o restante a ficar em espera. Isso permite que o sistema de cache priorize o que está na RAM melhor.

Edit: Embora eu não esteja familiarizado com o jmeter, parece que o padrão de uso do sistema de arquivos será

  1. escreva todos de maneira seqüencial.
  2. leia todas elas o mais rápido possível de uma maneira mais sequencial
  3. leia-os todos uma segunda vez em um padrão parcialmente aleatório (conforme cada thread compete para ler o grupo de arquivos que deseja) para enviá-los pela rede

Com esse padrão de uso, para ver um benefício razoável de adicionar muito mais RAM, você precisaria adicionar o suficiente para caber toda a MFT na RAM. Isso geralmente é um desperdício de dinheiro. Quando seria mais rentável adicionar um pouco mais de RAM e atualizar o armazenamento para melhorar significativamente os IOPs. Isso deve ser mais rápido do que manter um array raid5 de disco lento de 7,2K rpm, ou até mesmo um RAID10 feito com apenas 4 discos com quantidades colossais de RAM, pois os metadados não são os únicos dados sendo lidos / gravados de / para armazenamento. Consulte esta calculadora como uma ferramenta de estimativa sobre o desempenho esperado das IOPs e o número de discos diferentes e os níveis de invasão afetam o desempenho.

No caso acima, a única maneira de adicionar ainda mais memória ram pode ser mais rápida do que usar um sistema com armazenamento mais rápido, é se você adicionar memória RAM suficiente para que todos os dados, incluindo o conteúdo do arquivo, também sejam colocados na memória RAM. É por isso que alguns sistemas de bancos de dados anunciam que operam "100% na memória", de modo que não haja atrasos no sistema de armazenamento.

    
por 19.08.2016 / 01:46