¿Qué tamaño de pool de conexiones en relación con los núcleos de CPU han adoptado los equipos en un servidor PostgreSQL y qué medición los llevó a cambiarlo?

Pregunta abierta

La documentación de PostgreSQL describe max_connections como el número máximo de conexiones simultáneas al servidor, con un valor por defecto que suele ser 100. La página de la wiki de PostgreSQL sobre el número de conexiones a la base de datos ofrece una regla empírica para obtener el rendimiento óptimo: situar el número de conexiones activas cerca del doble del número de núcleos más el número efectivo de discos (spindles). Además, sostiene que tener más conexiones que eso reduce el rendimiento en lugar de aumentarlo. Entre ambos elementos está el pool: un pool dentro del proceso de cada instancia de la aplicación, un pooler externo como PgBouncer, o ambos. El tamaño del pool es el número que los equipos realmente ajustan.

La wiki no recoge en qué valor termina ese número cuando un equipo lo ha ajustado con una carga de trabajo real. ¿Los equipos acaban cerca de la fórmula, o un orden de magnitud por encima porque cada una de las veinte instancias de la aplicación exige su propio pool de diez conexiones? Cuando se redujo el pool, ¿qué ocurrió con la latencia en la aplicación? ¿Las peticiones se encolaron en el pool y expiraron, o la base de datos se volvió más rápida porque menos transacciones competían por bloqueos y CPU? Cuando se aumentó, ¿mejoró algo, o el cambio solo trasladó la espera del pool a la base de datos? ¿Qué medición fue decisiva: el tiempo de espera en el pool, los estados de pg_stat_activity, las esperas por bloqueos, la saturación de CPU en el host de la base de datos o un percentil de latencia en el borde? ¿Y cambia la respuesta entre transacciones OLTP cortas, consultas analíticas largas y cargas con sesiones en estado idle in transaction?

La pregunta importa porque la fórmula se cita mucho y se comprueba poco, y porque el tamaño del pool interactúa con el número de instancias, la duración de las transacciones y el modo del propio pooler de maneras que una regla empírica no puede recoger.

Qué contiene una respuesta útil

El número de núcleos y el almacenamiento del host de la base de datos, el número de instancias de la aplicación, el pooler y su modo (sesión, transacción) y las características de la carga (distribución de la duración de las transacciones, proporción de tiempo en idle in transaction). El tamaño del pool antes y después de cada cambio, con la fecha. La medición que desencadenó el cambio y la que sirvió para evaluarlo: tiempo de espera en el pool y sus percentiles, CPU de la base de datos, número de esperas por bloqueos, percentiles de latencia de las peticiones y tasas de error por agotamiento del pool. Si también se modificó max_connections. Son útiles tanto los informes en los que la fórmula se cumplió como aquellos en los que quedó muy lejos, y también los que concluyen que el tamaño del pool importaba menos que la duración de las transacciones, siempre que las cifras se indiquen con su fuente y el periodo observado.