Visualizando o uso da memória virtual

2

Eu iniciei mais de 700 threads a partir de um único programa E meu arquivo /proc/[PID]/status mostra a seguinte saída.

VmPeak:  7228104 kB
VmSize:  7228104 kB
VmLck:         0 kB
VmHWM:      3456 kB
VmRSS:      3456 kB
VmData:  7222340 kB
VmStk:        88 kB
VmExe:         4 kB
VmLib:      1540 kB
VmPTE:      2864 kB
StaBrk: 15e84000 kB
Brk:    15ec6000 kB
StaStk: 7fff765095a0 kB
Threads:        706

Mas estou tendo apenas 2GB de RAM e 4GB de espaço de troca. Alguém pode me dizer como a memória virtual chegou a 7gb +?

    
por Antarus 22.08.2013 / 14:15

3 respostas

2

Em alguns sistemas de memória virtual paginada por demanda, o sistema operacional se recusa a alocar páginas anônimas (ou seja, páginas contendo dados sem uma fonte de sistema de arquivos, como dados de tempo de execução, pilha de programas etc.), a menos que haja espaço swap suficiente para trocar as páginas a fim de liberar memória física. Essa contabilidade rigorosa tem a vantagem de que a cada processo é garantido o acesso à quantidade de memória virtual que eles alocam, mas também significa que a quantidade de memória virtual disponível é essencialmente limitada pelo tamanho do espaço de troca.

Na prática, os programas tendem a alocar mais memória do que eles usam. Por exemplo, o Java Virtual Machine aloca muita memória virtual na inicialização, mas não a utiliza imediatamente. A contabilização de memória no kernel do Linux tenta compensar isso rastreando a quantidade de memória realmente em uso pelos processos e supercomprometendo a quantidade de memória virtual. Em outras palavras, a quantidade de memória virtual alocada pelo kernel pode exceder a quantidade de memória física e espaço de troca combinados no sistema. Enquanto isso leva a uma melhor utilização da memória física e do espaço de troca, a desvantagem é que quando a quantidade de memória em uso excede a quantidade de memória física e espaço de troca disponível, o kernel deve de alguma forma liberar recursos de memória para atender a alocação de memória. compromisso.

O mecanismo do kernel usado para recuperar a memória é chamado de out-of-memory-killer (OOM-killer). Normalmente, o mecanismo começa a matar os processos "desonestos" que consomem memória para liberar memória para outros processos. Em alguns ambientes, uma opção viável para liberar memória e trazer o sistema de volta à operação pode ser a reinicialização. Para esses casos, o kernel pode ser configurado para entrar em pânico em uma condição de falta de memória por meio da configuração vm.panic_on_oom sysctl.

A heurística de contabilidade de memória usada pelo kernel pode se tornar mais liberal ou restrita por meio da configuração vm.overcommit_memory sysctl. Quando a contabilidade de memória restrita está em uso, o kernel não aloca mais páginas anônimas, a menos que tenha memória física livre suficiente ou espaço de troca para armazenar as páginas. Isso significa que é essencial que o sistema seja configurado com espaço de troca suficiente .

    
por 22.08.2013 / 22:05
1

Como um ponto tangencial, se seus encadeamentos forem criados e a função de encadeamento sair depois de executar seu trabalho, mas o VmDATA continuar aumentando, você terá um vazamento de memória.

Geralmente, quando uma função de thread sai, um pthread_exit é implícito, mas os recursos de thread não são liberados até um pthread_join ou pthread_detach. Portanto, para liberar explicitamente a pilha de encadeamentos do heap e fechar o vazamento, faça uma chamada explícita para ingressar ou desanexar.

    
por 25.09.2014 / 15:36
0

Isso porque a memória virtual não é o que o processo realmente está usando, é apenas o que poderia ser usado se usasse tudo que alocava.

Existe uma quantidade incrivelmente grande de descrições do termo "Memória Virtual" online porque este é um tópico comum de confusão, este é um deles: link

Este é mais específico para o Linux: link

    
por 22.08.2013 / 14:34