Gravando arquivos de log no SSD

Question

Temos um aplicativo que faz um monte de log. O meio para o qual nós logamos é o SSD SSD, no entanto, estamos começando a ver algumas falhas no campo. Poderíamos desligar (logar), ter níveis de log (temos), mas às vezes um engenheiro ativa o log para diagnosticar uma falha e esquece de desligá-lo, o que resulta em um SSD com falha algum tempo depois.

Examinando o código de log, salvamos a entrada de log em uma fila e a cada 5 segundos, iteramos a coleção e usamos File.AppendAllText para gravar a linha no arquivo.

De acordo com o MSDN, isso grava no arquivo e fecha-o.

Qual seria o melhor regime a ser usado para obter a mesma funcionalidade, mas prevenir (ou reduzir) os danos ao SSD?

Seria melhor abrir um FileStream no início do software, gravar no fluxo durante o uso e fechar antes de o software ser encerrado? Como isso aliviaria a situação no nível do disco? Quais processos estão envolvidos e como isso é melhor do que abrir o arquivo e fechá-lo imediatamente. Usar o FileStream 'parece' melhor, mas eu preciso de uma lógica mais concreta antes de fazer alterações.

Talvez exista uma maneira melhor que não tenhamos considerado.

    

Answer 1

OK, tenho certeza de que tenho sua resposta.

Pelo que eu entendi, File.AppendAllText está sendo usado para gravar cada linha no arquivo de log. Isso significa que o arquivo de log está sendo aberto, gravado e fechado sempre que AppendAllText é chamado.

Sem olhar exatamente como o AppendAllText é implementado, podemos também supor que na melhor das hipóteses apenas os dados adicionais estão sendo gravados no disco mais meta-dados correspondentes (material do sistema de arquivos).

Milhares de iterações dos itens acima, durante um período de tempo, destruirão um SSD (tipos MLC mais rapidamente que SLC). Isso porque os SSDs só podem gravar em seu armazenamento interno em grandes blocos.

Exemplo

Use um SSD de 128 GB com um tamanho de bloco interno de 512 KB. São 262.144 blocos no total.

Simplificando, sem contar os meta-dados (sistema de arquivos), se você abrir 262.144 arquivos minúsculos você terá que fazer com que todos os blocos do SSD tenham sido escritos para. Faça isso mais de 1000 a 4 mil vezes (dependendo do SSD) e você praticamente o matou.

Agora eu tenho certeza que os SSDs têm coisas inteligentes acontecendo para minimizar o tipo de desgaste acima, então tome o exemplo com um grão de sal. Mas o principal aqui é verdade e é importante: os SSDs não gostam de milhões de pequenas gravações.

Adicionar uma linha a um arquivo de log constitui uma pequena gravação de dados (ou talvez uma gravação grande, dependendo de como o MS implementou as coisas) e uma ou mais gravações pequenas para atualizar os metadados.

Soluções possíveis

• Escreva no log com menos frequência, digamos a cada 60 segundos, e / ou ...

• Abra o arquivo de log como Stream , anexe o que quiser em seu loop e, em seguida, libere / feche o Stream. Essa abordagem significa que o arquivo só é aberto uma vez , gravado e fechado. O .NET e o sistema operacional otimizarão a gravação.

• Use um disco rígido não SSD para registrar. Se a alteração do código de registro não for possível, mas você puder especificar um caminho de registro, essa poderá ser a melhor opção. Mesmo um disco rígido USB faria muito bem! Contanto que não seja SSD.