Mais uma curiosidade do que um problema; e, admito, algo de uma questão embaraçosamente básica:
Tenho notado que em muitas ocasiões, em minha máquina Linux, terei ~ 500MB de espaço de troca em uso, mesmo que eu tenha ~ 600MB de RAM não usada.
Meu entendimento ingênuo de alto nível foi que o espaço de troca não entra em ação até que a RAM esteja esgotada.
Eu fui além e assumi que essa situação deve ser a do kernel do Linux, porque um processo do usuário que solicita memória, faz isso apenas logicamente, e não tem noção de se essa memória é fisicamente suportada pela RAM ou pelo espaço de troca.
O que leva à pergunta, por que o kernel usaria preventivamente o espaço de troca? Isso faz parte de algum algoritmo de ajuste de desempenho? Ele está trocando para partes de disco da memória que ele considera menos provável de ser acessado (um esquema de LRU, talvez)? Em caso afirmativo, não faria sentido deixar tudo na RAM, e somente quando estiver próximo do esgotamento, então e somente então trocar as porções da LRU da RAM para o espaço de troca?
Devo esclarecer, meu servidor linux tem 2GB de RAM e 2GB de espaço de troca.
A parte não usada da RAM é de fato usada como cache HDD. Se você pensar sobre isso, você realmente lê partes do seu disco com mais freqüência que você acessa algumas partes da RAM. O que faz sentido colocar essa RAM no disco, enquanto usa RAM para armazenar os dados do disco rígido.
Faz sentido trocar as coisas antecipadamente desde que você realmente precisa da memória, você não terá que esperar até que o kernel seja feito com acesso ao disco.
Por exemplo, digamos que você queira abrir uma imagem grande. Quando a imagem é carregada, são necessários 300MB de RAM. Se o kernel usar toda a RAM que puder, carregar sua imagem requer que o kernel transfira 200MB da RAM para o disco. Se esvaziou proativamente a RAM, você economiza alguns milissegundos.
2 motivos:
Além das outras respostas, você pode configurar o Linux para exigir backup de qualquer memória alocada, mesmo que os programas não a usem.
Overcommitting memory and fearing the OOM killer are not necessary parts of the Linux experience, however. Simply setting the sysctl parameter vm/overcommit_memory to 2 turns off the overcommit behavior and keeps the OOM killer forever at bay. Most modern systems should have enough disk space to provide an ample swap file for most situations. Rather than trying to keep pet processes from being killed when overcommitted memory runs out, it might be easier just to avoid the situation altogether. [Respite from the OOM killer]
Se um programa aloca memória, o kernel pode simplesmente marcar mais páginas de swap como confirmadas. Essa indicação é armazenada no gerenciador de memória do kernel, o espaço em disco real ainda não foi tocado. Até que essa memória seja usada, nada realmente precisa ser trocado para dentro e para fora. Se eles nunca são usados, o uso de swap irá variar sem afetar o desempenho.
Como os processos são apresentados com seu próprio espaço de endereço ou "view" (é assim que a troca funciona, em primeiro lugar), o kernel tem muita margem de manobra para gerenciar isso. Usando um exemplo de fork a partir do artigo ligado acima, uma vez que é muito mais provável que tenha páginas de memória compartilhada do que alocar recentemente uma grande quantidade de memória não utilizada, a memória pode ser alocada copy-on-write, aumentando a contagem de uso de swap. Quando é realmente escrito para (o que pode não acontecer), então essa "troca confirmada" pode ser substituída por qualquer RAM não usada (aumentando o uso de RAM e diminuindo o uso de swap). Imagine um processo com 500MB alocados em uma máquina com todas ou quase todas as RAM em uso. Se houver 500MB disponíveis em swap (e o espaço em disco for barato, quão grande é 1% dos drives TB de hoje?: P), nenhuma memória deve ser copiada (ainda, e possivelmente nunca), mas o kernel pode garantir essas alocações "bem-sucedida" e continue usando as páginas de memória compartilhada pelo maior tempo possível.
Assim, evita-se a possibilidade do OOM killer, e é muito mais simples projetar a maioria dos softwares com a suposição de que as alocações de memória (incluindo alocações "implícitas" por algo como fork) sejam bem sucedidas ou falhem imediatamente, com a percepção prática de que memória deve ser trocada, então isso pode afetar o desempenho. Esse impacto é quase sempre pequeno, mas na pior das hipóteses leva à troca de dados (ainda às vezes preferível a uma falha do kernel ou um assassino de OOM).Embora eu não saiba os detalhes exatos de como funciona o gerenciador de memória Linux, essa resposta é o meu próprio entendimento generalizado e o que me lembro de ter lido ao longo dos anos. Eu tentei reeditar essa resposta para que seja necessária uma compreensão mínima do design do sistema operacional (é consideravelmente complexo e não é algo que eu estou terrivelmente interessado em mim), mas parece divagar um pouco; por favor, deixe-me saber se você vê como poderia ser melhorado. Na mão emocionante, pode não ser uma questão tão embaraçosamente básica.