Por que as discussões sobre ato “swappiness” como a informação só pode estar em um lugar ao mesmo tempo?

Question

Eu estive lendo sobre sintonizável do Linux "swappiness", que controla o quão agressivo o kernel é sobre a troca de memória das aplicações no disco quando não estão sendo usados. Se você Google o termo, você tem um monte de páginas como este discutir os prós e contras. Em poucas palavras, o argumento é o seguinte:

Se o seu swappiness é muito baixo, aplicações inactivas vai monopolizar toda a memória do sistema que outros programas pode querer usar.

Se o seu swappiness é muito alto, quando você acorda os aplicativos inativos, não vai ser um grande atraso como seu estado está de volta leitura de um disco.

Este argumento não faz sentido para mim. Se eu tiver um aplicativo inativo que está usando uma tonelada de memória, por que não faz a página do kernel sua memória para o disco e deixar outra cópia do que os dados na memória? Isto parece dar o melhor de dois mundos: se outro aplicativo precisa que a memória, ele imediatamente pode reivindicar a memória RAM física e começar a escrever a ele, uma vez que outra cópia do mesmo está no disco e podem ser trocados de volta quando o aplicativo inativo é acordado acima. E quando o aplicativo originais acorda, qualquer uma de suas páginas que ainda estão na memória RAM pode ser usado como está, sem ter que retirá-los do disco.

Ou estou faltando alguma coisa?

Answer 1

De acordo com esta 1 que é exatamente o que o Linux faz.

Eu ainda estou tentando fazer sentido de um monte de presente, de modo que todos os links de autoridade seria apreciada.

Answer 2

Se eu tiver um aplicativo inativo que está usando uma tonelada de memória, por que não a página do kernel sua memória para o disco e deixar outra cópia do que os dados in-memory?

Vamos dizer que nós fizemos isso. Nós escrevemos a página em disco, mas deixou-o na memória. Um tempo depois, outro processo precisa de memória, por isso queremos chutar a página do primeiro processo.

Precisamos saber com absoluta certeza se o primeiro processo modificou a página desde que foi escrito para o disco. Se ele tem, temos que escrevê-lo novamente. A maneira que nós iria acompanhar este é para tirar a permissão escrita do processo para a página de volta quando escreveu primeiro para o disco. Se as tentativas de processo de escrever para a página novamente, haverá uma falha de página. O kernel pode-se notar que o processo tenha sujado a página (e, portanto, terá de ser escrita novamente) antes de restaurar a permissão de gravação e permitindo a aplicação para continuar.

É aí que reside o problema. Tirando permissão de escrita a partir da página é realmente um pouco caro, especialmente em multiprocessador máquinas. É importante que todas as CPUs limpar seu cache de traduções de páginas para se certificar de que tirar a permissão de gravação.

Se o processo não escreve para a página, tomando uma falha de página é ainda mais caro. Eu presumo que um número não-trivial destas páginas iria acabar tendo que falha, que come nos ganhos que estávamos procurando, deixando-a na memória.

Então vale a pena fazer? Eu honestamente não sei. Estou apenas tentando explicar por que sair da página na memória não é vitória um tão óbvio quanto parece.

(*) Essa coisa toda é muito semelhante a um mecanismo chamado Copy-On-Write, que é usado quando um garfo processo () s. O processo filho é muito provável que vai executar apenas algumas instruções e exec call (), então seria tolo para copiar todas as páginas pais. Em vez disso a permissão de gravação é retirado ea criança simplesmente permissão para executar. Copy-on-write é uma vitória, porque a falha de página quase nunca é tomada:. A criança quase sempre chama exec () imediatamente

Answer 3

Mesmo se você página da memória aplicativos para o disco e mantê-lo na memória, você ainda teria que decidir quando deve um pedido ser considerado "inativo" e é isso que os controles swapiness. Paginação para o disco é caro em termos de IO e você não quer fazê-lo muitas vezes. Há também uma outra variável na equação, e que é o fato de que o Linux usa de memória restante como buffers de disco / cache.

Answer 4

A primeira coisa que o VM faz é páginas limpas e movê-los para a lista limpa.
Ao limpar a memória anônima (coisas que não têm um armazenamento de arquivo de apoio real, você pode ver os segmentos em / proc mapas // que são anônimas e não têm de armazenamento do sistema de arquivos vnode por trás deles), a primeira coisa a VM vai fazer é tomar as páginas "sujas" e "limpo", em seguida, escrevendo o conteúdo da página para swap. Agora, quando o VM tem uma falta de memória totalmente gratuito e está preocupado com a sua capacidade de conceder novas páginas livres para ser usado, ele pode percorrer a lista de páginas 'limpas' e com base em como recentemente eles foram usados ??e que tipo de memória eles são de que irá mover essas páginas para a lista livre.

Uma vez que as páginas de memória são colocados na lista livre, eles não estão mais associados com o conteúdo que eles tinham antes. Se um programa vem ao longo de uma referências a localização de memória na página servia anteriormente o programa terá uma falha grave e uma página (provavelmente completamente diferente) será agarrado a partir da lista livre e os dados serão lidos na página do disco. Uma vez feito isso, a página é realmente ainda 'limpa', uma vez que não foi modificado. Se a VM escolhe usar essa página em swap para uma página diferente na RAM, em seguida, a página seria novamente 'sujo', ou se o aplicativo escreveu a essa página seria 'sujo'. E, em seguida, o processo começa novamente.

Além disso, swappinness é muito horrível para aplicativos de servidor em um negócio / online / ambiente transacional / latência-sensíveis. Quando eu tenho caixas de RAM 16GB onde eu não estou correndo um monte de navegadores e GUIs, eu normalmente quero todos os meus aplicativos quase fixadas na memória. A maior parte da minha RAM tende a ser 8-10GB montes java que eu NUNCA quer paginada para disco, nunca, eo cruft que está disponível são processos como mingetty (mas mesmo lá as páginas glibc nesses aplicativos são compartilhados por outros aplicativos e efectivamente utilizadas, por isso mesmo o tamanho RSS desses processos inúteis são na sua maioria compartilhada, páginas usadas). Eu normalmente não ver mais do que alguns 10Mbs da 16GB realmente limpos para swap. Aconselho números swappiness muito, muito baixas ou nulas swappiness para servidores - as páginas não utilizadas deve ser uma pequena fração da RAM total e tentando recuperar essa quantidade relativamente pequena de RAM para cache de buffer corre o risco de troca de páginas de aplicativos e tendo acessos de latência em o aplicativo em execução.