O servidor trava na cópia do arquivo

Question

Estamos com um problema em um de nossos servidores. Quando copiamos arquivos maiores (grande significa 50MB e maior nesse caso), a operação de cópia (C: \ para C :) inicia normalmente, mas depois começa a ficar lenta, indo para 100kb / se fazendo todo o servidor travar (nosso aplicativo não pode mais retornar resultados do SQL Server, portanto, o aplicativo trava para os usuários).

O Intel RST mostra todo o verde no SMART. Aqui estão as especificações do sistema:

• Servidor: HPE ML10
• Armazenamento: 3x HP 3TB na configuração RAID5
• SO: Windows Server 2012 R2
• Funções do servidor: Controlador de domínio, servidor de aplicativos (SQL Server e aplicativo .NET)
• Configurações de armazenamento: tamanho da distribuição: 128 KB, limpeza do buffer de cache de gravação: ativado, modo de cache: desativado, tamanho dos setores físico e lógico: 512 bytes

Não sou especialista em servidores, por isso não tenho certeza se tenho essas coisas configuradas corretamente. Qual poderia ser o problema aqui?

EDIT: Eu não sou um especialista nessas coisas (desenvolvedor). Então, talvez eu esteja fazendo algo simples errado.

EDIT2: link O desempenho de gravação em disco é extremamente ruim. Mas nenhum total trava como quando copio com o Windows Explorer. Eu acho que o explorador suspenso bloqueia a bomba de mensagens, entupindo o sistema. Uma migração para um RAID1 / 10 poderia resolver o problema em suas opiniões?

    

Answer 1

Se eu interpretar "Cache-Mode: Off" corretamente, é completamente compreensível que o desempenho de gravação seja uma droga. Verifique se copiar / ler do RAID (para rede ou NUL) é problema ou copiar / gravar para o RAID - Eu acho que estou correto, só escrevendo para o RAID é uma dor.

O RAID5 é distribuído - cada faixa consiste em (no seu caso) três segmentos: dados1, dados2 e paridade12. Agora, quando alguns dados são gravados na matriz, eles não podem ser gravados em um segmento de dados, porque a paridade não corresponderia mais.

Se data1 for gravado / alterado, o controlador precisará:

1. leia dados2, recalcule a paridade12, escreva dados1, escreva paridade12 (para matrizes pequenas)
2. leia dados antigos1, leia paridade12, remova a paridade antiga de dados1 da paridade12, recalcule a paridade12 com novos dados1, escreva dados1, escreva paridade12 (para matrizes maiores)

Portanto, sempre que houver uma alteração, as operações do controlador serão amplificadas por três! Se não puderem ser armazenadas em cache, cada gravação resultará em três operações a serem executadas e seu aplicativo precisará aguardar. Com o cache, muitas operações de leitura e gravação podem ser omitidas e o impacto no desempenho será muito menor.

A única exceção a essa amplificação de operação de gravação é quando você escreve uma faixa inteira de uma só vez: apenas pegue data1 e data2 do buffer, calcule parity12 e grave todos os três segmentos. Isso é uma amplificação por apenas 1,5. No entanto, para poder combinar todos os dados recebidos em faixas completas, você precisa poder enfileirar os dados. Adivinhe, você precisa de cache novamente.

Em suma: se você usa RAID5 ou RAID6, você absolutamente requer cache - não é um luxo. Muito pouco ou mesmo nenhum cache vai matar seu desempenho. Se for um software ou RAID hospedado com cache configurável, reserve pelo menos 512 MB, melhor 1 ou 2 GB e ele "voará". O RAID5 com três unidades não será uma maravilha de desempenho, mas pode funcionar bem.

Editar: o HP ML10 G9 possui um controlador RAID SATA Intel RST integrado ao chipset - host RAID. Dependendo do modelo exato e do controlador usado, o cache deve ser configurável em algum lugar.