PostgreSQL e o OOM killer: Por que usamos overcommit de memória estrito

Artigo original ↗ Discussão no Hacker News ↗

Modos de overcommit do Linux e PostgreSQL

  • Vários comentaristas enfatizam que o overcommit estrito (vm.overcommit_memory=2) pode quebrar fork() e reinicializações de aplicações, especialmente se as razões de overcommit já estiverem ajustadas.
  • Recomendação: testar rigorosamente em QA/perf, fazer testes de carga e aplicar via scripts de implantação antes de incorporá-lo em sysctl.
  • Alguns preferem o modo heurístico (0) com overcommit_ratio muito baixo e uso intenso de oom_score_adj (por exemplo, -1000 para serviços críticos), além de ajuste da reserva do kernel.
  • Especificamente para PostgreSQL, o overcommit estrito pode ser atraente porque lida com ENOMEM de forma limpa e faz rollback das transações em vez de travar.

Hosts compartilhados: Go / linguagens gerenciadas vs Postgres

  • Problema real: backend em Go e Postgres no mesmo host.
  • O overcommit heurístico causou falhas de alocação no Postgres; o overcommit estrito deixou todo o sistema instável devido a grandes reservas virtuais do Go.
  • Soluções alternativas: overcommit_ratio ajustado empiricamente, uso de GOMEMLIMIT para limitar o heap do Go, ou isolar o banco de dados e a aplicação em nós separados ou via contêineres/cgroups.

OOM killer vs falhas de alocação

  • Forte divergência sobre se desativar o overcommit é sensato.
  • Alguns usuários desativam o overcommit e preferem congelamentos curtos em que fecham aplicativos manualmente, em vez de o kernel matar processos “aleatórios” ou críticos.
  • Outros argumentam que isso apenas troca mortes por OOM por travamentos com ENOMEM, já que a maioria do software de desktop não trata falhas de alocação e pode corromper o estado.
  • O comportamento do OOM killer do kernel em desktops é amplamente criticado por ser lento, imprevisível e hostil ao usuário.

Windows/macOS e swap / compressão

  • Vários comentários contrastam o Linux com o Windows: o Windows acompanha o commit charge, nunca faz overcommit e, em geral, lida com situações de pouca memória de forma mais graciosa.
  • Alguns dizem que o Windows efetivamente não tem “OOM killer”, rejeitando alocações absurdas; outros observam que ele ainda pode matar ou pedir para fechar o aplicativo problemático.
  • Debate sobre desativar o arquivo de paginação do Windows: alguns fazem isso para “desativar o overcommit”, enquanto outros chamam isso de quase sempre má ideia e enfatizam o arquivo de paginação como segurança.
  • No Linux, comentaristas defendem swap, zram/zswap, MGLRU e daemons de OOM em espaço de usuário como padrões mais sensatos, especialmente em comparação com configurações de hyperscalers “sem swap”.

Ângulos mais amplos de design / linguagem

  • Alguns argumentam que o overcommit estrito no desktop é uma armadilha devido ao descaso generalizado com o tratamento de erros de malloc.
  • Outros destacam que sistemas robustos (especialmente bancos de dados) deveriam implementar sua própria contabilidade de memória e estratégias de OOM.
  • Um fio lateral sugere que os tipos mais ricos do Rust (enums/Result) teriam evitado o bug específico de inteiro/booleano em C discutido no artigo.