PostgreSQL y el OOM killer: por qué usamos un overcommit estricto de memoria

Modos de overcommit de Linux y PostgreSQL

• Varios comentaristas señalan que el overcommit estricto (vm.overcommit_memory=2) puede romper fork() y los reinicios de aplicaciones, especialmente si los ratios de overcommit ya están ajustados.
• Recomendación: probarlo estrictamente en QA/perf, hacer pruebas de carga y desplegarlo mediante scripts de despliegue antes de integrarlo en sysctl.
• Algunos prefieren el modo heurístico (0) con un overcommit_ratio muy bajo y un uso intensivo de oom_score_adj (por ejemplo, -1000 para servicios críticos), además de ajustar la reserva del kernel.
• Para PostgreSQL en particular, el overcommit estricto puede resultar atractivo porque maneja ENOMEM correctamente y revierte transacciones en lugar de fallar.

Hosts compartidos: Go / lenguajes gestionados frente a Postgres

• Problema del mundo real: backend en Go y Postgres en el mismo host.
• El overcommit heurístico causó fallos de asignación en Postgres; el overcommit estricto volvió inestable todo el sistema debido a grandes reservas virtuales de Go.
• Soluciones alternativas: ajustar empíricamente overcommit_ratio, usar GOMEMLIMIT para limitar el heap de Go, o aislar la base de datos y la app en nodos separados o mediante contenedores/cgroups.

OOM killer frente a fallos de asignación

• Hay un fuerte desacuerdo sobre si desactivar el overcommit es una buena idea.
• Algunos usuarios desactivan el overcommit y prefieren congelaciones breves en las que cierran aplicaciones manualmente, en lugar de que el kernel mate procesos “aleatorios” o críticos.
• Otros sostienen que eso solo cambia los OOM kills por fallos con ENOMEM, ya que la mayoría del software de escritorio no gestiona fallos de asignación y puede corromper el estado.
• El comportamiento del OOM killer del kernel en escritorios es ampliamente criticado por ser lento, impredecible y hostil para el usuario.

Windows/macOS y swap / compresión

• Varios comentarios contraponen Linux con Windows: Windows rastrea el commit charge, nunca hace overcommit y, por lo general, maneja las situaciones de poca memoria con más gracia.
• Algunos dicen que Windows, en la práctica, no tiene “OOM killer”, sino que rechaza asignaciones irrazonables; otros señalan que todavía puede matar o pedir cerrar la app problemática.
• Debate sobre desactivar el archivo de paginación de Windows: algunos lo hacen para “desactivar el overcommit”, otros dicen que casi siempre es una mala idea y destacan el archivo de paginación como salvaguarda.
• En Linux, los comentaristas abogan por swap, zram/zswap, MGLRU y demonios de OOM en espacio de usuario como valores por defecto más sensatos, especialmente frente a configuraciones estilo hyperscaler de “sin swap”.

Ángulos más amplios de diseño / lenguaje

• Algunos sostienen que el overcommit estricto en el escritorio es una trampa peligrosa debido a la falta generalizada de manejo de errores de malloc.
• Otros destacan que los sistemas robustos (especialmente las bases de datos) deberían implementar su propia contabilidad de memoria y estrategias de OOM.
• Un hilo secundario sugiere que los tipos más ricos de Rust (enums/Result) habrían evitado el error concreto de entero/booleano en C discutido en el artículo.