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

Question

Eu tenho lido esta questão , e tem muita informação excelente.

Mas supondo que você tenha RAM mais que suficiente, acho que o arquivo de paginação deve estar desabilitado no SSD para estender o tempo de vida útil. Eu sei que você perderia o despejo principal no acidente, mas muitas pessoas não precisam dessa informação.

Do meu ponto de vista, sem um arquivo de paginação, quando você atinge o limite de sua RAM, isso pode desencadear uma surra no disco. Mas para SSDs não há noção de surra, as leituras são rápidas.

O que vocês acham?

    

Answer 1

But assuming you have more than enough RAM, I think page file should be disabled on SSD to extend the life time. I know you would lose the core dump on crash, but not many people need that information

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

Há também um grande volume de desinformação, tanto na maior Internet quanto no Server Fault, sobre SSDs que sofrem de vida ruim. Os primeiros modelos de SSDs podem ter tido problemas, e os flash drives USB definitivamente começam a degradar, mas os 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.

drives 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ê está saturando a interface de gravação (200 MB / seg) sem parar, com sobrescrever, minha estimativa é que você durará cerca de 58 dias. Mas isso é escrever algo como 17 TB de dados por dia para essa 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 isso de 50 GB por dia. Se a figura do 1 PB estiver correta (e eu sei que pode ser considerada uma figura média, mais discussão depois), isso ainda está em algum lugar ao norte de 50 anos.

Esses números parecem absurdamente altos, é claro, então vamos ver números reais citado pela Intel para a longevidade esperada dos drives . A Intel ficou feliz em qualificar as unidades MLC (não corporativas) para escrever 100 GB de dados, todos os dias, durante cinco anos. A compreensão padrão do flash SLC vs. MLC diz que o flash SLC dura cerca de 10 vezes mais do 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 os drives falharem cedo ou não. Mas os números por trás dos drives se somam para evitar que a longevidade seja um problema com SSDs de qualidade decente em tudo .

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

Pessoalmente, eu diria strongmente não usar um SSD MLC em um ambiente de servidor de produção. Se um SSD decente do SLC for muito caro, mantenha os discos girando por enquanto.

(Como um aparte, se você fizer os números, digamos 100 GB por dia por 50 anos, que é a classificação "SLC dura 10 vezes mais que MLC", parece que a Intel está dizendo que sua unidade de 32 GB realmente tem um vida útil total de gravação de mais perto de 2 PB de dados, não o PB 1 citado na especificação do produto.Mesmo se eu confiar apenas o menor desses dois valores para ser feliz que minhas unidades X25-E deve durar bem ao norte de 10 anos.

    

Answer 2

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

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

Should the pagefile be placed on SSDs?

Yes. Most pagefile operations are small random reads or larger sequential writes, both of which are types of operations that SSDs handle well.

In looking at telemetry data from thousands of traces and focusing on pagefile reads and writes, we find that

• Pagefile.sys reads outnumber pagefile.sys writes by about 40 to 1
• Pagefile.sys read sizes are typically quite small, with 67% less than or equal to 4 KB, and 88% less than 16 KB.
• Pagefile.sys writes are relatively large, with 62% greater than or equal to 128 KB and 45% being exactly 1 MB in size. In fact, given typical pagefile reference patterns and the favorable performance characteristics SSDs have on those patterns, there are few files better than the pagefile to place on an SSD.

Suporte e Q & A para unidades de estado sólido (MSDN)

    

Answer 3

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

O SO evitará usá-lo, a menos que seja necessário, salvando as gravações desnecessárias do SSD.

    

Answer 4

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

Dito isto, eu rodei o Windows (XP) sem um arquivo de paginação no passado, e ele está perfeitamente feliz com tudo que eu joguei nele. Sempre houve a dúvida de que alguma coisa aconteceria e que não fosse gostar.

Uma opção pode ser definir muito pequena.

    

Answer 5

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

TRIM é de fato a maior coisa que você pode fazer para estender o vida de um SSD. Aqui está o porquê: SSDs periodicamente "coleta de lixo" - copie os dados (fragmentados) de blocos de apagamento parcialmente vazios, e escreva-os 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 de gravação extra, não diretamente associada a gravações de host, é chamada de "amplificação de gravação". Na pior das hipóteses, de um SSD completamente cheio com uma pequena quantidade de espaço sobrescovisionado (reposição oculto), a amplificação de gravação pode facilmente estar na faixa de 500% - 700% da taxa de gravação do host!

Durante a coleta de lixo, o SSD não se preocupa em copiar e reescrever as páginas que foram invalidadas (sobrescritas ou TRIMmed), economizando uma grande quantidade de trabalho e atividade de 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, perdendo gravações indefinidamente (ou até que esses endereços de bloco sejam atribuídos a algum outro arquivo, o que pode demorar muito tempo).

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

    

Answer 6

Eu afirmei isso no outro post que você vinculou, mas nós rodamos um servidor muito main-line sem um arquivo de paginação e tudo aqui parece bem. Na verdade, parece mais rápido sem ela. Temos 8GB de RAM e eu diria que você deve tomar sua decisão com base em se você tem muita memória RAM, não se seu disco rígido é um SSD ou não. Embora eu possa entender o desejo de salvar a vida dele, não fazendo gravações desnecessárias.

    

Answer 7

Use apenas um segundo disco rígido para memória virtual.

    

Answer 8

Estou usando 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 da página, fui ao site do software e recebi o comando de execução para desativá-lo, problema resolvido.

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

    

Answer 9

Eu diria que não use swap, se você puder se safar. Ou talvez mude o modo de swap. Embora seja difícil usar um (quanto tempo levaria para gravar toda a unidade 100.000 vezes, com a largura de banda máxima que você tem?), Se não for necessário.

Então, novamente, o hibernate (suspender para o disco) não funciona sem algum tipo de swap.

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

Agora, tudo o que precisamos é de um hardware que suporte o comando erase (o Linux o suporta há meses), e a vida útil do SSD será apenas dandy.

    

Answer 10

Desative o arquivo de paginação no disco quando você tiver muita memória não utilizada. Alguns programas antigos exigem uma funcionalidade de arquivo de paginação e para aqueles O Windows criará uma pequena funcionalidade de arquivo de paginação na memória.

    

Answer 11

Eu tive um SSD de classe corporativa me queimando prematuramente. Minha máquina normalmente precisa estar ligada a menos que eu esteja dormindo. Eu não tenho grandes evidências, mas acho que o motivo foi uma troca pesada. Muitas vezes eu tinha muitas janelas abertas / coisas rodando / daemons com bugs com vazamentos de memória, de tal forma que, suspeito, houve alguma atividade de troca quase continuamente. Lembro-me de executar o iostat de tempos em tempos e perceber que muitas vezes havia uma atividade contínua em disco pesado. Lembro-me de um daemon que tinha um vazamento de memória por meses e precisava de matança periódica. Eu não resolvi o problema a menos que o sistema fosse irritantemente lento, então isso provavelmente durou muito tempo antes de eu ter tempo para reiniciar o daemon. E mais tempo para o vazamento ser corrigido.

Espere, oops - isso é serverfault. Mas para alguns servidores, não é mais fácil (e mais crítico) gerenciar cargas de trabalho de tal forma que você não esteja trocando uma tonelada. Então isso é relevante.