Portage de MariaDB sur IBM AIX : 3 semaines de souffrance technique

Partie 1 : Apporter MariaDB à la plateforme qui alimente les systèmes les plus critiques du monde

Dans la vie, il y a des décisions que tu prends en sachant très bien qu’elles te feront souffrir. Se marier. Avoir des enfants. Courir un marathon. Porter MariaDB 11.8 sur IBM AIX.

Voici l’histoire de la dernière – et pourquoi je la referais sans hésiter.

Chapitre 1 : “C’est si dur que ça ?”

Tout a commencé par une question innocente lors d’une réunion d’équipe : “Pourquoi n’avons-nous pas MariaDB sur nos systèmes AIX ?”

Voici ce que les gens qui n’ont jamais travaillé avec AIX ne comprennent pas : AIX ne plaisante pas. Lorsque les banques ont besoin d’un temps de disponibilité de cinq neuf pour leurs systèmes bancaires de base, elles utilisent AIX. Lorsque les compagnies aériennes ont besoin de systèmes de réservation qui ne peuvent pas tomber en panne, elles utilisent AIX. Quand Oracle, Informix ou DB2 doivent fournir des performances absolument brutales pour des charges de travail OLTP critiques, ils utilisent AIX.

AIX n’est pas à la mode. AIX n’a pas de mascotte cool. AIX ne fera pas l’objet d’articles de blogs technologiques essoufflés sur la “perturbation”. Mais lorsque les choses ne peuvent absolument pas échouer, AIX est là, faisant tranquillement son travail pendant que tous les autres sont occupés à redémarrer leurs conteneurs.

Alors pourquoi MariaDB ne prend-elle pas officiellement en charge AIX ? L’économie est simple : la communauté open source s’est concentrée sur Linux, et le portage nécessite une expertise spécifique à la plateforme. MariaDB prend officiellement en charge Linux, Windows, FreeBSD, macOS et Solaris. AIX ne figure pas sur la liste – non pas parce que c’est une mauvaise plate-forme, mais parce que personne n’a encore fait le travail.

Chez LibrePower, c’est exactement ce que nous faisons.

Ma première erreur a été de dire tout haut : “Il suffit sans doute de le compiler et d’ajuster quelques éléments”.

Leçon n° 1: Lorsque quelqu’un dit ” compile-le simplement ” à propos d’un logiciel sur AIX, il est sur le point d’en apprendre beaucoup sur la programmation des systèmes.

Chapitre 2 : CMake et les trois invités inattendus

Le premier jour de la compilation a été… éducatif. CMake sur AIX, c’est comme jouer aux cartes avec quelqu’un qui a une compréhension très différente des règles – et qui s’attend à ce que tu les découvres toi-même.

Le bogue de la fonction fantôme

AIX a une caractéristique intéressante : il déclare des fonctions dans les en-têtes pour des raisons de compatibilité, même si ces fonctions n’existent pas réellement au moment de l’exécution. C’est comme si ton GPS te disait “tourne à droite dans 200 mètres” mais que la rue était un mur de briques.

CMake fait un CHECK_C_SOURCE_COMPILES pour tester si pthread_threadid_np() existe. Le code se compile. CMake dit “super, on l’a !” Le binaire démarre et… BOOM. Symbole non trouvé.

Il s’avère que pthread_threadid_np() est réservé à macOS. AIX le déclare dans les en-têtes parce que… eh bien, je ne suis pas encore tout à fait sûr. Peut-être pour une raison de compatibilité POSIX qui avait un sens il y a des décennies ? Quelle que soit la raison, GCC le compile sans problème et l’éditeur de liens ne se plaint pas jusqu’à l’exécution.

Même chose avec getthrid(), qui est spécifique à OpenBSD.

La solution:

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()

poll.h : Cache-cache

AIX a <sys/poll.h>. C’est juste là. Tu peux cat. Mais CMake ne le détecte pas.

Après trois heures de débogage d’une erreur “POLLIN undeclared” dans viosocket.c, j’ai découvert que la solution consistait simplement à forcer la définition :

cmake ... -DHAVE_SYS_POLL_H=1

Trois heures. Pour un drapeau.

(Pour être honnête, il s’agit d’un problème de détection de plate-forme CMake, et non d’un problème AIX. Les vérifications de CMake supposent des dispositions d’en-tête de type Linux).

Les plugins maudits

À 98 % de la compilation – 98 % ! – le plugin wsrep_info a explosé avec des symboles non définis. Parce qu’il dépend de Galera. Que nous n’utilisons pas. Mais CMake le compile quand même.

Egalement S3 (nécessite les symboles Aria), Mroonga (nécessite Groonga), et RocksDB (profondément lié aux optimisations spécifiques à Linux).

Configuration finale de CMake :

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

Cela ressemble à une amputation chirurgicale, mais il s’agit en fait de tailler dans le gras. Ces plugins sont des cas limites dont peu de déploiements ont besoin.

Chapitre 3 : Thread Pool, ou comment j’ai appris à arrêter de m’inquiéter et à aimer le Mutex

C’est là que les choses sont devenues intéressantes. Et par “intéressant”, je veux dire “j’ai failli me donner un tic permanent”.

MariaDB a deux modes de gestion des connexions :

• une-filière-par-connexion: Un thread par client. Simple. S’adapte comme une voiture qui monte une côte.
• pool de threads: Un pool fixe de threads gère toutes les connexions. Élégant. Efficace. Et non disponible sur AIX.

Pourquoi ? Parce que le pool de threads nécessite des API de multiplexage d’E/S spécifiques à la plateforme :

Alors… à quel point la mise en œuvre de la prise en charge des jeux de vote peut-elle être difficile ?

(Note de la rédaction : à ce stade, l’auteur a besoin d’une pause de 20 minutes et d’une boisson).

Le problème ONESHOT

Linux epoll possède un merveilleux drapeau appelé EPOLLONESHOT. Il garantit qu’un descripteur de fichier ne déclenche des événements qu’une seule fois jusqu’à ce que tu le réarmes explicitement. Cela empêche deux threads de traiter la même connexion simultanément.

Le pollset AIX est déclenché par niveau. Uniquement déclenché par niveau. Pas d’options. Si des données sont disponibles, il les signale. Encore et encore et encore. Comme un collègue serviable qui te rappelle sans cesse ce courriel auquel tu n’as pas encore répondu.

Onze versions de la sagesse croissante

Il s’en est suivi onze itérations de code, toutes plus élaborées les unes que les autres, pour essayer de simuler le comportement de ONESHOT :

v1-v5 (L’âge de l’innocence)

J’ai essayé de modifier les drapeaux d’événements avec PS_MOD. “Si je mets l’événement à 0, il ne se déclenchera plus”, me suis-je dit. Spoiler : il n’a pas cessé de se déclencher.

v6-v7 (L’ère des machines à états)

“Je sais ! Je vais maintenir l’état interne et filtrer les événements en double.” Le problème : il y a une fenêtre de temps entre le moment où le noyau te donne l’événement et celui où tu mets à jour ton état. Dans cette fenêtre, un autre thread peut recevoir le même événement.

v8-v9 (La phase de déni)

“Je vais mettre l’état à PENDANT avant de traiter”. Ça a marché… en quelque sorte… jusqu’à ce que ça ne marche plus.

v10 (Espoir)

J’ai enfin trouvé la solution : PS_DELETE + PS_ADD. Lorsque tu reçois un événement, supprime immédiatement le fd du pollset. Lorsque tu es prêt à recevoir d’autres données, ajoute-le à nouveau.

// 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);

Ça a marché ! Avec -O2.

Avec -O3… segfault.

La nuit noire de l’âme (Le bug -O3)

Imagine mon visage. J’ai un code qui fonctionne parfaitement avec -O2. J’active -O3 pour les benchmarks de production et le serveur se plante avec “Got packets out of order” ou un segfault dans CONNECT::create_thd().

J’ai passé deux jours à penser qu’il s’agissait d’un bug du compilateur. GCC 13.3.0 sur AIX. J’ai accusé le compilateur. J’ai blâmé l’éditeur de liens. J’ai tout blâmé sauf mon propre code.

Le problème était plus subtil : MariaDB a deux chemins de code concurrents qui appellent io_poll_wait sur le même pollset :

• Les blocs d’écoute avec timeout=-1
• Les travailleurs sondent timeout=0 avant de s’endormir

Avec -O2, le code était suffisamment lent pour que la fenêtre de la condition de course soit microscopique. Avec -O3, l’exécution plus rapide du code faisait apparaître la condition de course en permanence.

C’est en fait un excellent exemple de la raison pour laquelle l’optimisation est importante sur n’importe quelle plateforme. La même condition de course existe dans le code ; l’optimisation change simplement le fait que tu la voies ou non.

v11 : Victoire

La solution a consisté à ajouter un mutex par jeu de polices :

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 connexions simultanées. 1 000 connexions. -O3 à plein régime. Zéro plantage.

Je l’ai fait. JE L’AI VRAIMENT FAIT.

Chapitre 4 : “-mcpu=power10 ? Bien sûr, pourquoi pas ?”

Le pool de threads fonctionnant, il était temps d’optimiser pour notre matériel. Nous avons des machines POWER9, et il est évident que -mcpu=power10 générera un meilleur code avec une compatibilité ascendante, n’est-ce pas ?

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

Super ! Vérifions maintenant les instructions générées :

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

Zéro. ZERO POWER10 instructions.

J’ai comparé l’assemblage de -mcpu=power9 vs -mcpu=power10:

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

Il s’avère que le backend XCOFF de GCC (le format binaire natif d’AIX – considère-le comme la façon d’emballer les programmes d’AIX, différente du format ELF de Linux) ne prend pas en charge les extensions POWER10. Les instructions préfixées (pld, pstd), l’adressage relatif au PC… rien de tout cela n’existe dans le monde XCOFF.

__MMA__ est défini (Matrix-Multiply Assist), mais n’est utile que si tu écris un code explicite pour utiliser les opérations matricielles. __PCREL__ et __PREFIXED__… indéfini.

À emporter: Sur AIX avec GCC, -mcpu=power10 produit un code identique à -mcpu=power9. Ne perds pas de temps à construire des binaires séparés.

Chapitre 5 : L’écosystème de la chaîne d’outils

Outils GNU sur AIX

La chaîne d’outils native d’AIX maintient une stricte compatibilité POSIX, ce qui est en fait une caractéristique du code portable. Mais pour ceux d’entre nous qui ont passé 20 ans à supposer que sed -i existait partout, cela nécessite quelques ajustements.

C’est pourquoi chez LibrePower, nous maintenons linux-compat, une collection d’outils GNU emballés pour AIX qui rend le développement moderne pratique :

# 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!)

Est-il différent de Linux ? Bien sûr. Mais tu sais ce qu’AIX a en commun ? Des décennies de stabilité, une planification des processus solide comme le roc, une gestion de la mémoire adaptée aux charges de travail des bases de données à haut débit et un sous-système d’E/S que les ingénieurs d’Oracle, d’Informix et de DB2 optimisent depuis bien avant la naissance de certains des développeurs d’aujourd’hui.

Je préfère de loin “avoir besoin d’installer des outils GNU” à “un tueur aléatoire en production”.

La percée du compilateur : Open XL 17.1.3

C’est là que l’histoire prend une tournure dramatique.

IBM propose xlC, son compilateur traditionnel, et plus récemment Open XL C/C++, basé sur LLVM/Clang. Nous avons installé Open XL 17.1.3 (construit sur Clang 19.1.2) pour l’évaluer en tant qu’alternative à GCC 13.3.0.

Résultat : trois fois plus rapide. Pas 3 % – trois fois.

Même matériel. Mêmes drapeaux (-O3 -mcpu=power9). Même code. Trois fois plus rapide, avec presque aucune variation d’une exécution à l’autre par rapport aux 10 à 40 % de variation de GCC.

Pourquoi une telle différence ?

GCC LTO (Link-Time Optimization) est impossible sur AIX. L’implémentation LTO de GCC nécessite le format binaire ELF ; AIX utilise XCOFF. Le script de configuration de GCC la bloque explicitement :

# 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."

Il ne s’agit pas d’un paquetage manquant ou d’un drapeau de construction – c’est une limitation architecturale fondamentale.

Open XL, qui est basé sur LLVM, a une bien meilleure génération de code pour POWER9 dès le départ. L’amélioration provient d’une meilleure planification des instructions, d’une meilleure allocation des registres et de passes d’optimisation que GCC n’a tout simplement pas pour cette cible.

L’ironie du LTO

Nous avons essayé Open XL avec -flto=full. Il se construit ! Sur XCOFF ! Mais… c’est 27% plus lent que Open XL sans LTO.

Pourquoi ? Les bibliothèques partagées AIX nécessitent une liste d’exportation explicite (exports.exp). Avec LTO, l’éditeur de liens voit ~27 000 symboles qu’il doit exporter. Le principal avantage de LTO est l’internalisation des fonctions et l’élimination du code mort – mais lorsque tu es obligé d’exporter 27 000 symboles, cet avantage s’évapore. Les frais généraux supplémentaires du LTO ne font qu’empirer les choses.

L’impasse du PGO

L’optimisation guidée par le profil ne fonctionne pas non plus. Nous avons tout essayé :

• Les symboles de profilage (__llvm_prf_*) sont des symboles locaux qui ne sont pas exportés.
• Relier manuellement libclang_rt.profile-powerpc64.a et forcer -u__llvm_profile_runtime
• Les cas de test simples fonctionnent, mais la configuration complexe de la bibliothèque partagée de MariaDB fait échouer l’approche.

Le runtime de profilage LLVM utilise atexit() pour écrire des profils. Sur AIX avec XCOFF, les destructeurs de bibliothèques partagées ont une sémantique différente. Les profils ne sont jamais écrits.

Conclusion: Open XL 17.1.3 sans LTO ni PGO nous donne une amélioration de 3x. C’est la victoire pragmatique pour l’instant.

La surprise du mode LPAR : Le mode partagé l’emporte sur le mode dédié

Voici une découverte contre-intuitive qui nous a surpris.

Un LPAR (Logical Partition) est la technologie de virtualisation d’AIX – il te permet de découper un serveur physique en plusieurs machines virtuelles isolées. Tu peux configurer ces partitions avec des processeurs “partagés” (flexibles, empruntés à un pool) ou des processeurs “dédiés” (réservés uniquement pour toi).

Nous avons testé la recherche vectorielle de MariaDB sur différentes configurations de LPAR :

Le LPAR partagé est environ 25 % plus rapide que le LPAR dédié pour les requêtes vectorielles à un seul fil.

Pourquoi ? Pour deux raisons :

1. Fréquence optimisée pour la charge de travail (WoF) : C’est un peu comme une voiture avec un turbo boost. En mode partagé avec une faible utilisation, POWER9 peut augmenter la fréquence d’un seul cœur jusqu’à ~3,8 GHz – comme si tu appuyais sur l’accélérateur sur une autoroute vide. Dedicated-Capped est fixé à 2750 MHz – comme un régulateur de vitesse bloqué à 55 mph.
2. Emprunt de cycles: Le mode partagé peut emprunter des cycles inactifs au pool de processeurs partagé. Dedicated-Capped est strictement limité à la capacité allouée – tu n’obtiens que ce que tu as payé, même si tes voisins n’utilisent pas la leur.

Le désastre du mode de don

Le mode Dedicated-Donating est censé redonner les cycles inutilisés au pool partagé. En théorie, tu obtiens des processeurs dédiés lorsque tu en as besoin et tu contribues au pool lorsque tu es inactif.

Dans la pratique, pour les charges de travail à un seul fil en rafale comme la recherche vectorielle : 60-70% de régression des performances avec GCC.

Les frais généraux liés à la récupération des cycles sont dévastateurs. Chaque fois que la charge de travail explose, il y a un temps de latence pour récupérer les cycles donnés. Avec la variance déjà plus élevée de GCC, cela crée de terribles performances.

Open XL le gère mieux (seule régression mineure), mais il n’y a aucune raison d’utiliser le mode Donation pour cette charge de travail.

Recommandation:

• Requêtes à un seul fil, sensibles à la latence (comme la recherche vectorielle) : Utilise un LPAR partagé – l’augmentation de la fréquence l’emporte
• Charges de travail multithreads, axées sur le débit (comme l’OLTP en masse) : Utilise Dedicated-Capped – la constance des performances est plus importante.

Cette constatation s’applique à toute charge de travail similaire sur POWER9 – et pas seulement à MariaDB.

La chose -blibpath (en fait un reportage)

Une véritable caractéristique d’AIX : tu dois spécifier explicitement le chemin de la bibliothèque au moment de la liaison avec -Wl,-blibpath:/your/path. Si tu ne le fais pas, le binaire ne trouvera pas libstdc++ même s’il se trouve dans le même répertoire.

Au début, cela te semble ennuyeux. Puis tu réalises : AIX préfère les chemins explicites et déterministes aux recherches implicites. Dans les environnements de production où “ça a marché sur ma machine” n’est pas acceptable, c’est une caractéristique, pas un bogue.

Chapitre 6 : Les chiffres (Progrès réels, écarts réels)

Après tout ce travail, où en sommes-nous réellement ? Permettez-moi d’être totalement transparent.

Ce qui fonctionne solidement

Le RPM est publié sur aix.librepower.org et déployé sur un système IBM POWER9 (12 cœurs, SMT-8). MariaDB 11.8.5 fonctionne sur AIX 7.3 avec le pool de threads activé. Le serveur a passé avec succès une suite d’assurance qualité brutale :

1 648 482 400 octets de mémoire – constants pendant 30 minutes. Pas un seul octet de dérive. Le serveur a fonctionné pendant 39 minutes en charge continue et s’est éteint proprement.

Il fonctionne. Il est stable. Il est prêt à être mis en production.

Le voyage de la performance

Voici le tableau complet, de l’état initial à l’état actuel :

Le travail sur le pool de threads a permis des gains massifs pour les charges de travail simultanées. Pour la recherche vectorielle en particulier, Open XL apporte une amélioration supplémentaire de 3x par rapport à GCC.

L’écart par rapport à Linux (rebondissement : il n’y en a pas)

Voici la question que tout le monde se pose : “Comment se compare-t-il à Linux ?”

Pour la recherche vectorielle (MHNSW) – une charge de travail qui met à l’épreuve les schémas d’accès à la mémoire – voici ce que nous avons mesuré sur du matériel POWER9 identique :

Attends – le système AIX a 21 cœurs contre 24 pour Linux (12,5 % de moins). Et la différence mesurée ? 10-18%.

Ce n’est pas un écart de performance. C’est une différence de matériel.

Avec Open XL, AIX offre les mêmes performances par cœur que Linux. Le mythe “AIX est lent” ? Complètement démystifié. C’est le compilateur qui a toujours fait la différence.

Ce que nous avons essayé (Le musée de l’échec)

La science ne se limite pas à ce qui fonctionne – il s’agit aussi de documenter ce qui ne fonctionne pas. Voici notre mur de “bien essayé, mais non” :

Le résultat de VSX est particulièrement intéressant : nous avons implémenté un filtre Bloom SIMD en utilisant les extensions vectorielles de POWER. Il était 41 % plus lent que le scalaire. POWER9 n’a pas de multiplication vectorielle 64 bits – il faut vec_extract → multiplication scalaire → vec_insert pour chaque voie, ce qui est plus lent que de laisser le moteur Out-of-Order gérer une boucle scalaire.

Ce qui a vraiment aidé

Ceci est la première partie. Le travail continue.

Ce que j’ai appris

1. CMake suppose qu’il s’agit de Linux. Sur les systèmes non-Linux, vérifie manuellement que la détection des fonctionnalités est correcte. Les faux positifs te feront mal au moment de l’exécution.
2. Les entrées/sorties déclenchées par niveau nécessitent de la discipline. EPOLLONESHOT existe pour une raison. Si ton système ne l’a pas, prépare-toi à mettre en œuvre ta propre sérialisation.
3. -O3 expose les bogues latents. Si ton code “fonctionne avec -O2 mais pas avec -O3”, tu as une condition de course. Le compilateur fait son travail ; le bogue est le tien.
4. Les mutex sont tes amis. Oui, elles ont des frais généraux. Mais tu sais ce qui est le plus coûteux ? Déboguer les conditions de course à 3 heures du matin.
5. AIX récompense la compréhension profonde. C’est un système qui ne pardonne pas les raccourcis, mais une fois que tu as compris ses conventions, il est prévisible et robuste. Ce n’est pas pour rien que les banques l’utilisent encore – et qu’elles continueront à le faire dans un avenir prévisible.
6. L’écosystème est important. Des projets comme linux-compat de LibrePower rendent le développement moderne viable sur AIX. Contribuer à cet écosystème profite à tout le monde.
7. L‘optimisation est un voyage, pas une destination. Nous avons réussi à faire fonctionner le pool de threads. Nous avons stabilisé -O3. Mais il reste encore des performances à débloquer, et nous n’avons pas encore terminé.

La suite (Spoiler : la deuxième partie est prête)

Les RPM sont publiés sur aix.librepower.org. La version GCC est stable et prête pour la production. La version Open XL offre des performances trois fois supérieures mais nécessite une licence commerciale pour une utilisation en production.

Dans la deuxième partie, je couvrirai :

• Comment nous avons comblé un écart de performance de 23x à 0%.
• Les correctifs de configuration qui nous ont permis d’obtenir une amélioration de 65x.
• La configuration LPAR en profondeur
• Le “Musée de l’échec” complet des choses qui n’ont pas fonctionné.

TL;DR

• MariaDB 11.8.5 fonctionne maintenant sur AIX 7.3 avec le pool de threads activé
• Première mise en œuvre d’un pool de threads pour AIX à l’aide d’un pollset (11 itérations pour obtenir une simulation ONESHOT correcte).
• IBM Open XL C/C++ 17.1.3 est trois fois plus rapide que GCC 13.3.0
• GCC LTO est impossible sur AIX (XCOFF vs ELF) ; Open XL LTO est contre-productif (27% plus lent à cause des exportations forcées).
• Le LPAR partagé l’emporte sur le LPAR dédié pour les requêtes à un seul thread (augmentation de la fréquence du WoF : 3,8 GHz contre 2750 MHz).
• Le mode donateur est désastreux: 60-70% de régression avec GCC – utilise le mode plafonné.
• POWER VSX bloom filter était 41% plus lent que le scalaire (pas de multiplication vectorielle 64 bits sur POWER9).

Des questions ? Des idées ? Tu veux contribuer à l’écosystème open source AIX ?

Ce travail fait partie de LibrePower – Open source software for IBM Power Systems.

Dépôt du projet AIX : gitlab.com/librepower/aix