Conviva, una empresa de análisis de eventos a gran escala, documentó la transición de su motor de consultas Rust de mmap a io_uring tras identificar un cuello de botella crítico en la producción. El sistema, basado en DataFusion y Arrow, procesa trillones de eventos diarios leyendo archivos Arrow IPC de 3 a 5 GB desde discos NVMe. Aunque mmap ofrecía lecturas sin copia de memoria (zero-copy) en cargas ligeras, bajo alta concurrencia el rendimiento se degradó severamente: las latencias p95 aumentaron de 30 a más de 150 segundos y el escaneo de filas por núcleo cayó drásticamente.
La investigación reveló que el problema no era la latencia del disco, sino el thrashing de la caché de páginas del sistema operativo. Al compartir la caché de páginas entre múltiples pods en el mismo host, la presión de memoria provocó una tormenta de fallos de página (page faults) y una intensa contención de bloqueos en el kernel. En pruebas controladas, un solo pod fue un 41% más rápido que cuatro pods, confirmando que la competencia por la caché compartida era el limitador. El análisis de rendimiento mostró que el 78% del tiempo de CPU en ejecuciones frías se consumía en funciones del kernel como __filemap_add_folio, reduciendo el tiempo de procesamiento de la consulta al 5% frente al 45% en ejecuciones cálidas. Además, se registraron más de 2 millones de context switches por segundo, en comparación con 14.000 en condiciones óptimas.
El hardware, con 32 discos NVMe en RAID-0, era capaz de alcanzar 21 GB/s, pero mmap solo logró 3.44 GB/s, aprovechando apenas el 16% de la capacidad. Ante esto, Conviva adoptó io_uring, que permite E/S asíncrona y directa, evitando la gestión de la caché de páginas del kernel y eliminando la contención de bloqueos asociada a mmap.