Cómo hacer que Postgres sea lento

• Introducción a un enfoque experimental sobre combinaciones de parámetros que pueden degradar drásticamente el rendimiento de Postgres
• En general, se ajustan a la inversa varios factores como caché, índices, WAL e I/O
• Al manipular de forma extrema shared_buffers, autovacuum y opciones relacionadas con WAL, se logró una caída de TPS de 42,000 veces
• También se aplicaron funciones recientes como io_method e io_workers de las nuevas versiones Postgres 18/19 para forzar una limitación a un solo hilo de I/O
• Los resultados demuestran que solo con el archivo de configuración de Postgres es posible provocar una degradación extrema del rendimiento

---

Resumen general

Este artículo presenta un experimento que, en vez de enfocarse en optimizar Postgres para hacerlo más rápido, busca exclusivamente hacerlo más lento, llevando el rendimiento al límite mediante cambios únicamente en distintos valores de configuración de PostgreSQL.
La prueba se basó en la carga TPC-C de BenchBase (128 almacenes, 100 conexiones, cada una intentando hasta 10,000 transacciones por segundo, Postgres 19devel reciente, Ryzen 7950x, 32GB de RAM, SSD de 2TB, durante 120 segundos).
Con la configuración base, el rendimiento fue de 7082 TPS, y se observó paso a paso cuánto se degradaba al manipular cada parámetro.

Reducir drásticamente el caché

• Postgres utiliza un caché potente (shared_buffers) para reducir el I/O de disco
• Al bajar shared_buffers a 8MB desde el valor base (10GB), el TPS cayó a cerca de 1/7 (1052 TPS)
• Se observó que la tasa de aciertos de caché bajó de 99.90% a 70.52%, y que las llamadas al sistema de lectura aumentaron más de 300 veces
• Se intentó reducirlo hasta 128kB, pero Postgres solo permitió un mínimo de aproximadamente 2MB, lo que produjo una caída adicional hasta 485 TPS

Aumentar las tareas en segundo plano (ajuste de autovacuum)

• Se llevaron al mínimo todos los umbrales relacionados con autovacuum, haciendo que vacuum se ejecutara casi en cada operación
  • combinación de autovacuum_vacuum_insert_threshold=1, autovacuum_naptime=1, etc.
  • vacuum se repetía prácticamente cada segundo incluso cuando en la práctica no tenía trabajo que hacer
• En este proceso también se redujo maintenance_work_mem a 128kB y se activó todo el logging de autovacuum
• Como resultado, el TPS cayó a 293 (menos de 1/20 del original)
• A través de los logs en tiempo real de autovacuum, se confirmó que la causa de la degradación eran las tareas en segundo plano excesivamente frecuentes

Empeorar al máximo las escrituras de WAL (Write-Ahead Log)

• Todos los parámetros relacionados con WAL se ajustaron al peor escenario posible
  • wal_writer_flush_after=0, wal_writer_delay=1, wal_sync_method=open_datasync, etc.
  • se forzaron checkpoints cada 30 segundos y se mantuvieron min_wal_size/max_wal_size=32MB al mínimo
  • wal_level=logical, wal_log_hints=on, haciendo que incluso se registrara información innecesaria en WAL
  • también se activó carga adicional como track_wal_io_timing, summarize_wal
• Como resultado, el TPS cayó hasta 98 (menos de 1/70 del original)
• En los logs se observaron comportamientos anómalos, como checkpoints repitiéndose cada pocos cientos de ms

Eliminar el efecto de los índices

• Se configuró el uso de índices para que siempre se calculara con el costo máximo posible (random_page_cost=1e300, cpu_index_tuple_cost=1e300), invalidando de hecho los índices
• Se aumentó shared_buffers a 8MB (para asegurar estabilidad) y el TPS cayó hasta 0.87 (logrando una ralentización de 7,000 veces)

Forzar I/O de un solo hilo

• Se aprovecharon funciones recientes de Postgres 18+
• Con io_method=worker, io_workers=1, se forzó que todo el I/O pasara por un solo hilo worker
• El TPS cayó aún más, hasta 0.016 (42,000 veces más lento)
• En la prueba de 100 conexiones durante 120 segundos, el rendimiento quedó tan limitado que solo se completaron 11 transacciones

Conclusión y guía de reproducción

• Se demuestra que con solo 32 manipulaciones de parámetros es posible llevar una DB en producción prácticamente a un estado de "parálisis"
• Es posible maximizar la degradación del rendimiento tocando únicamente la configuración de postgresql.conf
• Quienes quieran reproducir el experimento deben consultar BenchBase Postgres, el entorno TPC-C indicado arriba y la lista completa de configuraciones
• No se incluyen algunos parámetros adicionales ni otros intentos extra por hacerlo aún más lento

Lista resumida de parámetros

• shared_buffers = 8MB
• umbrales/scale_factor relacionados con autovacuum: minimizados a 0~1
• costos, memoria y logs relacionados con vacuum: minimizados y maximizados según corresponda
• opciones de sync/flush/logging/nivel relacionadas con WAL: mantenidas en modo lento
• random_page_cost, cpu_index_tuple_cost de índices: establecidos en 1e300
• io_method = worker, io_workers = 1
• para otros valores detallados, consultar la lista del cuerpo principal

Cierre

• Solo con el archivo postgresql.conf se puede provocar una degradación de rendimiento extrema
• En la práctica, vale la pena tomar esta combinación como referencia en sentido inverso (para mejorar el rendimiento de forma eficiente)
• El artículo cierra mencionando que el autor interrumpió el experimento por dolor de espalda

[GN⁺]

Opiniones de Hacker News

• Presenta una forma de usar todos los datos en una sola tabla, como si fuera un KVS NoSQL SQL, al estilo de las primeras versiones de TRIRIGA, olvidándose por completo de cosas como índices, múltiples tablas, transacciones, relaciones entre entidades e integridad referencial
• Esto es tan divertido que dan ganas de que salga toda una serie de libros sobre "cómo empeorar más las cosas"; aprendiendo así uno puede encontrar mejores formas por contraste. Si fuera con estilo O’Reilly, la portada podría llevar un animal de fantasía mal dibujado (por ejemplo, un unicornio con cabeza en ambos lados, hablando por AirPods mientras le da dinero a un estafador, hace una presentación en PowerPoint, se da un atracón y consume drogas)
  • De hecho, hubo un caso real en la Segunda Guerra Mundial en que se usó una estrategia parecida: para aumentar la supervivencia de los pilotos, unos meteorólogos primero identificaron las condiciones que causaban más bajas y luego planificaban las misiones para evitarlas. Enlace de referencia: Suppose I wanted to kill a lot of pilots
  • En clases de escritura creativa también había ejercicios de leer y analizar textos mal escritos, o de reescribir adrede un buen texto de forma mala, y ese fue de los ejercicios de escritura más útiles
  • También sirve como referencia el sitio de parodias ORLYBooks sitio de parodias
• Sería buenísimo tener un sandbox de producción para experimentar con herramientas de observabilidad: un sistema estilo SaaS de tamaño razonable, con simulación de uso, y una configuración de postgres/rabbit más o menos normal para poner a prueba herramientas o estrategias de depuración
• La idea es realmente genial. Si quieres optimizar bien, quizá conviene primero arruinarlo por completo como punto de partida o grupo de control opuesto. Vale la pena preguntarse si de verdad uno trata las bases de datos o los sistemas de forma científica, o si solo sigue prácticas por inercia
  • Yo siempre hago eso cuando empiezo a usar un servicio en la nube: primero gasto Series A lo más rápido posible y después me pongo a optimizar costos cloud
• The Defence of Duffer's Drift es un ejemplo temprano de este género: en la primera historia destrozan la táctica de escuadrón y terminan perdiendo a la mayoría; en las siguientes, van cambiando las condiciones tácticas y los resultados mejoran poco a poco. Libros tácticos más recientes, como Musicians of Mars 2, usan el mismo enfoque. La primera historia de Team Badger se parece muchísimo a Duffer's Drift, pero adaptada según ubicación, equipo y tecnología. Los PDF relacionados pueden verse en The Defence of Duffer's Drift y Musicians of Mars 2. Resulta impactante cómo, tras una derrota aplastante, el comandante de Team Badger repasa por qué fue vencido de forma tan desastrosa pese a su confianza y preparación
  • En una línea similar, están películas como Groundhog Day y sobre todo Edge of Tomorrow; también vale la pena ver este homenaje moderno publicado recientemente en un blog militar británico: Defence Baltic Bridge Dreams
• Fue interesante la mención de los deadlocks; me pregunto si también habrá una parte sobre ajustar la configuración de los niveles de aislamiento de transacciones
• Me alegró ver la mención de B Sanderson
• Se siente como una combinación de Hyperbole and a Half con un db admin; me dejó de buen ánimo al leerlo y además aprendí algunas cosas
• El estilo de escritura y la forma de desarrollar las ideas fueron realmente excelentes; fue una lectura muy amena

[sonic0987]

Excelente. Me encanta este tipo de enfoque.