El CPU al 100% que en realidad no está haciendo nada
Un motor de datos puede mostrar el CPU al 100% y aun así estar desperdiciando la mitad de su capacidad. El equipo de Pivot, el motor analítico de PivotLake, midió con contadores de hardware que en una consulta de agregación el 50,1% del tiempo el procesador no podía ejecutar ninguna instrucción porque estaba esperando a la memoria. Solo el 16,1% del tiempo estaba retirando operaciones de verdad.
Ese es el tipo de dato que cambia cómo piensas sobre el rendimiento de tu producto. Si tu dashboard tarda 4 segundos y el CPU marca 100%, la conclusión intuitiva es que necesitas más cómputo. La medición dice lo contrario: probablemente necesitas menos accesos a memoria.
¿Por qué un CPU al 100% puede no estar saturado?
Un CPU moderno no ejecuta código de forma lineal. Puede procesar varias instrucciones a la vez o ninguna, y el sistema operativo lo marca como "ocupado" simplemente porque hay una tarea que necesita tiempo de CPU. Eso no significa que el silicio esté trabajando.
¿Y esto cómo se aplica en tu negocio?
Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.
👥 Quiero el Kit →La brecha que explica todo es esta: un CPU moderno procesa del orden de 4 a 8 instrucciones por nanosegundo, mientras que un acceso a RAM tarda entre 50 y 100 nanosegundos. Traducido: el procesador podría ejecutar entre 400 y 800 instrucciones en el tiempo que tarda en traer un solo dato desde memoria.
Por eso los fabricantes construyen cachés dentro del propio chip. La caché L1 responde en torno a 1 nanosegundo, entre 50 y 100 veces más rápido que la RAM. El problema es el tamaño: la L1 de un CPU moderno ronda los 64 KB, y las cachés más lejanas llegan a unos pocos cientos de MB solo en los procesadores tope de gama. Todo el rendimiento de una base de datos se juega en qué tan bien aprovechas ese espacio diminuto.
El caso de GROUP BY: cómo un HashTable ingenuo destruye la caché
Una agregación GROUP BY agrupa un dataset por una o más columnas y calcula métricas como count o sum. El enfoque "ingenuo" es abrir un HashTable indexado por la clave de grupo y, por cada fila, buscar si la clave existe y actualizar el resultado.
Suena simple, pero si tienes millones de grupos únicos, casi cada acceso al HashTable es un fallo de caché que va directo a RAM. El CPU parece al 100%, pero en realidad está esperando.
Para demostrarlo, el equipo de Pivot despojó a su motor de toda la lógica compleja y lo reemplazó por la versión más simple posible. Corrieron SELECT count(*), UserID FROM hits GROUP BY UserID sobre el dataset "hits" de ClickBench, con 99 millones de filas y alrededor de 17 millones de UserID únicos.
El entorno de prueba fue un servidor bare metal de CherryServers con un AMD EPYC 9124 Genoa de 16 núcleos y 128 GB de DDR5. Usaron bare metal, y no una máquina de AWS o GCP, porque necesitaban contadores de hardware que las nubes no exponen por razones de seguridad. La consulta se fijó a un solo núcleo con taskset, ya que este GROUP BY ingenuo no puede paralelizarse.
El resultado: 3,9 segundos en la primera ejecución y 3,6 segundos en la segunda, con todo ya en page-cache y sin disco involucrado. Los contadores de perf stat mostraron el 50,1% de slots de CPU estancados por memoria y apenas 16,1% retirando operaciones. En cargas desde DRAM, el contador ls_dmnd_fills_from_sys.dram_io_near registró 76.190.837 accesos. Como cada carga trae 64 bytes (una línea de caché), eso equivale a 4,5 GB traídos desde RAM durante una sola consulta.
Radix partitioning: hacer más trabajo para tardar menos
La solución que probó Pivot se llama radix partitioning y divide el proceso en dos fases. En la primera, cada fila se separa en una de 4096 particiones según los 12 bits más altos del hash de la clave. En la segunda, se procesa partición por partición, construyendo un HashTable pequeño para cada una y volcando el resultado.
A primera vista parece un contrasentido: se hacen más operaciones, no menos. Cada fila se hashea y se envía a un HashMap igual que antes, pero además pasa por un vector intermedio. La clave es que los HashTables de trabajo ahora son mucho más pequeños y tienen muchas más probabilidades de caber en las cachés del CPU.
Los números respaldan el enfoque. La consulta bajó a 3,3 segundos y luego a 2,7 segundos en la segunda ejecución. Los contadores cambiaron de forma drástica: el tiempo estancado por memoria cayó del 50,1% al 23,5%, y el tiempo retirando operaciones subió del 16,1% al 32,2%.
El detalle más interesante es que el motor ejecutó 19.350.459.182 operaciones, frente a las 11.431.618.219 de la versión ingenua. Hizo más trabajo y terminó antes, porque cambió accesos fríos a DRAM por instrucciones de CPU. Los slots de CPU estancados por memoria bajaron de 8.364.109.137 a 3.790.955.223, y los accesos a DRAM cayeron a 25.688.280, es decir 1,5 GB en lugar de 4,5 GB.
Como referencia del techo alcanzable, el motor Pivot completo resolvió la misma consulta en un solo núcleo en 1.848 milisegundos, trayendo 954 MB desde DRAM, y en 171 milisegundos al paralelizar sobre los 16 núcleos.
¿Qué significa esto para tu startup?
Si construyes producto sobre una base de datos, este experimento tiene consecuencias directas en tus decisiones de arquitectura y de costos.
- Deja de escalar por CPU antes de medir. Un dashboard lento con el CPU al 100% suele ser un problema de acceso a memoria, no de cómputo. Antes de subir de instancia, corre
perf statcon las métricasbackend_bound_memoryyretiringen tu servidor. Si el porcentaje estancado por memoria es alto, más núcleos no te van a salvar. - Revisa cómo agregas datos. Si tu código hace
GROUP BYsobre columnas con millones de valores únicos usando un solo HashTable global, estás condenado a fallos de caché. Particionar por hash antes de agregar es una técnica trasladable a cualquier stack, no solo a motores escritos en Rust. - Cuestiona el costo de la nube por este motivo. Las instancias con más RAM no siempre resuelven la latencia: el problema es la distancia entre el CPU y el dato, no la cantidad de memoria disponible. Un algoritmo consciente de la caché puede rendir más en una máquina más barata.
- Mide en bare metal cuando necesites certeza. Si tu equipo de datos tiene que justificar una decisión de infraestructura, los contadores de hardware son la evidencia más difícil de discutir. Vale la pena tener acceso a un servidor dedicado para pruebas puntuales.
La lección de fondo es que el rendimiento de datos se decide en los detalles de acceso a memoria, y que a veces la optimización correcta consiste en hacer más operaciones para esperar menos. Para un founder, eso se traduce en una pregunta concreta: ¿estás midiendo lo que tu sistema realmente hace, o solo mirando el porcentaje de CPU?
No se encontraron datos adicionales verificables sobre Pivot o PivotLake en fuentes periodísticas durante esta investigación; el análisis se apoya en la publicación técnica original del equipo.
Fuentes
¿Y esto cómo se aplica en tu negocio?
Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.
👥 Quiero el Kit →
