- Postgres 18, actualmente en beta1, incorpora soporte para I/O asíncrona (Asynchronous I/O), mejorando de forma importante el rendimiento de lectura en entornos de nube
- Con el nuevo parámetro
io_method, se puede elegir además del método sync tradicional, los modos worker e io_uring
- Según benchmarks en AWS, con
io_uring el rendimiento de lectura desde disco mejora hasta 3 veces
- Sin embargo, con la asincronía también se vuelve más difícil interpretar los tiempos de I/O en el análisis de consultas existente (
EXPLAIN ANALYZE)
- Se requiere optimización de rendimiento mediante la nueva vista de monitoreo (
pg_aios) y el parámetro de ajuste effective_io_concurrency
Incorporación de I/O asíncrona en Postgres 18
- Tradicionalmente, Postgres ha usado un modelo de I/O bloqueante, esperando a que cada lectura de disco termine
- La alta latencia en almacenamiento basado en red (como EBS) provoca cuellos de botella en entornos de nube
- La I/O asíncrona permite procesar varias lecturas de disco en paralelo, elevando el uso de CPU y el throughput total
Trabajo previo en Postgres 17: Read Stream API
- En Postgres 17 se introdujo la API
read_stream para estandarizar la abstracción de las operaciones de lectura
- Pero seguía dependiendo del caché de páginas del SO y no se reflejaba directamente en el shared buffer de Postgres
- En Postgres 18 ahora es posible hacer lecturas asíncronas directas, no solo sugerencias al kernel
Nueva configuración: io_method
- Postgres 18 agrega la configuración
io_method en postgresql.conf, con estas 3 opciones:
io_method = sync
- El mismo método síncrono de Postgres de siempre
- Usa un mecanismo de solicitud anticipada de lectura basado en
posix_fadvise()
io_method = worker (predeterminado)
- Un proceso worker dedicado a I/O lee datos de forma asíncrona y los entrega al shared buffer
- El proceso principal puede seguir ejecutándose sin interrumpirse por las lecturas
- El número predeterminado de workers es 3 y puede ajustarse con
io_workers
io_method = io_uring
- Una interfaz de I/O de alto rendimiento disponible en Linux kernel 5.1 o superior
- Realiza lecturas asíncronas directamente mediante un ring buffer compartido con el kernel, sin procesos worker
- Requiere kernel, sistema de archivos y configuración modernos
Benchmark de rendimiento de la I/O asíncrona (según AWS)
- Entorno de prueba:
- AWS c7i.8xlarge (32 vCPU, 64GB RAM)
- EBS io2 de 100GB, 20,000 IOPS
- Ejecución de
SELECT COUNT(*) sobre una tabla de 3.5GB
Comparación de rendimiento con caché fría:
| Versión/configuración |
Tiempo de ejecución (ms) |
| Postgres 17 (sync) |
15,831 |
| Postgres 18 (sync) |
15,071 |
| Postgres 18 (worker) |
10,052 |
| Postgres 18 (io_uring) |
5,723 |
io_uring ofrece una mejora de rendimiento de 2.8 veces frente a sync- Es especialmente eficaz para minimizar la latencia de disco en la nube
Ajuste de effective_io_concurrency
- En Postgres 18, este parámetro influye en la cantidad interna de solicitudes asíncronas de read-ahead
- Su valor predeterminado subió de 1 a 16, y junto con
io_combine_limit determina el rango máximo de lectura
- En entornos de nube con alta latencia, un valor grande puede ser favorable, pero se necesitan benchmarks según la carga de trabajo
Nueva herramienta de monitoreo: pg_aios
- En
pg_stat_activity, durante operaciones asíncronas aparece el evento AioIoCompletion, lo que dificulta analizar la espera del backend
- En el caso de
io_uring, como el kernel procesa directamente la I/O, el estado no es visible desde Postgres
- La vista
pg_aios permite consultar información detallada de las solicitudes asíncronas en curso
SELECT * FROM pg_aios;
- Permite ver estados como
SUBMITTED, COMPLETED_IO y la información del bloque objetivo
Precaución: cambio en la interpretación de la información de tiempos de I/O
- Los
I/O Timings que se veían en EXPLAIN ANALYZE solo son confiables en el modo síncrono
- Al usar
worker o io_uring con asincronía, la ejecución en paralelo y la distribución entre workers distorsionan la interpretación de los tiempos
- Para evaluar el esfuerzo real de I/O, se recomienda usar la cantidad de buffers
shared read y pg_aios
Conclusión
- Postgres 18 aporta una mejora real al rendimiento de cargas de trabajo centradas en lectura
- En particular, puede ofrecer grandes ventajas al usar discos de alta latencia en entornos de nube
- Al mismo tiempo, exige reaprender cómo interpretar métricas de observabilidad, hacer tuning y aplicar la configuración
- Para Postgres 19 también se espera soporte para escritura asíncrona
2 comentarios
Postgres de verdad es lo máximo, genial
Comentarios en Hacker News
preadv2(..., RWF_NOWAIT)para realizar lecturas asíncronas desde la caché de páginas. Esto podría ser útil para reducir la latencia conio_method = workerNOWAITen el hilo principal y delegarla a un hilo de trabajo solo si fallaaio(4)de FreeBSD, y sería interesante ver cómo funciona dado que no tiene las desventajas deaiode Linux/glibcio_uring, y se pregunta si muchos administradores o distribuciones de Linux lo están deshabilitandoVACUUM ANALYZEconpgcronpgbouncer