Primeiro, os programas / processos não "comem" a memória. Eles usam ou são alocados memória.
VSZ (tamanho da memória virtual em kilobytes) é a soma de toda a memória virtual exigida pelo processo. Este tamanho é principalmente um atributo do processo / programa, e não sob o controle do sistema operacional.
RSS é o tamanho do conjunto residente, que é a quantidade de memória física alocada para o processo. Essa é a memória física usada para armazenar páginas de memória virtual residentes (em vez de localizadas no armazenamento de backup, ou seja, trocadas) enquanto o processo está sendo executado. O RSS será menor ou igual ao tamanho da memória virtual do processo.
Observe que, às vezes, o RSS é relatado como o número de páginas (que normalmente tem um tamanho de 4096 bytes) em vez de em kilobytes. Então, nessas situações, comparar o VSZ ao RSS é inadequado.
Observe que esses tamanhos para o processo podem incluir bibliotecas compartilhadas assim como memória para código / texto, dados, heap e pilha. Cabe ao SO agendar processos e determinar quais páginas do processo permanecem residentes na memória (física) e quais são trocadas. É mais provável que as bibliotecas compartilhadas sejam mantidas residentes do que as páginas usadas exclusivamente pelo processo. Um processo no estado adormecido (por exemplo, STAT == D1 ou STAT == S1) poderia ter a maioria de suas páginas trocadas e ter um pequeno RSS. Tudo está sob o controle do sistema operacional e a dinâmica da execução do processo.
Observe também que o Linux é diferente da maioria dos outros * nixes em que o Linux (a menos que configurado de outra forma) irá confirmar demais os pedidos para ( memória virtual. Portanto, mesmo que nenhum quadro de página ou espaço de troca seja alocado para o processo (até que o processo tente acessar essa memória "alocada"), seu VSS poderá aumentar.
Adendo : resposta ao comentário
is why a difference is so huge? sometimes VSZ is 20 times bigger than RSS, even on system with no swap.
Você está citando um exemplo específico sem fornecer detalhes.
O recurso de supercomprometimento do Linux pode ser um fator para uma grande discrepância entre o VSZ e o RSS, se não houver troca. Esse programa usa malloc() s de buffers grandes, mas não usados?
Talvez você tenha que avaliar o uso de memória desse processo usando ferramentas de memória como pmap e top , o que fornecerá um pouco mais de detalhes.
Veja "Runtime_Memory_Measurement" para obter mais informações. A documentação de top declara que
SWAP -- Swapped size (kb)
The swapped out portion of a task's total virtual memory image.
RES -- Resident size (kb)
The non-swapped physical memory a task has used.
RES = CODE + DATA.
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.
VIRT = SWAP + RES
Não sei se essas definições top devem considerar a memória virtual que foi confirmada, mas que ainda não alocou recursos físicos. Eu acho que sim, mas a equação VIRT foi simplificada pela omissão da situação (incomum) de ter memória virtual consolidada mas não alocada.
Adendo 2 : resposta ao comentário
Maybe try running top or htop on your own computer, you will see that there is a number of processes that use significant amount of VSZ and almost no RSS
Não viu nada de interessante no meu sistema Ubuntu:
PID PR NI VIRT RES SHR S %CPU %MEM SWAP CODE DATA nDRT COMMAND
26379 20 0 20812 7996 3496 S 4 0.4 12m 4 2828 0 gs
1082 20 0 85292 46m 15m S 2 2.5 36m 1660 30m 0 Xorg
2036 20 0 22948 8756 7148 S 1 0.4 13m 40 788 0 multiload-apple
2411 20 0 47984 19m 10m S 1 1.0 27m 1924 7584 0 python
62 20 0 0 0 0 S 0 0.0 0 0 0 0 kondemand/0
930 20 0 3236 1528 792 S 0 0.1 1708 284 820 0 dbus-daemon
1618 20 0 6964 3084 2244 S 0 0.2 3880 420 836 0 cupsd
1971 20 0 15708 3100 2484 S 0 0.2 12m 216 10m 0 udisks-daemon
2037 20 0 39316 11m 9676 S 0 0.6 26m 76 1404 0 sensors-applet
25733 20 0 2568 1280 956 R 0 0.1 1288 64 480 0 top
2473 20 0 6712 4060 1564 S 0 0.2 2652 780 2492 0 bash
Para todos os processos do usuário, VIRT == SWAP + RES era verdadeiro, mas RES == CODE + DATA não era.
Eu tenho alguns SBCs executando o Linux embarcado, mas não tenho top cross-compilado para eles. Olhando para /proc/<pid>/stat para um processo de shell, há VSZ = 580kB e RSS = 200kB (na verdade, 50 páginas), mas é claro que /proc/meminfo reporta zero bytes para swap. Talvez a obtenção de top em execução neste SBC possa ser interessante (já que não sei onde top obtém seus números para swap).