Entendendo o uso de memória virtual> swap + físico no Linux

Eu tenho um processo que está relatando na parte superior que possui 6 GB de memória residente e 70 GB de memória virtual alocada. O estranho é que esse servidor específico possui apenas 8 GB de espaço físico e 35 GB de espaço de troca disponível.

No manual 'top':

   o: VIRT  --  Virtual Image (kb)
      The total amount of virtual memory used by the  task.   It  includes
      all  code,  data  and  shared  libraries  plus  pages that have been
      swapped out. (Note: you can define the STATSIZE=1 environment  vari-
      able  and  the VIRT will be calculated from the /proc/#/state VmSize
      field.)

      VIRT = SWAP + RES.

Dada essa explicação, eu esperaria que a alocação de memória virutal de um processo seja limitada à minha troca + memória física disponível.

De acordo com o 'pmap', o código, a biblioteca compartilhada e as seções de memória compartilhada desse processo são mínimas - não mais que 300 milhões ou mais.

Obviamente, a máquina e o processo ainda estão funcionando corretamente (embora lentamente), então o que estou perdendo aqui?

Pode ser que exija zero de memória que não esteja na memória RAM física ou no arquivo de paginação.

Alguns recursos que você pode querer considerar:

• http://www.gitam.edu/eresource/comp/gvr(os)/13.6.htm
• http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.system/2006-11/msg00176.html

Seu aplicativo cria muitas páginas de memória vazias? Nesse caso, seu aplicativo pode se beneficiar muito de:

• http://code.google.com/p/compcache/ ( EXPERIMENTAL )

Permite compactar e descomprimir em páginas de memória em tempo real. Por sua vez, você é capaz de manter tudo na RAM, em vez de trocar para o disco ( muito lento ).

Aqui está uma discussão entre virt vs. memória residente:

/programming/561245/virtual-memory-usage-from-java-under-linux-too-much-memory-used

A discussão refere-se a processos Java, mas é aplicável a qualquer coisa em execução no Linux. O ponto principal em relação à virtude é que o total inclui um monte de coisas que nunca podem ser usadas. O Virt é algo para se olhar para sistemas operacionais de 32 bits (já que os processos atingirão limites no espaço endereçável), mas, em grande parte, não é útil. Como observado, o ponto a ser observado é a memória residente, que será limitada à RAM física disponível e à sua troca.

Provavelmente, porque o espaço de endereço do processo é do tamanho que você especificou, mas não é realmente alocado pelo sistema operacional.

De: http://lwn.net/Articles/428100/

No processo de tentar atingir esse objetivo de "sobrecarga baixa o suficiente e sem latência significativa", os desenvolvedores do Go fizeram algumas suposições simplificadoras, uma das quais é que a memória que está sendo gerenciada para um aplicativo em execução provém de uma única e praticamente contígua intervalo de endereços. Essas suposições podem ter o mesmo problema que seu editor encontrou com vi - outro código pode alocar partes no meio do intervalo - então os desenvolvedores do Go adotaram a mesma solução: eles simplesmente alocam toda a memória que acham que podem precisar (eles imaginaram, razoavelmente, que 16 GB devem ser suficientes em um sistema de 64 bits) no momento da inicialização.

Portanto, às vezes é assim que o gerenciamento de memória é deselegante - ter um espaço de endereço contínuo simplifica a liberação de mem não utilizado.

A resposta provavelmente é MMAP - os dados estão no disco, mas estão "fora" da troca e não podem ser vistos com o comando "free" ou "top".

Se o processo java não for muito complicado, tente jogar com "lsof" para descobrir onde está o arquivo MMAP. No entanto, se esse processo java for complicado, será difícil ver isso.

Também fiquei surpreso que o Linux permita que você aloque mais memória virtual do que a memória física + o espaço de troca, mas aparentemente ajuda no desempenho em situações típicas.

Felizmente, existe um parâmetro de ajuste do kernel que pode ser usado para alternar o modo de contabilidade da memória. Este parâmetro é vm.overcommit_memory e indica qual algoritmo é usado para rastrear a memória disponível. O padrão (0), usa o método heurístico e supercompromete o sistema de memória virtual. Se você deseja que seus programas recebam erros de falta de memória apropriados na alocação, em vez de sujeitar seus processos a mortes aleatórias, defina esse parâmetro como 2.

http://www.linuxjournal.com/article/10678