Reemplazamos mmap por io_uring en nuestro motor de consultas Rust y se volvió más lento

We Replaced MMAP with Io_uring in Our Rust Query Engine. It Got Slower

Reemplazamos mmap por io_uring en nuestro motor de consultas Rust y se volvió más lento

En Conviva, después de que mmap causara picos de latencia y fallos de página bajo cargas concurrentes, decidieron probar io_uring con O_DIRECT para evitar la caché de páginas. En Linux, la reducción de fallos mayores fue drástica, pero los fallos menores se multiplicaron por ocho y el tiempo total de consulta empeoró: de 13.6 a 21.8 segundos. El cuello de botella no era el disco, sino la contención de locks y la gestión de la caché.

El panorama: bajo carga, el thrashing de la caché de páginas y la contención de locks a nivel de kernel —no la E/S de disco— eran el cuello de botella.
  1. jandrewrogers

    Un problema aquí es que mmap e io_uring requieren arquitecturas de software fundamentalmente diferentes en un contexto de rendimiento. No deberías intercambiarlos.

    APIs como io_uring, combinadas con O_DIRECT, te permiten diseñar tu propio planificador de espacio de usuario específico para tu carga de trabajo desde los primeros principios. Si delegas la planificación en un runtime, entonces has renunciado a la mayoría de las ventajas de rendimiento que esas APIs fueron diseñadas para proporcionar. En muchos casos, el rendimiento será peor. Por el contrario, mmap delega implícitamente todas las decisiones de planificación y tiene algunas ventajas si la delegación es tu estrategia en comparación con un runtime.

    Los beneficios de io_uring son limitados sin un compromiso de diseñar tus propios planificadores. Como aspecto positivo, los diseñadores de planificadores expertos pueden aumentar el rendimiento por factores enteros sustanciales usando estas APIs en comparación con mmap. Diseñar planificadores específicos para la aplicación no es fácil, es un esfuerzo de alta cualificación. Pero la recompensa es real.

    Usar io_uring bien requiere apostar por completo por la arquitectura de software que requiere para mostrar lo que puede hacer.

  2. laserbeam

    El verdadero problema aquí es que hay una parte 2 (enlazada al final del artículo) donde consiguen que la implementación con io_uring sea el doble de rápida que mmap. Así que es un título clickbait para una parte 1, que se resuelve en la parte 2.

    Así que se sacaron de la manga 2 artículos, uno de los cuales es puro ragebait. Y ambos parecen escritos por un LLM. Quizá tengan algún consejo interesante, quizá no... pero no es un formato que disfrute leyendo.

  3. londons_explore

    Hay un patrón en la ingeniería de software que consiste en:

    * Existe un proyecto

    * Nuevos empleados proponen una idea para mejorar la eficiencia

    * Se pasan meses implementándola. El código antiguo se convierte en legacy.

    * Ahora se añaden características extra a lo nuevo durante el desarrollo.

    * La eficiencia de lo nuevo resulta ser peor que la original, pero ahora las nuevas características y la 'menos deuda técnica' son los motores.

    * Se lanza lo nuevo, se deprecia lo viejo, pero hay poco beneficio real para todos esos meses de trabajo.

Más de este día

2026-09-11