Escrevemos um aplicativo que executa gravações pequenas (22kB) em vários arquivos de uma só vez (um thread executando gravações assíncronas na fila em vários locais em nome de outros threads) no mesmo volume local (RAID1).
99,9% das gravações são de baixa latência, mas ocasionalmente (talvez a cada minuto ou dois) obtemos uma ou duas gravações de grande latência (vi 10 segundos ou mais) sem qualquer explicação real.
Plataforma: Servidor Win2003 com NTFS.
Monitoramento: Sysinternals Process Monitor (veja link abaixo) e nosso próprio registro de aplicativo.
Tentamos várias coisas para tentar resolver isso, coletadas em alguns sites, por exemplo:
Tornando a primeira parte dos nomes dos arquivos exclusiva para ajudar na geração de nomes 8.3
Gravando arquivos em vários diretórios
Alterando o cache de gravação de disco Intel
Compartilhamento de arquivos/impressoras do Windows
Minimize a memória usada
Equilíbrio
Maximize o rendimento de dados para compartilhamento de arquivos
Maximize o rendimento de dados para aplicativos de rede
Sistema->Avançado->Desempenho->Avançado
NtfsDisableLastAccessUpdate - use o conjunto de comportamento fsutil disablelastaccess 1
desabilitar a geração de nome 8.3 - use "fsutil behavior set disable8dot3 1" + reiniciar
Habilitar um cache de sistema de arquivos de tamanho grande
Desative a paginação do código do kernel
Limite de bloqueio de página IO
Desligue (ou ligue) o serviço de indexação
Mas nada parece fazer muita diferença. Há uma série de coisas que ainda não tentamos, mas nos perguntamos se alguém já se deparou com o mesmo problema, um motivo e uma solução (programática ou não).
Podemos reproduzir o problema usando IOMeter e uma configuração simples:
Inicie o IOMeter e remova todos, exceto o primeiro thread de trabalho em 'Topologia' usando o botão de desconexão.
Selecione o thread de trabalho e coloque uma cruz na caixa ao lado do disco que deseja usar na guia Disk Targets e coloque '2000000' em Tamanho máximo do disco (NOTA: deve ter pelo menos 1 GB de espaço livre; o tamanho do setor é 512 bytes)
Em seguida, crie uma nova especificação de acesso e adicione-a ao thread de trabalho:
Tamanho da solicitação de transferência = 22kB
100% Sequencial
Porcentagem de especificação de acesso = 100%
Porcentagem de leitura/gravação = 100% gravação
Altere a frequência de atualização da exibição de resultados para 5 segundos, o tempo de execução da configuração de teste para 20 segundos e ambas as configurações de 'Número de trabalhadores a serem gerados automaticamente' para zero.
Selecione o Worker Thread no painel Topology e pressione o botão Duplicate Worker 59 vezes para criar 60 threads com configurações idênticas.
Clique no botão 'Ir' (bandeira verde) e monitore a guia Resultados. O 'Tempo máximo de resposta de E/S (ms)' sempre atinge pelo menos 3.500 em nossa máquina. Nossa máquina não é exatamente lenta (servidor Xeon 8 core rack com 4GB e RAID integrado).
Eu estaria interessado em ver o que outras pessoas conseguem. Temos a sensação de que pode ter algo a ver com o sistema de arquivos NTFS (o nosso atualmente está 75% cheio de arquivos fragmentados) e vamos tentar algumas coisas em torno desse princípio. Mas também está relacionado ao desempenho do disco, já que não o vemos em um RAMDisk e não é tão grave em um array RAID10.
Qualquer ajuda é muito apreciada.
Ricardo
Clique com o botão direito e selecione 'Abrir link em uma nova guia':
Resultado do ProcMon
Responder1
Agora tenho mais informações sobre esse assunto.
Tendo testado o teste IOMeter descrito em 12 máquinas diferentes usando uma variedade de hardware, reduzi-o a um chipset RAID específico (3 máquinas diferentes com o mesmo chipset exibem esse comportamento usando RAID1 e RAID10). Todas as outras máquinas têm um resultado pelo menos uma ordem de grandeza melhor.
Chipset: Intel 631xESB/632xESB SATA RAID (também conhecido como ESB2)
Veja esta postagem no site da Intel para obter mais informações e esperamos uma resposta da Intel:
Intel 631xESB/632xESB SATA RAID (também conhecido como ESB2) grava lentamente
Ricardo