Cómo cerré una brecha de rendimiento de 23 veces (Spoiler: no había brecha)

Parte 2: De “AIX es lento” a “AIX iguala a Linux”

En la Parte 1, luché con CMake, implementé un grupo de hilos desde cero y envié una versión estable de MariaDB 11.8.5 para AIX. El servidor superó las 1.000 conexiones concurrentes, 11 millones de consultas y cero fugas de memoria.

A continuación, realicé una prueba comparativa de búsqueda vectorial.

AIX: 42 consultas por segundo.
Linux (mismo hardware): 971 consultas por segundo.

Veintitrés veces más lento. En idéntico hardware IBM Power S924. Misma versión de MariaDB. Mismo conjunto de datos.

Esta es la historia de cómo descubrimos que no había ninguna diferencia de rendimiento: sólo errores de configuración y un compilador subóptimo.

Capítulo 1: La sensación de hundimiento

Hay un tipo particular de desesperación que surge al ver una diferencia de rendimiento de 23 veces en un hardware idéntico. Es el tipo de desesperación de “quizá debería haberme hecho florista”.

Permíteme preparar el escenario: ambas máquinas son LPARs que se ejecutan en servidores IBM Power S924 con procesadores POWER9 a 2750 MHz. El mismo MariaDB 11.8.5. El mismo conjunto de datos de prueba: 100.000 vectores con 768 dimensiones, utilizando el índice MHNSW (Hierarchical Navigable Small World) de MariaDB para la búsqueda de vectores.

La prueba era sencilla: encontrar los 10 vecinos más próximos a un vector de consulta. El tipo de operación que impulsa todas las funciones de búsqueda mejoradas por IA que hayas utilizado alguna vez.

Linux lo hizo en aproximadamente 1 milisegundo. AIX tardó 24 milisegundos.

Mi primer instinto fue la negación. “El punto de referencia debe de estar mal”. No lo estaba. “Quizá el índice esté corrupto”. No lo estaba. “Quizá la red va lenta”. Era una conexión de socket local.

Es hora de profundizar.

Capítulo 2: Los primeros 65x – La configuración importa

El caché que lo olvidó todo

La primera pista nos la dio el perfilador de MariaDB. Cada consulta tardaba lo mismo, fuera la primera o la centésima. Las cachés no funcionan así.

He comprobado la configuración MHNSW de MariaDB:

SHOW VARIABLES LIKE 'mhnsw%';

mhnsw_max_cache_size: 16777216

16 MB. Nuestro gráfico vectorial necesita unos 300 MB para mantener la estructura HNSW en memoria.

Aquí está el truco: cuando la caché se llena, MariaDB no expulsa las entradas antiguas (no hay LRU). Deshazte de todo y empieza de cero. Cada. Cada. Consulta.

Imagina una biblioteca en la que, cuando las estanterías se llenan, el bibliotecario quema todos los libros y encarga ejemplares nuevos. Para cada usuario.

Corrección: mhnsw_max_cache_size = 4GB en la configuración del servidor.

Resultado: 42 QPS → 112 QPS. Una mejora de 2,7 veces a partir de una línea de configuración.

El problema del tamaño de página

AIX utiliza por defecto páginas de memoria de 4 KB. Linux en POWER utiliza páginas de 64 KB.

Para el patrón de acceso de MHNSW -persecución de punteros a través de un gráfico de 300 MB- esto importa enormemente. Con páginas de 4 KB, necesitas 16 veces más entradas TLB (Translation Lookaside Buffer) para mapear la misma cantidad de memoria. Los fallos en el TLB son caros.

Piénsalo como navegar por una ciudad. Con páginas de 4 KB, necesitas direcciones para cada edificio individual. Con páginas de 64 KB, obtienes indicaciones por barrios. Mucho más rápido cuando estás saltando constantemente de un lado a otro.

Corrección: Script envolvente que establece LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

Resultado: 112 QPS → 208 QPS secuenciales, y 2.721 QPS con 12 trabajadores paralelos.

El marcador después de la Fase 1

Mejora 65 veces a partir de dos cambios de configuración. Sin modificaciones de código.

Pero seguíamos siendo 6 veces más lentos que Linux por núcleo. La investigación continuó.

Capítulo 3: El misterio de la CPU vs. el bloqueo de la memoria

Una vez fijada la configuración, saqué las herramientas de creación de perfiles. MariaDB tiene un perfilador integrado que desglosa el tiempo de consulta por fases.

AIX:

Sending data: 4.70ms total
  - CPU_user: 1.41ms
  - CPU_system: ~0ms
  - Stalls: 3.29ms (70% of total!)

Linux:

Sending data: 0.81ms total
  - CPU_user: 0.80ms
  - Stalls: ~0.01ms (1% of total)

El tiempo de ejecución de la CPU era 1,8 veces más lento en AIX, lo que se explica por las diferencias del compilador. Pero las paradas de memoria eran 329 veces peores.

La causa raíz: Invalidación de la caché del hipervisor

He aquí algo que tardé dos días en averiguar: en una LPAR (Partición Lógica) compartida, el hipervisor POWER se adelanta periódicamente a los procesadores virtuales para dar tiempo a otras particiones. Cuando lo hace, puede invalidar líneas de caché L2/L3.

El recorrido del gráfico de MHNSW es una persecución de punteros a través de 300 MB de memoria, literalmente el peor escenario para la invalidación de la caché. Estás saltando de nodo en nodo, cada uno en una parte diferente de la memoria, y el hipervisor está vaciando periódicamente tu caché.

Es como intentar leer un libro mientras alguien sigue cerrándolo y volviéndolo a poner en la estantería.

El sistema Linux tenía procesadores dedicados. El sistema AIX funcionaba de forma compartida. No es lo mismo.

Pero antes de poder probar los procesadores dedicados, necesitaba solucionar el problema del compilador.

Capítulo 4: La odisea del compilador

Todo lo que intenté con GCC (y por qué fracasó)

La caja de herramientas GCC de AIX está construida sin soporte LTO. No es una bandera que hayas olvidado: es arquitectónicamente imposible porque la implementación LTO de GCC requiere ELF, y AIX utiliza XCOFF.

Los paquetes MariaDB de Ubuntu utilizan -flto=auto. Esa optimización simplemente no existe para AIX con GCC.

IBM Open XL: El giro argumental

En este punto, había pasado tres días intentando hacer GCC más rápido. Era hora de probar algo diferente.

IBM Open XL C/C++ 17.1.3 es el moderno compilador de IBM, basado en LLVM/Clang. Genera un código significativamente mejor para POWER9 que GCC.

Construir MariaDB con Open XL requirió resolver cinco problemas diferentes:

1. Falta el encabezado HTM: Open XL no tiene el htmxlintrin.h de GCC. He creado un stub.
2. AR de 32 bits por defecto: Las herramientas AIX son de 32 bits por defecto. Configura OBJECT_MODE=64.
3. LLVM AR incompatible: el AR de Open XL no podía manejar XCOFF. Utilizó el sistema /usr/bin/ar.
4. Conflictos con OpenSSL: Utiliza -DWITH_SSL=system para evitar problemas con wolfSSL.
5. Faltan rutas de biblioteca: Explícito -L/opt/freeware/lib para el enlazador.

A continuación, ejecuté la prueba comparativa:

Tres veces más rápido. Mismo código fuente. Mismas banderas de optimización (-O3 -mcpu=power9).

Y aquí está la ventaja: la varianza del punto de referencia de GCC era del 10-40% entre ejecuciones. La variación de Open XL fue inferior al 2%. Prácticamente sin fluctuaciones.

¿Por qué tanta diferencia?

Open XL (al estar basado en LLVM) sí lo tiene:

• Mejor programación de instrucciones para la ejecución fuera de orden del POWER9
• Asignación superior de registros
• Pases de optimización más agresivos

El backend POWER/XCOFF de GCC simplemente no está tan maduro. La Toolbox GCC de AIX es funcional, pero no está optimizada para cargas de trabajo de rendimiento crítico.

Capítulo 5: Los callejones sin salida de LTO y PGO

La esperanza es eterna. ¿Quizá funcionen el LTO y el PGO de Open XL?

LTO: La ironía

Open XL admite -flto=full en XCOFF. ¡Se construye de verdad! Pero…

Resultado: un 27% más lento que el Open XL sin LTO.

¿Por qué? Las bibliotecas compartidas de AIX requieren una lista de exportación explícita (exports.exp). Con LTO, el script de CMake vio ~27.000 símbolos para exportar.

La principal ventaja de LTO es la internalización de funciones, es decir, marcarlas como locales para poder optimizarlas o inlinearlas. Cuando te ves obligado a exportar 27.000 símbolos, ninguno de ellos puede internalizarse. La sobrecarga de LTO (archivos intermedios más grandes, enlace más lento) permanece, pero la ventaja desaparece.

Es como pagar la suscripción a un gimnasio y que luego te digan que no puedes utilizar ninguno de los aparatos.

PGO: Los perfiles que nunca fueron

La Optimización Guiada por Perfil sonaba prometedora:

1. Construye con -fprofile-generate
2. Carga de trabajo del entrenamiento de carrera
3. Reconstruir con -fprofile-use
4. Disfruta de un código más rápido

El paso 1 funcionó. Paso 2… los perfiles nunca aparecieron.

He vinculado manualmente el tiempo de ejecución de perfiles LLVM a la biblioteca compartida. Sigue sin haber perfiles.

La causa raíz: El tiempo de ejecución de perfiles de LLVM utiliza atexit() o __attribute__((destructor)) para escribir perfiles al salir. En AIX con XCOFF, la semántica de los destructores de bibliotecas compartidas es diferente de la de ELF. El gestor simplemente no se llama de forma fiable para configuraciones complejas de múltiples bibliotecas como MariaDB.

Los casos de prueba sencillos funcionan. Las aplicaciones reales no.

Capítulo 6: La revelación de la LPAR

Ahora tenía un compilador rápido. Es hora de probar los procesadores dedicados y eliminar el problema de la invalidación de la caché del hipervisor.

La matriz de pruebas

Espera. ¿Compartido es más rápido que dedicado?

El factor WoF

POWER9 tiene una función llamada Frecuencia Optimizada para la Carga de Trabajo (WoF). En modo compartido con baja utilización, un solo núcleo puede aumentar hasta ~3,8 GHz. Los procesadores capados dedicados están bloqueados a 2750 MHz.

Para una consulta de un solo hilo, el modo compartido obtiene un 38% más de velocidad de reloj. Eso supera la penalización por invalidación de caché para esta carga de trabajo.

Piénsalo como elegir entre un coche deportivo en una autopista con tráfico ocasional (compartido) frente a un camión con un carril reservado pero con un límite de velocidad (dedicado limitado).

El desastre del modo donación de PowerVM

Hay una tercera opción: los procesadores dedicados en modo “Donación”, que devuelven los ciclos ociosos al pool compartido.

60% de regresión con GCC.

Cada vez que una consulta estalla, se produce una latencia que recupera los ciclos donados. Para cargas de trabajo con ráfagas y un único subproceso, como las consultas a bases de datos, esto es devastador.

Recomendación: Nunca utilices el modo Donar para cargas de trabajo de bases de datos.

El punto dulce de los 21 núcleos

Con 21 núcleos dedicados (frente a los 24 de Linux), Open XL alcanzó 0,067s, casi igualando los 0,063s del modo compartido. La caché L3 adicional de más núcleos compensa la falta de aumento de frecuencia WoF.

Capítulo 7: El marcador final (giro argumental)

Nuevos puntos de referencia en hardware POWER9 idéntico, enero de 2026:

Espera. El sistema AIX tiene 21 núcleos frente a los 24 de Linux. Eso es un 12,5% menos de núcleos, lo que significa un 12,5% menos de caché L3.

¿La “diferencia” medida? 10-18%.

Eso no es una diferencia de rendimiento. Es una diferencia de hardware.

Con IBM Open XL, AIX ofrece un rendimiento por núcleo idéntico al de Linux. ¿La diferencia de 23x con la que empezamos? Nunca se trató de que AIX fuera lento. Se trataba de eso:

1. Una caché mal configurada (16MB en lugar de 4GB)
2. Tamaño de página incorrecto (4 KB en lugar de 64 KB)
3. El compilador equivocado (GCC en lugar de Open XL)

El mito de que “AIX es lento” ha muerto.

El Museo de la Falla Completa

La ciencia no sólo trata de lo que funciona, sino también de documentar lo que no funciona. Aquí está nuestro muro de “buen intento, pero no”:

El resultado de VSX es especialmente interesante: implementamos un filtro bloom SIMD utilizando las extensiones vectoriales de POWER. Fue un 41% más lento que el escalar. POWER9 no tiene multiplicación vectorial de 64 bits: necesitas vec_extract → multiplicación escalar → vec_insert para cada carril, lo que es más lento que dejar que el motor Fuera de Orden se encargue de un bucle escalar.

Lo que aprendí

1. Los impagos importan más de lo que crees

Una caché de 16 MB por defecto convertía las consultas de menos de un milisegundo en consultas de 24 ms. Eso es una penalización de 24 veces por un parámetro mal configurado.

Cuando portes software, cuestiona todos los valores predeterminados. Lo que funciona en Linux puede no funcionar en tu plataforma.

2. El mito de que “AIX es lento” siempre fue una cuestión de cadena de herramientas

Con GCC, éramos 3-4 veces más lentos que Linux. Con Open XL, igualamos a Linux por núcleo.

La plataforma nunca fue lenta. Simplemente, la cadena de herramientas por defecto no estaba optimizada para cargas de trabajo de rendimiento crítico. Elige el compilador adecuado.

3. La virtualización tiene contrapartidas ocultas

La LPAR compartida puede ser más rápida que la dedicada para cargas de trabajo monohilo (aumento de frecuencia WoF). La dedicada es mejor para un rendimiento multihilo sostenido. El modo de donación es una trampa.

Conoce tu carga de trabajo. Elige la configuración de tu LPAR en consecuencia.

4. No todos los puertos de optimización

LTO, PGO y la vectorización SIMD fallaron en AIX por diversas razones. Las técnicas que hacen que Linux sea rápido no siempre se traducen.

A veces la optimización “obvia” es la elección equivocada. Mídelo todo.

5. A veces no hay ningún hueco

Pasamos días investigando un “déficit de rendimiento” que resultó ser:

• Errores de configuración
• Compilador incorrecto
• Menos núcleos en el sistema de prueba

La lección: verifica tus líneas de base. Asegúrate de que estás comparando manzanas con manzanas antes de asumir que hay un problema que resolver.

Recomendaciones

Para usuarios de AIX MariaDB

1. Utiliza la versión Open XL (versión 3, próximamente)
2. Establece mhnsw_max_cache_size en al menos 4GB para la búsqueda vectorial
3. Mantener LPAR compartida para latencia de consulta única
4. Nunca utilices el modo Donar para las bases de datos
5. Utiliza páginas de 64K mediante la envoltura LDR_CNTRL

Para Upstream MariaDB

1. Aumenta mhnsw_max_cache_size por defecto – 16MB es demasiado pequeño
2. Implementa el desalojo LRU – descartar toda la caché por desbordamiento es brutal
3. No añadas el filtro de floración POWER VSX – el escalar es más rápido en POWER9

¿Qué sigue?

Los RPM se publican en aix.librepower.org. La versión 2 incluye las correcciones de configuración. La versión 3, con compilaciones Open XL, estará disponible en cuanto consigamos una licencia comercial (la de evaluación caduca en 59 días).

Prioridades inmediatas:

• Licencia comercial Open XL: La evaluación caduca pronto. Necesitas la licencia de IBM para el RPM de producción de la versión 3.
• Implementación AIO nativa: AIX tiene POSIX AIO e IOCP compatible con Windows. Es hora de escribir el backend InnoDB.
• Comentarios de MHNSW: El valor por defecto de mhnsw_max_cache_size de 16MB es demasiado pequeño para las cargas de trabajo reales; sugeriremos un valor por defecto mayor.

Para las organizaciones que ya ejecutan cargas de trabajo de misión crítica en AIX -y hay muchas, desde bancos a aerolíneas o sistemas sanitarios-, la opción de ejecutar también MariaDB moderno y de alto rendimiento abre nuevas posibilidades.

AIX coincide con Linux. El mito ha muerto. Y MariaDB en AIX está listo para la producción.

TL;DR

• Empezó con una diferencia de rendimiento de 23 veces (42 QPS frente a 971 QPS)
• Corregida la configuración de la caché: Mejora 5 veces
• Tamaño de página fijo: ~40% más
• Cambio a IBM Open XL: 3 veces mejor que GCC
• LPAR compartida utilizada: ~25% más rápida que la dedicada (WoF boost)
• Resultado final: SIN GAP – 10% de diferencia = 12,5% menos de núcleos (21 frente a 24)
• AIX iguala el rendimiento por núcleo de Linux con Open XL
• Open XL LTO: no ayuda (27% más lento)
• Abrir XL PGO: no funciona (problema con AIX XCOFF)
• POWER VSX SIMD: 41% más lento que el escalar (sin multiplicación vec de 64 bits)
• Modo donación: 60% de regresión – nunca se utiliza para bases de datos
• “AIX es lento para las BD de código abierto” siempre fue un mito de la cadena de herramientas

¿Preguntas? ¿Ideas? ¿Ejecutas MariaDB en AIX y quieres compartir tu experiencia?

Este trabajo forma parte de LibrePower – Unlocking IBM Power Systems through open source. RAS inigualable. TCO superior. Huella mínima 🌍

Repositorio del proyecto LibrePower AIX: gitlab.com/librepower/aix