Eu tenho um processo que está relatando em 'top' que ele tem 6GB de memória residente e 70GB de memória virtual alocada. O estranho é que esse servidor específico tem apenas 8 GB de espaço físico e 35 GB de espaço disponível para troca.
Do manual "superior":
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 esta explicação, eu esperaria que a alocação de memória virutal de um processo fosse limitada à minha swap + memória física disponível.
De acordo com o 'pmap', as seções de código, biblioteca compartilhada e memória compartilhada deste processo são todas mínimas - não mais do que 300M 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 demanda de memória zero que não está no RAM físico ou no arquivo de paginação.
Alguns recursos que você pode querer ver:
Seu aplicativo cria muitas páginas de memória vazias? Em caso afirmativo, seu aplicativo pode se beneficiar muito de:
Permite comprimir e descomprimir em páginas de memória em tempo real. Por sua vez, você é capaz de manter tudo na memória RAM ao invés de trocar para o disco ( muito lento ).
Aqui está uma discussão sobre virt vs. memória residente:
A discussão refere-se a processos Java, mas é aplicável a qualquer coisa que esteja sendo executada no Linux. O ponto principal em relação à virt é que o total inclui um monte de coisas que nunca podem ser usadas. Virt é algo para se olhar para sistemas operacionais de 32 bits (já que os processos atingirão limites em espaço endereçável), mas em grande parte não é útil de outra forma. Como observado, a coisa a prestar atenção é a memória residente, que será limitada à RAM física disponível e à sua troca.
Isso é provável porque o espaço de endereço do processo é o tamanho que você declarou, mas não é realmente alocado pelo SO.
De: link
In the process of trying to reach that goal of "low enough overhead and no significant latency," the Go developers have made some simplifying assumptions, one of which is that the memory being managed for a running application comes from a single, virtually-contiguous address range. Such assumptions can run into the same problem your editor hit with vi - other code can allocate pieces in the middle of the range - so the Go developers adopted the same solution: they simply allocate all the memory they think they might need (they figured, reasonably, that 16GB should suffice on a 64-bit system) at startup time.
Então essa é a maneira deselegante com que o gerenciamento de memória é feito às vezes - ter um espaço de endereçamento contínuo simplifica a liberação de mems não utilizados.
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 de java não é muito complicado, você pode tentar brincar com "lsof" para encontrar onde o arquivo MMAP está. No entanto, se esse processo de java for complicado, será difícil de ser visto.
Também fiquei surpreso que o Linux permite que você aloque mais memória virtual do que memória física + espaço de troca, mas aparentemente ajuda o desempenho em situações típicas.
Fortunately, there is a kernel-tuning parameter that can be used to switch the memory accounting mode. This parameter is vm.overcommit_memory, and it indicates which algorithm is used to track available memory. The default (0), uses the heuristic method and overcommits the virtual memory system. If you want your programs to receive appropriate out-of-memory errors on allocation instead of subjecting your processes to random killings, you should set this parameter to 2.
Tags linux virtual-memory