Ingeniero de AWS reporta que el rendimiento de PostgreSQL cae a la mitad en Linux 7.0; la corrección podría no ser sencilla

• En el kernel de desarrollo de Linux 7.0, ingenieros de Amazon/AWS detectaron una grave regresión de rendimiento en la que el throughput del servidor de bases de datos PostgreSQL cae a cerca de la mitad frente al kernel anterior
• Según mediciones en servidores Graviton4, Linux 7.0 ofrece solo aproximadamente 0.51 veces el throughput del kernel previo, y se determinó que la causa es que se consume mucho más tiempo en los spinlocks en espacio de usuario
• La regresión se debe a un cambio en Linux 7.0 que restringe el modo de preemption del kernel; se presentó un parche para restaurar PREEMPT_NONE como valor predeterminado, pero no está claro si será aceptado
• El autor original, Peter Zijlstra, señaló que en vez de modificar el kernel, PostgreSQL debería adaptarse para aprovechar la extensión de time slice de RSEQ (Restartable Sequences)
• La versión estable de Linux 7.0 está prevista para dentro de unas 2 semanas y también será el kernel base de Ubuntu 26.04 LTS, por lo que existe preocupación por una degradación amplia del rendimiento hasta que PostgreSQL se adapte

---

Detección del problema y magnitud

• El ingeniero de Amazon/AWS Salvatore Dipietro reportó una regresión en el throughput y la latencia de PostgreSQL
• En mediciones sobre servidores Graviton4, Linux 7.0 entrega solo 0.51 veces el throughput del kernel existente
  • Se confirmó que la causa es un consumo de tiempo mucho mayor en los spinlocks en espacio de usuario

Causa de la regresión: restricción del modo de preemption

• El resultado del bisecting identificó como causa el cambio que restringe el modo de preemption del kernel en Linux 7.0
• Ese cambio se realizó para mantener solo los modos Full y Lazy de preemption en arquitecturas de CPU modernas, y fue incluido como parte de la actualización del scheduler de Linux 7.0

Parche presentado y reacción de los mantenedores del kernel

• Debido a la gravedad de la regresión, se envió a la lista de correo del kernel de Linux un parche para restaurar PREEMPT_NONE como modo de preemption predeterminado
• Sin embargo, Peter Zijlstra, autor del código original, se mostró contrario a aceptar ese parche y afirmó que la solución es que PostgreSQL aproveche la extensión de time slice de RSEQ (Restartable Sequences)
  • La extensión de time slice de RSEQ también es una función incluida en Linux 7.0
  • Zijlstra explicó que "esto puede limitar la exposición a la preemption del lock holder"

Alcance del impacto y calendario de lanzamiento

• Si esa postura se mantiene, el rendimiento de PostgreSQL en algunos escenarios podría degradarse de forma considerable en la versión estable de Linux 7.0 hasta que PostgreSQL sea actualizado
• La versión estable de Linux 7.0 está prevista para dentro de unas 2 semanas
• Linux 7.0 será el kernel base de Ubuntu 26.04 LTS, por lo que Ubuntu 26.04 LTS, cuyo lanzamiento está previsto para finales de abril, también podría verse afectado

[unstabler]

Por lo que escuché, los desarrolladores del kernel les han estado diciendo a los desarrolladores de PostgreSQL desde hace casi 10-20 años: "los spinlocks en espacio de usuario no son recomendables, así que nos gustaría que lo reconsideraran"...

https://x.com/kosaki55tea/status/2040458791536497035

[GN⁺]

Comentarios en Hacker News

• Vale la pena leer la respuesta de seguimiento en LKML de Andres Freund, desarrollador de Postgres

  • Si el problema de rendimiento es una regresión reproducible, es extraño que la única solución sea desactivar funciones nuevas agregadas en 7.0
  • Más que una sola publicación, si se sigue todo el hilo hay información adicional importante
  • No es buena idea forzar funciones de bajo nivel introducidas en 7.0 para resolver una regresión que solo aparece en 7.0
    La opinión es que los mantenedores de Linux deberían dar prioridad de soporte a aplicaciones clave como PostgreSQL
    Esto recuerda un caso anterior en Fedora donde las actualizaciones se bloqueaban al instalar Wine
  • La solución de “usar hugepages” siempre se menciona, pero la mayoría de los usuarios la ignora
  • Solo en una máquina ARM64 de 96 núcleos el rendimiento cayó a 0.51x, y no se reprodujo en AMD64
    O sea, no es un problema que vayan a sufrir todos los usuarios de PostgreSQL al actualizar al kernel más reciente

• Hubo quien opinó que usar spinlock en espacio de usuario sin soporte del kernel es buscarse una caída de rendimiento

  • Yo también detesto el uso de spinlock en Postgres y lo estoy eliminando gradualmente
    Pero los locks basados en futex provocan regresiones de rendimiento por el aumento de memory barriers
    Además, Postgres todavía tiene que considerar plataformas que no soportan operaciones atómicas de 8 bytes, así que no es fácil reemplazarlo
    El spinlock en cuestión fue eliminado recientemente y, al usar huge pages, el cuello de botella casi desaparece
  • Se comparó usar spinlock en espacio de usuario con “darse martillazos en la cara”
  • También hubo quien dijo que PostgreSQL ha usado spinlock por mantener compatibilidad con kernels antiguos, pero que ya es hora de dejarlo atrás

• También apareció la afirmación de que “nadie usa el kernel más reciente en producción”
  En la práctica, Ubuntu 26.04 LTS saldrá pronto basado en Linux 7.0, así que muchos usuarios lo usarán pronto
  El problema actual es que no se resuelve con sysctl sino que requiere un parche del kernel

  • Aun así, tiene que haber gente probando kernels recientes para detectar este tipo de problemas temprano
  • Si PostgreSQL se ve afectado, es posible que otras aplicaciones también lo estén
  • También se señaló que en entornos Docker no hay opción, porque se comparte el kernel del host
  • Como referencia, la opción PREEMPT_NONE fue eliminada en la mayoría de las plataformas

• El contexto sobre PREEMPT_LAZY puede verse en este artículo de LWN

• Hubo un comentario en tono de broma preguntando si habían revisado si Jia Tan envió un parche reciente al kernel,
  y alguien respondió que “ni hace falta, ya sobran las vulnerabilidades”

• Hubo quien se preguntó si el I/O asíncrono y las optimizaciones de consultas paralelas de PostgreSQL 18 podrían compensar esta caída de rendimiento
  Los detalles relacionados pueden verse en las notas de lanzamiento de PostgreSQL 18

• También hubo dudas sobre por qué hacen falta modos de preempción dinámica como PREEMPT_LAZY
  La idea es que no está claro cuál es el beneficio para el usuario común

  • En respuesta, se explicó que es un diseño para aumentar el rendimiento sin incrementar la latencia
    Eso permite que el kernel reciba información más explícita y mejore las decisiones de planificación

• Alguien comentó que había medido una caída de rendimiento del 10% entre FreeBSD 14 y 15.0, y que este caso al menos le daba algo de consuelo

  • Luego vino la respuesta: “¿pero al menos agregaron suficientes funciones para justificarlo?”

• También hubo críticas a que Phoronix publicó la nota sin verificación suficiente
  En un correo posterior se concluyó que el benchmark en sí estaba mal y que en realidad no era un problema grave

  • Aun así, la regresión ocurre solo cuando no se usan huge pages
    Puede que no sea un gran problema para PostgreSQL, pero podría afectar a otras aplicaciones que no pueden usar huge pages
    Por eso, algunos opinan que no es algo que simplemente deba ignorarse

• También se compartió este enlace a un viejo hilo de LKML