Portar MariaDB a IBM AIX: 3 semanas sufriendo que merecieron mucho la pena

Parte 1: Llevando MariaDB a la plataforma que alimenta los sistemas más críticos del mundo

Hay decisiones en la vida que tomas sabiendo perfectamente que te causarán algún dolor. Casarte. Tener hijos. Correr una maratón. Portar MariaDB 11.8 a IBM AIX.

Esta es la historia de la última, y por qué volvería a hacerlo sin dudarlo.

Capítulo 1: “¿Tan difícil puede ser?”

Todo empezó con una pregunta inocente durante una reunión de equipo: “¿Por qué no tenemos MariaDB en nuestros sistemas AIX?”.

Esto es lo que pasa con AIX que la gente que nunca ha trabajado con él no entiende: AIX no se anda con chiquitas. Cuando los bancos necesitan un tiempo de actividad de cinco nueves para sus sistemas bancarios centrales, utilizan AIX. Cuando las aerolíneas necesitan sistemas de reservas que no puedan fallar, utilizan AIX. Cuando Oracle, Informix o DB2 necesitan ofrecer un rendimiento absolutamente brutal para cargas de trabajo OLTP de misión crítica, funcionan con AIX.

AIX no está de moda. AIX no tiene una mascota guay. AIX no será el tema de los blogs tecnológicos sobre “disrupción”. Pero cuando las cosas no pueden fallar en absoluto, AIX está ahí, haciendo tranquilamente su trabajo mientras todos los demás están ocupados reiniciando sus contenedores.

Entonces, ¿por qué MariaDB no es compatible oficialmente con AIX? Economía sencilla: la comunidad de código abierto se ha centrado en Linux, y la portabilidad requiere conocimientos específicos de la plataforma. MariaDB es compatible oficialmente con Linux, Windows, FreeBSD, macOS y Solaris. AIX no está en la lista, no porque sea una mala plataforma, sino porque nadie ha hecho el trabajo todavía.

En LibrePower, eso es exactamente lo que hacemos.

Mi primer error fue decir en voz alta “Probablemente sólo sea cuestión de compilarlo y ajustar algunas cosas”.

Lección nº 1: Cuando alguien dice “simplemente compílalo” sobre software en AIX, está a punto de aprender mucho sobre programación de sistemas.

Capítulo 2: CMake y los tres invitados inesperados

El primer día de compilación fue… educativo. CMake en AIX es como jugar a las cartas con alguien que tiene una comprensión muy diferente de las reglas, y espera que las descubras por ti mismo.

El fallo de la función fantasma

AIX tiene una característica interesante: declara funciones en las cabeceras por compatibilidad, incluso cuando esas funciones no existen realmente en tiempo de ejecución. Es como si tu GPS te dijera “gira a la derecha en 200 metros” pero la calle fuera un muro de ladrillo.

CMake hace un CHECK_C_SOURCE_COMPILES para comprobar si pthread_threadid_np() existe. El código se compila. CMake dice “¡genial, ya lo tenemos!”. El binario se inicia y… BOOM. Símbolo no encontrado.

Resulta que pthread_threadid_np() es sólo para macOS. AIX lo declara en las cabeceras porque… bueno, aún no estoy del todo seguro. ¿Quizá por alguna razón de compatibilidad con POSIX que tenía sentido hace décadas? Sea cual sea la razón, GCC lo compila felizmente, y el enlazador no se queja hasta el tiempo de ejecución.

Lo mismo ocurre con getthrid(), que es específico de OpenBSD.

La solución:

IF(NOT CMAKE_SYSTEM_NAME MATCHES "AIX")
  CHECK_C_SOURCE_COMPILES("..." HAVE_PTHREAD_THREADID_NP)
ELSE()
  SET(HAVE_PTHREAD_THREADID_NP 0)  # Trust but verify... okay, just verify
ENDIF()

encuesta.h Escóndete

AIX tiene <sys/poll.h>. Está ahí mismo. Puedes cat. Pero CMake no lo detecta.

Después de tres horas depurando un error “POLLIN undeclared” en viosocket.c, descubrí que la solución era simplemente forzar la definición:

cmake ... -DHAVE_SYS_POLL_H=1

Tres horas. Por una bandera.

(Para ser justos, se trata de un problema de detección de plataforma de CMake, no de AIX. Las comprobaciones de CMake asumen distribuciones de cabecera estilo Linux).

Los Plugins Malditos

Al 98% de compilación – ¡98%! – el plugin wsrep_info explotó con símbolos indefinidos. Porque depende de Galera. Que no estamos usando. Pero CMake lo compila igualmente.

También S3 (requiere símbolos Aria), Mroonga (requiere Groonga) y RocksDB (profundamente ligado a optimizaciones específicas de Linux).

Configuración final de CMake:

-DPLUGIN_MROONGA=NO -DPLUGIN_ROCKSDB=NO -DPLUGIN_SPIDER=NO 
-DPLUGIN_TOKUDB=NO -DPLUGIN_OQGRAPH=NO -DPLUGIN_S3=NO -DPLUGIN_WSREP_INFO=NO

Parece una amputación quirúrgica, pero en realidad es sólo recortar la grasa. Estos plugins son casos extremos que pocas implantaciones necesitan.

Capítulo 3: Thread Pool, o cómo aprendí a dejar de preocuparme y a amar el Mutex

Aquí es donde las cosas se pusieron interesantes. Y por “interesante” quiero decir “casi me da un tic permanente”.

MariaDB tiene dos modos de gestión de las conexiones:

• un hilo por conexión: Un hilo por cliente. Sencillo. Escala como un coche cuesta arriba.
• pool de hilos: Un conjunto fijo de hilos gestiona todas las conexiones. Elegante. Eficaz. Y no disponible en AIX.

¿Por qué? Porque el pool de hilos requiere APIs de multiplexación de E/S específicas de la plataforma:

Así que… ¿tan difícil puede ser implantar el soporte pollset?

(Nota del editor: Llegados a este punto, el autor necesitó una pausa de 20 minutos y una bebida)

El problema de ONESHOT

Linux epoll tiene una maravillosa bandera llamada EPOLLONESHOT. Garantiza que un descriptor de archivo dispare eventos sólo una vez hasta que lo vuelvas a armar explícitamente. Esto impide que dos hilos procesen simultáneamente la misma conexión.

El Pollset AIX se activa por niveles. Sólo se activa por niveles. Sin opciones. Si hay datos disponibles, los comunica. Una y otra vez. Como un colega servicial que no para de recordarte ese correo electrónico que aún no has contestado.

Once versiones para aumentar la sabiduría

Lo que siguió fueron once iteraciones de código, cada una más elaborada que la anterior, intentando simular el comportamiento de ONESHOT:

v1-v5 (La edad de la inocencia)

Probé a modificar las banderas de evento con PS_MOD. “Si cambio el evento a 0, dejará de disparar”, pensé. Spoiler: no dejó de disparar.

v6-v7 (La era de las máquinas de estado)

“¡Ya lo sé! Mantendré el estado interno y filtraré los eventos duplicados”. El problema: hay una ventana de tiempo entre que el núcleo te da el evento y tú actualizas tu estado. En esa ventana, otro hilo puede recibir el mismo evento.

v8-v9 (La fase de negación)

“Pondré el estado PENDIENTE antes de procesar”. Funcionó… más o menos… hasta que dejó de funcionar.

v10 (Esperanza)

Por fin encontré la solución: PS_DELETE + PS_ADD. Cuando recibas un evento, borra inmediatamente el fd del pollset. Cuando estés preparado para recibir más datos, vuelve a añadirlo.

// On receiving events: REMOVE
for (i = 0; i < ret; i++) {
    pctl.cmd = PS_DELETE;
    pctl.fd = native_events[i].fd;
    pollset_ctl(pollfd, &pctl, 1);
}

// When ready: ADD
pce.command = PS_ADD;
pollset_ctl_ext(pollfd, &pce, 1);

¡Funcionó! Con -O2.

Con -O3… segfault.

La Noche Oscura del Alma (El -O3 Bug)

Imagínate. Tengo un código que funciona perfectamente con -O2. Habilito -O3 para las pruebas de producción y el servidor se bloquea con “Got packets out of order” o un segfault en CONNECT::create_thd().

Me pasé dos días pensando que era un error del compilador. GCC 13.3.0 en AIX. Culpé al compilador. Culpé al enlazador. Culpé a todo menos a mi propio código.

El problema era más sutil: MariaDB tiene dos rutas de código concurrentes que llaman a io_poll_wait en el mismo pollset:

• Los bloques de escucha con timeout=-1
• Los trabajadores encuestan con timeout=0 antes de irse a dormir

Con -O2, el código era lo suficientemente lento como para que la ventana de condición de carrera fuera microscópica. Con -O3, la ejecución más rápida del código hacía que la condición de carrera apareciera constantemente.

En realidad, éste es un gran ejemplo de por qué importa la optimización en cualquier plataforma. La misma condición de carrera existe en el código; la optimización sólo cambia si la ves.

v11: Victoria

La solución fue añadir un mutex por juego de rol:

if (timeout_ms == 0) {
    if (pthread_mutex_trylock(lock) != 0)
        return 0;  // Listener is active, skip
} else {
    pthread_mutex_lock(lock);  // Block and wait
}
// ... poll + delete loop ...
pthread_mutex_unlock(lock);

100 conexiones simultáneas. 1.000 conexiones. -O3 a pleno rendimiento. Cero caídas.

Lo he conseguido. REALMENTE LO HICE

Capítulo 4: “-mcpu=power10? Claro, ¿por qué no?

Con el grupo de hilos funcionando, era hora de optimizar para nuestro hardware. Tenemos máquinas POWER9, y obviamente -mcpu=power10 generará mejor código con compatibilidad hacia atrás, ¿no?

gcc -mcpu=power10 -mtune=power10 -O3 -o test_p10 test.c
./test_p10  # Runs on POWER9!

¡Estupendo! Ahora vamos a comprobar las instrucciones generadas:

grep -c "pld\|pstd\|plwa\|paddi" test_p10.s
# Result: 0

Cero. Instrucciones de ZERO POWER10.

He comparado el montaje de -mcpu=power9 con el de -mcpu=power10:

power9: 133 lines
power10: 132 lines  
diff: Minor reordering, NO power10-specific instructions

Resulta que el backend XCOFF de GCC (el formato binario nativo de AIX – piensa que es la forma que tiene AIX de empaquetar los programas, diferente del formato ELF de Linux) no es compatible con las extensiones POWER10. Las instrucciones prefijadas (pld, pstd), el direccionamiento relativo al PC… nada de eso existe en el mundo XCOFF.

__MMA__ está definida (Ayuda Matriz-Multiplicar), pero sólo es útil si escribes código explícito para utilizar operaciones matriciales. __PCREL__ y __PREFIXED__… indefinidas.

Para llevar: En AIX con GCC, -mcpu=power10 produce un código idéntico a -mcpu=power9. No pierdas el tiempo creando binarios distintos.

Capítulo 5: El ecosistema de la cadena de herramientas

Herramientas GNU en AIX

La cadena de herramientas nativa de AIX mantiene una compatibilidad POSIX estricta, lo que en realidad es una característica para el código portable. Pero para los que nos hemos pasado 20 años asumiendo que sed -i existe en todas partes, requiere algunos ajustes.

Por eso en LibrePower mantenemos linux-compat, una colección de herramientas GNU empaquetadas para AIX que hacen práctico el desarrollo moderno:

# With linux-compat from LibrePower, all of this works:
sed -i 's/foo/bar/' file.txt   # ✓
grep -A 5 "pattern" file       # ✓
seq 1 100                      # ✓
date +%s%N                     # ✓ (nanoseconds!)

¿Es diferente de Linux? Claro, pero ¿sabes qué tiene AIX? Décadas de estabilidad, una programación de procesos sólida como una roca, una gestión de memoria adaptada a cargas de trabajo de bases de datos de alto rendimiento y un subsistema de E/S que los ingenieros de Oracle, Informix y DB2 llevan optimizando desde antes de que nacieran algunos de los desarrolladores actuales.

Prefiero “necesidad de instalar herramientas GNU” a “asesino OOM aleatorio en producción” cualquier día.

El gran avance del compilador: Open XL 17.1.3

Aquí es donde la historia da un giro dramático.

IBM tiene xlC, su compilador tradicional, y más recientemente Open XL C/C++, basado en LLVM/Clang. Hemos instalado Open XL 17.1.3 (basado en Clang 19.1.2) para evaluarlo como alternativa a GCC 13.3.0.

El resultado: 3 veces más rápido. No un 3%: tres veces.

Mismo hardware. Mismas banderas (-O3 -mcpu=power9). El mismo código. Tres veces más rápido, con una variación casi nula de ejecución a ejecución en comparación con la variación del 10-40% de GCC.

¿Por qué tanta diferencia?

GCC LTO (Link-Time Optimization) es imposible en AIX. La implementación de LTO de GCC requiere el formato binario ELF; AIX utiliza XCOFF. El script de configuración de GCC lo bloquea explícitamente:

# Apart from ELF platforms, only Windows and Darwin support LTO so far.
if test x"$enable_lto" = x"yes"; then
  as_fn_error "LTO support is not enabled for this target."

No se trata de que falte un paquete o una bandera de compilación, sino de una limitación arquitectónica fundamental.

Open XL, al estar basado en LLVM, genera código mucho mejor para POWER9 desde el principio. La mejora proviene de una programación de instrucciones superior, una mejor asignación de registros y pases de optimización que GCC simplemente no tiene para este objetivo.

La ironía del LTO

Hemos probado Open XL con -flto=full. ¡Construye! ¡En XCOFF! Pero… es un 27% más lento que Open XL sin LTO.

¿Por qué? Las bibliotecas compartidas AIX requieren una lista de exportación explícita (exports.exp). Con LTO, el enlazador ve ~27.000 símbolos que debe exportar. La principal ventaja de LTO es internalizar funciones y eliminar código muerto, pero cuando te ves obligado a exportar 27.000 símbolos, esa ventaja se evapora. La sobrecarga adicional de LTO en realidad lo empeora.

El callejón sin salida del PGO

La Optimización Guiada por Perfil tampoco funciona. Lo hemos probado todo:

• Los símbolos de tiempo de ejecución de perfil (__llvm_prf_*) son símbolos locales que no se exportan
• Enlazar manualmente libclang_rt.profile-powerpc64.a y forzar -u__llvm_profile_runtime
• Los casos de prueba sencillos funcionan, pero la compleja configuración de la biblioteca compartida de MariaDB desbarata el enfoque

El tiempo de ejecución de perfiles LLVM utiliza atexit() para escribir perfiles. En AIX con XCOFF, los destructores de bibliotecas compartidas tienen una semántica diferente. Los perfiles nunca se escriben.

Conclusión: Open XL 17.1.3 sin LTO ni PGO nos proporciona una mejora 3 veces superior. Esa es la victoria pragmática por ahora.

La sorpresa del modo LPAR: El modo compartido supera al dedicado

He aquí un hallazgo contraintuitivo que nos sorprendió.

Una LPAR (Partición Lógica) es la tecnología de virtualización de AIX: te permite dividir un servidor físico en varias máquinas virtuales aisladas. Puedes configurar estas particiones con procesadores “compartidos” (flexibles, prestados de un pool) o “dedicados” (reservados sólo para ti).

Probamos la búsqueda vectorial de MariaDB en distintas configuraciones de LPAR:

La LPAR compartida es aproximadamente un 25% más rápida que la dedicada para consultas vectoriales de un solo hilo.

¿Por qué? Por dos razones:

1. Frecuencia optimizada para la carga de trabajo (WoF): Piensa en ello como en un coche con turboalimentación. En modo compartido con baja utilización, POWER9 puede aumentar la frecuencia de un solo núcleo hasta ~3,8 GHz – como pisar el acelerador en una autopista vacía. Dedicado-Capped se fija en 2750 MHz – como el control de crucero bloqueado a 55 mph.
2. Préstamo de ciclos: El modo compartido puede tomar prestados ciclos ociosos del conjunto de procesadores compartidos. Dedicado-Capitado se limita estrictamente a la capacidad asignada: sólo obtienes lo que has pagado, aunque tus vecinos no estén utilizando lo suyo.

El desastre del modo donación

Se supone que el modo Dedicado-Donante devuelve los ciclos no utilizados al pool compartido. En teoría, obtienes procesadores dedicados cuando los necesitas y contribuyes al fondo común cuando estás inactivo.

En la práctica, para cargas de trabajo bursty de un solo hilo, como la búsqueda vectorial: 60-70% de regresión de rendimiento con GCC.

La sobrecarga de recuperación de ciclos es devastadora. Cada vez que la carga de trabajo estalla, hay latencia al recuperar ciclos donados. Con la ya de por sí alta varianza de GCC, esto crea un rendimiento terrible.

Open XL lo gestiona mejor (sólo una pequeña regresión), pero no hay razón para utilizar el modo Donar para esta carga de trabajo.

Recomendación:

• Consultas de un solo hilo, sensibles a la latencia (como la búsqueda vectorial): Utiliza la LPAR compartida – gana el aumento de frecuencia
• Cargas de trabajo multihilo y centradas en el rendimiento (como OLTP masivo): Utiliza Dedicated-Capped: el rendimiento constante importa más

Este hallazgo se aplica a cualquier carga de trabajo similar en POWER9, no sólo a MariaDB.

La cosa -blibpath (En realidad, una característica)

Una característica genuina de AIX: tienes que especificar explícitamente la ruta de la biblioteca en tiempo de enlace con -Wl,-blibpath:/your/path. Si no lo haces, el binario no encontrará libstdc++ aunque esté en el mismo directorio.

Al principio esto parece molesto. Luego te das cuenta: AIX prefiere las rutas explícitas y deterministas a las búsquedas implícitas. En entornos de producción en los que no es aceptable el “funcionó en mi máquina”, eso es una característica, no un error.

Capítulo 6: Las cifras (Progresos reales, lagunas reales)

Después de todo este trabajo, ¿dónde estamos realmente? Permíteme ser totalmente transparente.

Lo que funciona sólido

El RPM está publicado en aix.librepower.org y desplegado en un sistema IBM POWER9 (12 núcleos, SMT-8). MariaDB 11.8.5 se ejecuta en AIX 7.3 con el grupo de hilos activado. El servidor ha superado una serie de pruebas de calidad brutales:

1.648.482.400 bytes de memoria, constantes durante 30 minutos. Ni un solo byte de deriva. El servidor funcionó durante 39 minutos bajo carga continua y realizó un apagado limpio.

Funciona. Es estable. Está listo para funcionar en producción.

El viaje del rendimiento

Aquí tienes el cuadro completo, desde el punto de partida hasta el estado actual:

El trabajo con grupos de hilos proporcionó enormes ganancias para cargas de trabajo concurrentes. Para la búsqueda vectorial en concreto, Open XL ofrece una mejora adicional de 3 veces sobre GCC.

La brecha contra Linux (giro argumental: no hay ninguna)

Ésta es la pregunta que todo el mundo se hace: “¿Cómo se compara con Linux?”

Para la búsqueda vectorial (MHNSW) -una carga de trabajo que estresa los patrones de acceso a la memoria- esto es lo que medimos en un hardware POWER9 idéntico:

Espera: el sistema AIX tiene 21 núcleos frente a los 24 de Linux (un 12,5% menos). ¿Y la diferencia medida? 10-18%.

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

Con Open XL, AIX ofrece el mismo rendimiento por núcleo que Linux. ¿El mito de que “AIX es lento”? Completamente desmentido. La diferencia siempre fue el compilador.

Lo que intentamos (El Museo del Fracaso)

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 realmente ayudó

Esta es la Parte 1. El trabajo continúa.

Lo que aprendí

1. CMake asume Linux. En sistemas que no sean Linux, comprueba manualmente que la detección de características es correcta. Los falsos positivos te morderán en tiempo de ejecución.
2. La E/S activada por niveles requiere disciplina. EPOLLONESHOT existe por una razón. Si tu sistema no lo tiene, prepárate para implementar tu propia serialización.
3. -O3 expone errores latentes. Si tu código “funciona con -O2 pero no con -O3”, tienes una condición de carrera. El compilador está haciendo su trabajo; el fallo es tuyo.
4. Los mutex son tus amigos. Sí, tienen sobrecarga. ¿Pero sabes qué tiene más sobrecarga? Depurar condiciones de carrera a las 3 de la mañana.
5. AIX recompensa la comprensión profunda. Es un sistema que no perdona los atajos, pero una vez que entiendes sus convenciones, es predecible y robusto. Hay una razón por la que los bancos siguen utilizándolo, y seguirán haciéndolo en un futuro previsible.
6. El ecosistema importa. Proyectos como linux-compat de LibrePower hacen viable el desarrollo moderno en AIX. Contribuir a ese ecosistema beneficia a todos.
7. La optimización es un viaje, no un destino. Hemos conseguido que funcione el grupo de hilos. Tenemos -O3 estable. Pero hay más rendimiento que desbloquear, y aún no hemos terminado.

Lo que viene después (Spoiler: La 2ª parte está lista)

Los RPM se publican en aix.librepower.org. La versión GCC es estable y está preparada para funcionar en producción. La versión Open XL ofrece un rendimiento 3 veces superior, pero requiere una licencia comercial para su uso en producción.

En la Parte 2, trataré:

• Cómo cerramos una brecha de rendimiento de 23 veces hasta el 0%.
• Las correcciones de configuración que nos proporcionaron una mejora de 65x
• La inmersión profunda en la configuración LPAR
• El “Museo del Fracaso” completo de cosas que no funcionaron

TL;DR

• MariaDB 11.8.5 funciona ahora en AIX 7.3 con el grupo de hilos activado
• La primera implementación de un grupo de hilos para AIX utilizando pollset (11 iteraciones para conseguir una simulación ONESHOT correcta).
• IBM Open XL C/C++ 17.1.3 ofrece 3 veces más velocidad que GCC 13.3.0
• GCC LTO es imposible en AIX (XCOFF frente a ELF); Open XL LTO es contraproducente (27% más lento debido a las exportaciones forzadas)
• La LPAR compartida supera a la dedicada para consultas de un solo hilo (aumento de frecuencia WoF: 3,8 GHz frente a 2750 MHz)
• El modo Donar es desastroso: 60-70% de regresión con CCG – utiliza el modo Capado
• El filtro de floración POWER VSX era un 41% más lento que el escalar (no hay multiplicación vectorial de 64 bits en POWER9)

¿Preguntas? ¿Ideas? ¿Quieres contribuir al ecosistema de código abierto de AIX?

Este trabajo forma parte de LibrePower – Software de código abierto para IBM Power Systems

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