A fragmentação da MFT pode ser um problema no meu servidor de arquivos ocupado?

Question

Windows Server 2003 SP2 LUN montado a partir de SAN Milhões de arquivos pequenos em centenas de milhares de diretórios (100 GB no total) NTFS com tamanho de cluster de 4k

Ao fazer o rastreamento inicial de arquivos para backups ou arquivar o acesso regular do usuário aos arquivos nesta unidade, ele fica muito lento.

Os caras de rede e SAN não mostram nenhuma atividade anormal nas investigações iniciais, mas investigações mais profundas continuam. Algum tipo de problema no nível do servidor com o NTFS ou o Windows é suspeito.

Dado que quase todos os arquivos são < 10k de forma que cabem dentro de 1-3 clusters, não suspeito que a fragmentação regular seja um problema, mas talvez a fragmentação da MFT possa ser. Como os backups e as limpezas causam interrupção do usuário mesmo fora das horas, hesito em usar a desfragmentação do Windows para analisar minha fragmentação e realmente me preocupo com a fragmentação da MFT. Qualquer foi para descobrir isso mais rapidamente do que uma análise completa do disco?

Programas de desfragmentação de terceiros também não estão fora de questão se alguém tiver recomendações. Não perturbar mais os usuários com nossa análise é uma grande prioridade.

Também estamos pensando em inserir a chave reg para NtfsDisableLastAccessUpdate. Alguém achou isso para realmente ser uma grande melhoria e não apenas um pequeno ajuste?

Existem boas ferramentas para medir a contenção de bloqueio / acesso de arquivos para uma unidade ocupada? Ferramentas GUI de sysinternals como procmon não escalam a esse nível mais.

    

Answer 1

Descobri que a lentidão estava ocorrendo com dezenas de milhares de arquivos com as mesmas 5 letras de um prefixo. Minha teoria é que as árvores NTFS MFT B + são criadas muito profundas e desequilibradas neste caso. Restaurar os arquivos para um disco novo não repetiu o problema, então eu suspeito que isso é de alguma forma equilibrado corretamente em uma nova criação com os arquivos todos em uma linha do que quando os arquivos são criados aleatoriamente (às vezes um desses arquivos de prefixo e às vezes não) um disco já fragmentado.

Estamos planejando randomizar os nomes e também investigar a desativação dos nomes 8dot3 para o futuro.

    

Answer 2

Quando você estiver fazendo backup de um volume como esse, você estará exercitando seriamente o armazenamento subjacente. Quando você começa a ler nesses milhões de arquivos pequenos espalhados pelo sistema de arquivos, o fator limitante é o IOPS de leitura aleatória que os discos subjacentes em sua SAN podem fornecer. A própria SAN pode não estar estressada, mas o volume do qual você está lendo será atingido e qualquer outro processo que tente fazer qualquer outra coisa ao mesmo tempo sofrerá, a menos que você diminua a atividade de backup.

A coisa é a profundidade da fila nesse volume. Se estiver com um pico significativamente maior que o número de discos que fazem backup do volume, você estará atingindo os limites de IOPS. O Perfmon lhe dará uma idéia, mas os melhores dados virão da própria análise do Storage Array se for possível obtê-los. Eu duvido seriamente que o seu problema tenha algo a ver com o bloqueio de arquivos. O Pessoal de Armazenamento precisa olhar para o IOPS nos discos no pacote RAID do qual seu volume está separado, eu suspeito que esses discos estão atingindo mais de ~ 150 IOPs cada (maior se eles forem 15k, mais baixos se forem 7.2k) . Se você tiver um grupo RAID 10 de 6 discos que hospede esse volume, ele atingirá o máximo de uma taxa não muito melhor do que 10Meg / seg se estiver realmente fazendo backup de milhões de arquivos 10k e muito pouco que seja muito maior.

O NtfsDisableLastAccessUpdate ajudará no seu caso - ele descarta um conjunto de IOPS de cada atividade de arquivo e, em particular, evita algumas leituras e gravações extras associadas a cada arquivo. Dado que você tem milhões e que seus arquivos ou tão pequenos devem ter uma vitória significativa, pode ser até 50% de ganho. Dito isso, o efeito mais provável que você verá é que o backup será acelerado, mas ainda terá um limite de IOPs.

Você também deve considerar alinhando a partição do disco se isso já não tiver sido feito. Em um caso como este (muitas pequenas leituras) não é tão grande quanto pode ser para outros padrões de E / S, provavelmente cerca de 10% supondo que seu tamanho de faixa de RAID seja 128k e sua média seja de cerca de 10k, mas pode valer a pena o esforço. Isso exigirá o backup de todo o volume, reparticionando e reformatando-o e, em seguida, restaurando os dados para que não seja um exercício trivial.

    

Answer 3

A execução do desfragmentador de disco no modo de análise é a única maneira que conheço para ver quantos fragmentos da MFT você tem.

Se o volume estiver em uso 24 x 7, provavelmente você está "atrapalhando" os usuários. Se não, programe o comando "defrag -a -v C:" para executar fora do horário de atendimento com sua saída redirecionada para um arquivo. Isso fará com que você receba a saída do comando sem que você esteja acordado para executá-la às 4 da manhã de domingo. > sorriso <

Não posso fornecer estatísticas "NtfsDisableLastAccessUpdate", mas certamente as defini, a menos que você precise salvar o último horário de acesso. (Eu usaria o comando "fsutil behavior set disablelastaccess 1", em vez de defini-lo no registro. Você também precisa reinicializar para que a alteração entre em vigor.)

Você também pode considerar a possibilidade de desabilitar a criação do nome de arquivo 8dot3, caso não seja necessário. Faça isso, especialmente, se você tiver um grande número de arquivos em um único diretório. (Apesar de desligar isso não vai se livrar dos nomes 8dot3 que já estão lá ...)

Comparar a saída de "fsutil fsinfo statistics" no volume em questão antes / depois desse lento "rastreamento inicial" pode dizer algo sobre o que está acontecendo, embora eu ache que isso mostre apenas uma quantidade medonha de metadados leituras estão ocorrendo.

Você tem espaço suficiente na SAN para fazer uma restauração de todo o conteúdo do volume para um novo LUN configurado de forma semelhante (com relação às suas propriedades de SAN - nível de RAID, etc.) como o LUN de produção? Seria interessante ver como um sistema de arquivos NTFS recém-criado com a criação de nomes 8dot3 desativada desde o início, e talvez uma zona MFT de tamanhos diferentes, se comporta em comparação com a LUN de produção. (Também não seria muito difícil orquestrar uma migração por meio da cópia de arquivos alterados do LUN de produção para esse LUN de armazenamento temporário, se o LUN de teste provar funcionar melhor).