Desmistificando o tmpfs: reduzir partições temporárias realmente libera RAM no Linux?

O que o tmpfs faz com a sua RAM: limites, remount e consumidores ocultos#

Ao fazer uma checagem de rotina nos recursos do sistema pelo terminal, executei o comando df -h e me deparei com a seguinte saída:

Sist. Arq.      Tam. Usado Disp. Uso% Montado em                                                                    
tmpfs           939M  1,8M  937M   1% /run                                                                          
/dev/sda6        91G   39G   48G  45% /                                                                             
tmpfs           4,6G  219M  4,4G   5% /dev/shm                                                                      
tmpfs           4,6G     0  4,6G   0% /run/qemu

Olhando para os 4,6G alocados para o /dev/shm e para o /run/qemu, a primeira dúvida comum é: se eu redimensionar e diminuir esse tmpfs, vou liberar imediatamente mais memória RAM para os meus processos?

Ao analisar a arquitetura do kernel Linux, a resposta direta é não. No entanto, entender como o tmpfs funciona e por que ajustá-lo é essencial para manter a estabilidade do sistema.

1. O erro conceitual: como o tmpfs enxerga a RAM#

Existe uma confusão frequente ao interpretar a coluna "Tam." (Tamanho) no df -h. Muitos assumem que aquele espaço físico está bloqueado (locked) na memória RAM, aguardando uso.

No Virtual File System (VFS) do Linux, a alocação de memória no tmpfs é estritamente sob demanda (lazy allocation). O valor de 4,6G reportado não é um espaço pré-alocado, mas sim um teto máximo permitido (upper bound constraint).

No meu caso, o /dev/shm (usado para memória compartilhada POSIX e IPC) estava ocupando apenas 219M. Apenas esses 219 Megabytes estavam consumindo memória física real. O restante do espaço (4,4G) era puramente virtual, aguardando que algum processo executasse escritas para que o alocador do kernel entregasse páginas físicas reais.

2. Por que limitar o tmpfs se ele não devolve RAM de imediato?#

Se diminuir o tmpfs não libera RAM instantaneamente, por que ajustar esses limites? A resposta é simples: prevenção contra o OOM (Out-Of-Memory) Killer.

Por padrão, ao montar um tmpfs, o kernel concede um limite de até 50% da memória RAM física disponível. Se uma aplicação com memory leak ou um container desgovernado começar a despejar dados massivamente em /dev/shm, o kernel alocará páginas físicas até atingir esse teto.

Quando a memória se esgota:

1. O processo kswapd0 entra em ação tentando enviar páginas de processos úteis para a swap.
2. O sistema entra em lentidão extrema (thrashing).
3. O OOM Killer é acionado pelo kernel, encerrando processos vitais para salvar o host.

Ao definir uma cota mais restrita no tmpfs, mudamos esse comportamento. Se um processo tentar gravar além do limite via write() ou mmap(), a syscall falha imediatamente, o kernel retorna -1 e define o erro como ENOSPC (No space left on device). A gravação é contida na hora, protegendo o restante do sistema.

3. Ajustando limites a quente e de forma persistente#

Para aplicar o ajuste sem causar paradas em serviços ativos:

Redimensionamento dinâmico em tempo de execução#

Para limitar o /dev/shm a 1G mantendo intactos os 219M já gravados:

mount -o remount,size=1G /dev/shm

Atenção: Você não pode definir um size menor do que a quantidade de páginas sujas (dirty pages) já ocupadas em memória.

Persistência no /etc/fstab com flags de segurança#

Para manter a regra após reinicializações, adicione a entrada no /etc/fstab, aproveitando para aplicar flags de segurança recomendadas (nodev, nosuid, noexec):

tmpfs   /dev/shm    tmpfs   defaults,nodev,nosuid,noexec,size=1G   0   0

4. Rastreando os reais consumidores de RAM#

Para identificar o que realmente estava consumindo memória no servidor:

Descritores abertos em memória compartilhada#

lsof +D /dev/shm

Inspeção do slab allocator (caches internos de inodes e dentry)#

slabtop -o -s c | head -n 15

Leitura global de memória e caches#

cat /proc/meminfo | egrep 'MemTotal|MemFree|MemAvailable|Cached|Swap'

Lições práticas sobre o uso do tmpfs#

1. O tmpfs não reserva RAM estática: O tamanho exibido pelo df -h é um limite virtual superior. Apenas os dados efetivamente gravados consomem memória física.
2. Restringir o tamanho previne travamentos: Limitar o /dev/shm impede que aplicações com falhas consumam metade da RAM e ativem o OOM Killer.
3. Remontagem sem reinicialização: É possível ajustar a cota em tempo real com mount -o remount,size=X sem perder os dados armazenados em memória compartilhada.

Veja também

Linux Por que seu servidor precisa de SWAP mesmo com espaço em disco: mecânica de kernel e setup de 4GB

Servidores Debugging de baixo nível no CloudLinux: syscalls, LVE e o perigo dos limites ilimitados

Desenvolvimento Debugging de baixo nível: entendendo exit code 126, kernel VFS e falhas de posix_spawn no Bun

Este post está licenciado sob CC BY-NC.