PostgreSQL e OOM Killer: A Imperativa Gestão de Memória com Strict Overcommit

A gestão de memória é um pilar crítico para a estabilidade de qualquer sistema, especialmente em bancos de dados de alta performance como o PostgreSQL. A abordagem de strict memory overcommit no Linux, configurada via vm.overcommit_memory=2, é uma prática essencial para desenvolvedores que buscam robustez. Ela transforma uma potencial catástrofe de falha de Out-Of-Memory (OOM), que derruba todo o serviço e pode corromper dados, em um erro de alocação de memória mais gerenciável (ENOMEM) para uma única conexão, preservando a integridade e a disponibilidade do banco.

O problema do OOM Killer não é exclusivo do PostgreSQL. Como noticiamos em 7 de junho de 2026 na matéria sobre a proteção nativa da Vercel contra 'out of memory' em builds, falhas por esgotamento de memória são um desafio comum que afeta diversas camadas da infraestrutura tecnológica. Para o PostgreSQL, a complexidade é maior devido à sua arquitetura de processos filhos compartilhando memória. A Ubicloud, com vasta experiência em serviços gerenciados de PostgreSQL, adota essa configuração de forma consistente, ressaltando sua importância na arquitetura de sistemas.

Apesar da eficácia do strict memory overcommit, ele foi temporariamente desabilitado pela Ubicloud devido a um bug crítico no kernel Linux 6.5. Esse defeito, introduzido pelo commit 408579c, causava um vazamento no contador Committed_AS, levando o sistema a relatar um uso de memória muito maior do que o real. Isso resultava em falhas de alocação mesmo com memória física disponível.

A boa notícia é que o problema foi diagnosticado, inclusive com auxílio de uma IA para analisar commits do kernel, e Linus Torvalds implementou a correção. A resolução do bug permite que a prática de strict memory overcommit seja reativada com segurança, restaurando a proteção que ela oferece para o PostgreSQL e garantindo a contabilização precisa da memória alocada, um retorno à boa prática para garantir a estabilidade em ambientes de produção.

Para o profissional de desenvolvimento, gerenciar a memória de forma proativa minimiza dores de cabeça com incidentes em produção. A adoção de strict memory overcommit é uma medida de segurança que impacta diretamente a experiência do desenvolvedor (DX) e a confiabilidade do software. Ao evitar que um OOM derrube todo o servidor PostgreSQL, ganhamos em tempo de atividade e reduzimos a complexidade da recuperação de desastres, convertendo um evento catastrófico em um erro pontual e tratável.

A configuração precisa do CommitLimit, como a heurística de 80% da memória física mais 2 GB, é um exemplo de boa prática. Ela considera não só o uso do PostgreSQL, mas também de sidecars e estruturas do kernel, evitando que processos auxiliares consumam indevidamente o orçamento de memória. Isso garante que o banco de dados tenha os recursos necessários, prevenindo interrupções e otimizando a performance, especialmente em cenários de alta demanda.