Você deve desativar o arquivo de paginação com SSD?

Eu tenho lido esta pergunta e tem muita informação ótima.

Mas, supondo que você tenha RAM mais que suficiente, acho que o arquivo de paginação deve ser desativado no SSD para prolongar a vida útil. Eu sei que você perderia o despejo principal em caso de falha, mas poucas pessoas precisam dessa informação.

Pelo que entendi, sem um arquivo de paginação, à medida que você atinge o limite de sua RAM, isso pode causar um surto no disco. Mas para SSDs não há conceito de debulhar, as leituras são rápidas.

O que é que vocês acham?

Mas, supondo que você tenha RAM mais que suficiente, acho que o arquivo de paginação deve ser desativado no SSD para prolongar a vida útil. Eu sei que você perderia o despejo principal em caso de falha, mas poucas pessoas precisam dessa informação

Isso soa como otimização prematura. Você não discutiu quais SSDs planeja usar e, sem realmente analisar a carga de trabalho do servidor e a planilha de dados de SSD planejada, não pode ter idéia do efeito que um arquivo de página terá na vida útil do seu SSD.

Também há um grande volume de informações erradas, tanto na Internet maior quanto aqui na Server Fault, sobre SSDs que sofrem com uma expectativa de vida ruim. Os primeiros SSDs do modelo podem ter tido problemas, e as unidades flash USB definitivamente começam a se degradar, mas as SSDs de classe empresarial têm algoritmos de nivelamento de desgaste muito melhores e alguns usam flash sobressalente para melhorar o desempenho e o desgaste.

As unidades Intel X25-E , por exemplo, reivindicam uma duração de gravação de 1 petabyte de gravações aleatórias para a unidade de 32 GB. Se você estiver saturando a interface de gravação (200 MB / s) sem parar, com substituição, minha estimativa é de que durará cerca de 58 dias. Mas isso está gravando algo como 17 TB de dados por dia nessa unidade.

A carga de trabalho típica do servidor na unidade do sistema operacional será muito, muito menor, mesmo se você tiver um arquivo de paginação. Chame de 50 GB por dia. Se o valor de 1 PB é preciso (e eu sei que pode ser considerado um valor médio, mais discussões depois), isso ainda está em algum lugar ao norte de 50 anos.

Esses números parecem absurdamente altos, é claro, então vamos ver os números reais citados pela Intel para a longevidade esperada das unidades . A Intel ficou feliz em qualificar as unidades MLC (não empresariais) para gravar 100 GB de dados, todos os dias, durante cinco anos. O entendimento padrão do flash SLC vs. MLC diz que o flash SLC dura cerca de 10 vezes mais que o MLC (o link acima também mostra isso em um gráfico).

A verdade será confirmada pelo tempo, é claro - ou começaremos a ver as unidades falharem cedo ou não. Mas os números por trás das unidades somam longevidade unidade não ser um problema com SSDs qualidade decente em tudo .

Se você estiver usando um SSD MLC, talvez tenha razão em se preocupar. Mas lembre-se de que, se a Intel estiver feliz em avaliar a unidade em 100 GB / dia por cinco anos, isso ainda é fundamentalmente o mesmo que 50 GB / dia por 10 anos. E, voltando ao meu argumento original, você ainda precisa saber que tipo de carga de trabalho real você fará na unidade.

Pessoalmente, eu diria que não deve usar um SSD MLC em um ambiente de servidor de produção. Se um SSD decente do SLC for muito caro, atenha-se aos discos giratórios por enquanto.

(Além disso, se você fizer os números, digamos 100 GB por dia durante 50 anos, que é a classificação "SLC dura 10x mais que o MLC", parece que a Intel está dizendo que a unidade de 32 GB realmente tem uma vida útil total de gravação de mais perto de 2 PB de dados, não o de 1 PB citado na especificação do produto. Mesmo que eu confie apenas no menor desses dois valores para ficar feliz que minhas unidades X25-E durem bem ao norte de 10 anos.)

Além da longevidade provavelmente não ser um problema, como Daniel Lawson menciona, e do feedback da própria equipe do MS (abaixo), considere

1. O arquivo de paginação será usado apenas quando necessário de qualquer maneira
2. Se o arquivo de paginação estiver sendo usado, tê-lo no SSD versus um disco rígido giratório fará uma enorme diferença

O arquivo de paginação deve ser colocado nos SSDs?

Sim. A maioria das operações de arquivo de paginação são pequenas leituras aleatórias ou gravações seqüenciais maiores, sendo tipos de operações que os SSDs lidam bem.

Observando os dados de telemetria de milhares de rastreamentos e concentrando-nos nas leituras e gravações do arquivo de paginação, descobrimos que

• Pagefile.sys lê em menor número pagefile.sys escreve por aproximadamente 40 a 1
• Os tamanhos de leitura Pagefile.sys são geralmente muito pequenos, com 67% menor ou igual a 4 KB e 88% menor que 16 KB.
• As gravações Pagefile.sys são relativamente grandes, com 62% maior ou igual a 128 KB e 45% com exatamente 1 MB de tamanho. De fato, dados os padrões de referência típicos do arquivo de paginação e as características de desempenho favoráveis ​​dos SSDs nesses padrões, existem poucos arquivos melhores que o arquivo de paginação para colocar em um SSD.

Suporte e perguntas e respostas para unidades de estado sólido (MSDN)

Em vez de desativar completamente o arquivo de paginação, pode ser útil dizer ao sistema operacional para não usá-lo (por exemplo sysctl vm.swappiness=0).

O sistema operacional evitará usá-lo, a menos que seja necessário, salvando gravações desnecessárias no SSD.

Eu deixaria o arquivo de paginação sempre ativado; certas partes do seu sistema operacional ou aplicativos podem ser escritas para esperar que um esteja lá e, como tal, podem se comportar mal se não houver um.

Dito isto, executei o Windows (XP) sem um arquivo de paginação no passado e ele ficou perfeitamente feliz com tudo o que joguei nele. Sempre havia a dúvida incômoda de que algo surgiria e que não iria gostar.

Uma opção pode ser configurá-lo muito pequeno.

Isso não responde diretamente ao OP, mas eu queria corrigir uma impressão equivocada na resposta / comentários acima de Ronald e Daniel. (Eu sou novo, por isso não tenho pontos suficientes para comentar.)

O TRIM é de fato a maior coisa que você pode fazer para prolongar a vida útil de um SSD. Eis o porquê: os SSDs periodicamente "colhem lixo" - copiam os dados (fragmentados) de blocos de apagamento parcialmente vazios e os escrevem contiguamente em um bloco recém-apagado.

Os endereços são remapeados para que o host não precise estar ciente disso. Essa atividade extra de gravação, não diretamente associada à gravação do host, é chamada de "amplificação de gravação". No pior caso de um SSD completamente cheio com uma pequena quantidade de espaço superprovisionado (sobressalente oculto), a amplificação de gravação pode facilmente estar na faixa de 500% a 700% da taxa de gravação do host!

Durante a coleta de lixo, o SSD não se preocupa em copiar e reescrever páginas que foram invalidadas (substituídas ou TRIMmed), economizando uma quantidade potencialmente grande de atividades de trabalho e gravação. Se o sistema de arquivos apagar um arquivo grande, mas não informar a unidade via TRIM, a unidade continuará copiando os dados apagados, desperdiçando gravações indefinidamente (ou até que esses endereços de bloco sejam atribuídos a algum outro arquivo, que pode demorar muito).

Em resumo, o TRIM é realmente importante para a longevidade e o desempenho.

Eu afirmei isso no outro post que você vinculou, mas executamos um servidor de linha principal sem um arquivo de paginação e tudo aqui parece bem. De fato, parece mais rápido sem ele. Temos 8 GB de RAM e eu diria que você deve tomar sua decisão com base em se possui muita RAM, e não se o seu disco rígido é um SSD ou não. Embora eu possa entender o desejo de salvar a vida dela, não fazendo gravações desnecessárias.

Basta usar um segundo disco rígido para memória virtual.

Eu tenho um laptop com 8 GB de RAM, unidade única SSD e nenhum arquivo de paginação, há mais de um ano, sem problemas. Eu corri para um jogo que exigia o arquivo de paginação, fui ao site do software e obtive o comando run para desativá-lo, problema resolvido.

Meu laptop tem quatro anos. Antigo, mas roda mais rápido do que alguns desktops mais novos. Vazamentos de memória, também conhecido como arquivo SWAP, são o problema do sistema operacional Windows desde a criação da técnica. Infelizmente, os desenvolvedores do Linux seguiram seus passos. Quanto menos software você estiver executando em segundo plano, melhor (especialmente se for da Microsoft).

Eu diria que não use swap, se você puder se safar. Ou talvez abaixe o swappiness. Embora seja difícil desgastá-lo (quanto tempo levaria para gravar em toda a unidade 100.000 vezes, com a largura de banda máxima que você possui?), Se você não precisar.

Por outro lado, o hibernar (suspender no disco) não funciona sem algum tipo de troca.

Costumava haver algum comportamento estranho sem troca (como em um disco de 50 MB de RAM para troca seria uma vitória), mas isso foi corrigido no último verão (ou foi em 2007?), Portanto, um sistema operacional atual deve ficar bem.

Agora, tudo o que precisamos é de hardware que suporte o comando apagar (o Linux o suporta há meses), e a vida no SSD será simplesmente dândi.

Eu tive dois SSDs de classe empresarial que me queimaram muito prematuramente (isto é, dentro do período de garantia). Eu acho que o motivo foi a troca pesada devido a surras. Eu sempre percebi que tinha processos desnecessários executando daemons de buggy com vazamentos de memória, de modo que havia uma atividade de troca pesada quase continuamente. Eu corro iostat -n9 -w 10em segundo plano de tempos em tempos e percebo que muitas vezes há atividade contínua de disco pesado. Também a atividade do processo do kernel (swap) foi registrada como a fonte da maioria das E / S. Lembro-me de um daemon que teve um vazamento de memória por meses e precisou de matança periódica. Frequentemente, eu não soluciono problemas, a menos que o sistema seja irritantemente lento, e muitas vezes a debulhação durou muito tempo antes que eu dedicasse algum tempo para reiniciar o daemon. E mais para o vazamento ser corrigido.

Embora a desativação da troca chame minha atenção para a debulha, o problema seria resolvido antes que ocorresse um grande desgaste no SSD, está longe de ser a melhor maneira de evitar esses danos; qualquer ferramenta decente de monitoramento / alerta seria melhor.

Uma ressalva que muitas das respostas não reconhecem é que, se um servidor estiver executando um SSD continuamente, ele será esgotado rapidamente - os burnouts dentro de um ano nessa situação são comuns. O thrashing clássico geralmente ocorre quando a troca de memória virtual é pesada o suficiente para manter a unidade (swap) ocupada principalmente - bem dentro de uma ordem de magnitude de sua largura de banda máxima de E / S e há pelo menos um processo aguardando uma E / S relacionada à troca O para concluir na maioria das vezes que o sistema está nesse estado. As outras respostas assumem que o sistema não estádebatendo-se, pelo menos não da maneira clássica; ou confiar em um mal-entendido sobre o que é surra. E essa suposição falsa, apesar de outros dados precisos, leva a respostas incorretas quanto à paginação PORQUE, mesmo quando um SSD é o único local possível para o arquivo de troca, é melhor deixar ativado.

Desative o arquivo de paginação no disco quando houver muita memória não utilizada. Alguns programas antigos exigem uma funcionalidade de arquivo de paginação e, para esses, o Windows cria uma pequena funcionalidade de arquivo de paginação na memória.