Archive d’étiquettes pour : LibrePower

Portage de MariaDB vers IBM AIX (Partie 2) : comment AIX se met au niveau de Linux

/dans /par

De “AIX est lent” à “AIX égale Linux” (avec les bons outils et le bon code)

Dans la première partie, je me suis battu avec CMake, j’ai implémenté un pool de threads à partir de zéro et j’ai livré un serveur MariaDB 11.8.5 stable pour AIX. Le serveur a passé 1 000 connexions simultanées, 11 millions de requêtes et aucune fuite de mémoire.

Ensuite, j’ai effectué une recherche vectorielle de référence.

AIX: 42 requêtes par seconde.
Linux (même HW) : 971 requêtes par seconde.

Vingt-trois fois plus lent. Sur un matériel IBM Power S924 identique. Même version de MariaDB. Même jeu de données.

Voici l’histoire de la façon dont nous avons découvert qu’il n’y avait aucun écart de performance – juste des erreurs de configuration et un compilateur sous-optimal.

Chapitre 1 : Le sentiment d’affaissement

Il y a un genre particulier de désespoir qui vient quand on voit un écart de performance de 23x sur un matériel identique. C’est le genre de désespoir “j’aurais peut-être dû devenir fleuriste”.

Permettez-moi de planter le décor : les deux machines sont des LPARs fonctionnant sur des serveurs IBM Power S924 avec des processeurs POWER9 à 2750 MHz. Même MariaDB 11.8.5. Même ensemble de données de test – 100 000 vecteurs à 768 dimensions, utilisant l’index MHNSW (Hierarchical Navigable Small World) de MariaDB pour la recherche vectorielle.

Le critère de référence était simple : trouver les 10 voisins les plus proches d’un vecteur de requête. C’est le genre d’opération qui alimente toutes les fonctions de recherche améliorées par l’IA que tu as déjà utilisées.

Linux l’a fait en environ 1 milliseconde. AIX a mis 24 millisecondes.

Mon premier réflexe a été le déni. “Le repère doit être erroné”. Ce n’était pas le cas. “Peut-être que l’index est corrompu”. Ce n’était pas le cas. “Peut-être que le réseau est lent”. Il s’agissait d’une connexion locale.

Il est temps de creuser.

Chapitre 2 : Les premiers 65x – L’importance de la configuration

Le cache qui a tout oublié

Le premier indice est venu du profileur de MariaDB. Chaque requête prenait le même temps, qu’il s’agisse de la première ou de la centième. Ce n’est pas ainsi que fonctionnent les caches.

J’ai vérifié la configuration MHNSW de MariaDB :

SHOW VARIABLES LIKE 'mhnsw%';

mhnsw_max_cache_size: 16777216

16 MO. Notre graphique vectoriel a besoin d’environ 300 Mo pour contenir la structure HNSW en mémoire.

C’est là que le bât blesse : lorsque le cache se remplit, MariaDB n’expulse pas les anciennes entrées (pas de LRU). Il jette tout et repart à zéro. Chaque. Chaque. Demande.

Imagine une bibliothèque où, lorsque les étagères sont pleines, le bibliothécaire brûle tous les livres et commande de nouveaux exemplaires. Pour chaque utilisateur.

Correction: mhnsw_max_cache_size = 4GB dans la configuration du serveur.

Résultat : 42 QPS → 112 QPS. Une amélioration de 2,7x à partir d’une seule ligne de configuration.

Le problème de la taille des pages

AIX utilise par défaut des pages de mémoire de 4 Ko. Linux sur POWER utilise des pages de 64 Ko.

Pour le modèle d’accès du MHNSW – la chasse aux pointeurs sur un graphique de 300 Mo – cela a une importance énorme. Avec des pages de 4 Ko, tu as besoin de 16x plus d’entrées TLB (Translation Lookaside Buffer) pour mapper la même quantité de mémoire. Les erreurs du TLB coûtent cher.

C’est comme si tu naviguais dans une ville. Avec des pages de 4 Ko, tu as besoin d’indications pour chaque bâtiment. Avec des pages de 64 Ko, tu obtiens des indications par quartier. C’est beaucoup plus rapide quand tu es constamment en train de sauter d’un bâtiment à l’autre.

Correction: script d’enrobage qui définit LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

Résultat : 112 QPS → 208 QPS en séquentiel, et 2 721 QPS avec 12 travailleurs en parallèle.

Le tableau d’affichage après la phase 1

ConfigurationQPS séquentielAvec 12 travailleurs
Base de référence42~42
+ 4GB cache112–
+ 64K pages2082,721

Amélioration de 65x à partir de deux changements de configuration. Aucune modification du code.

Mais nous étions toujours 6x plus lents que Linux par cœur. L’enquête s’est poursuivie.

Chapitre 3 : Le mystère du décrochage entre le CPU et la mémoire

Une fois la configuration établie, j’ai sorti les outils de profilage. MariaDB possède un profileur intégré qui décompose le temps de requête par phase.

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)

Le temps d’exécution de l’unité centrale était 1,8 fois plus lent sur AIX – ce qui peut s’expliquer par les différences de compilateur. Mais les blocages de la mémoire étaient 329 fois pires.

La cause première : Invalidation du cache de l’hyperviseur

Voici quelque chose que j’ai mis deux jours à comprendre : dans une LPAR (Logical Partition) partagée, l’hyperviseur POWER préempte périodiquement les processeurs virtuels pour donner du temps à d’autres partitions. Ce faisant, il peut invalider des lignes de cache L2/L3.

La traversée du graphe du MHNSW est une chasse aux pointeurs à travers 300 Mo de mémoire – littéralement le pire scénario pour l’invalidation de la mémoire cache. Tu sautes de nœud en nœud, chacun dans une partie différente de la mémoire, et l’hyperviseur vide périodiquement ton cache.

C’est comme essayer de lire un livre alors que quelqu’un ne cesse de le fermer et de le remettre sur l’étagère.

Le système Linux avait des processeurs dédiés. Le système AIX fonctionnait avec des processeurs partagés. Ce ne sont pas des pommes pour des pommes.

Mais avant de pouvoir tester les processeurs dédiés, je devais résoudre le problème du compilateur.

Chapitre 4 : L’odyssée du compilateur

Tout ce que j’ai essayé avec GCC (et pourquoi ça a échoué)

TentativeRésultatPourquoi
-flto (Optimisation du temps de connexion)ImpossibleGCC LTO nécessite le format ELF ; AIX utilise XCOFF
-fprofile-generate (PGO)Échec de la constructionErreurs de l’assembleur concernant la relocalisation relative au TOC
-ffast-mathTout se casse la figureIEEE float violations corrupt bloom filter hashing
-funroll-loopsPlus lentCache d’instruction gonflé – POWER9 n’aime pas ça
-finline-functionsPlus lentMême problème de cache I

La boîte à outils AIX GCC est construite sans support LTO. Ce n’est pas un drapeau que tu as oublié – c’est architecturalement impossible parce que l’implémentation LTO de GCC nécessite ELF, et AIX utilise XCOFF.

Les paquets MariaDB d’Ubuntu utilisent -flto=auto. Cette optimisation n’existe tout simplement pas pour AIX avec GCC.

IBM Open XL : Le rebondissement de l’intrigue

À ce stade, j’ai passé trois jours à essayer de rendre GCC plus rapide. Il est temps d’essayer quelque chose de différent.

IBM Open XL C/C++ 17.1.3 est le compilateur moderne d’IBM, basé sur LLVM/Clang. Il génère un code nettement meilleur pour POWER9 que GCC.

Pour construire MariaDB avec Open XL, il a fallu résoudre cinq problèmes différents :

  1. En-tête HTM manquant: Open XL n’a pas le fichier htmxlintrin.h de GCC. J’ai créé un stub.
  2. AR 32 bits par défaut: Les outils AIX sont par défaut en 32 bits. Définis OBJECT_MODE=64.
  3. Incompatibilité LLVM AR: Open XL’s AR ne pouvait pas gérer XCOFF. Utilise le système /usr/bin/ar.
  4. Conflits OpenSSL: Utilise -DWITH_SSL=system pour éviter les problèmes liés à WolfSSL.
  5. Chemins d’accès aux bibliothèques manquants: Explicit -L/opt/freeware/lib pour l’éditeur de liens.

Ensuite, j’ai exécuté le test de référence :

Compilateur30 requêtesPar requête
GCC 13.3.00.190s6.3ms
Open XL 17.1.30.063s2.1ms

Trois fois plus rapide. Même code source. Mêmes drapeaux d’optimisation (-O3 -mcpu=power9).

Et voici le bonus : la variance du benchmark de GCC était de 10 à 40 % entre les exécutions. La variance d’Open XL était inférieure à 2 %. Il n’y a pratiquement pas de gigue.

Pourquoi une telle différence ?

Open XL (qui est basé sur LLVM) l’a fait :

  • Meilleure planification des instructions pour l’exécution hors ordre de POWER9
  • Attribution de registres supérieurs
  • Des passes d’optimisation plus agressives

Le backend POWER/XCOFF de GCC n’est tout simplement pas aussi mature. La boîte à outils AIX GCC est fonctionnelle, mais elle n’est pas optimisée pour les charges de travail critiques en termes de performances.

Chapitre 5 : Les impasses du LTO et du PGO

L’espoir est éternel. Peut-être que les LTO et PGO d’Open XL fonctionneraient ?

LTO : L’ironie

Open XL prend en charge -flto=full sur XCOFF. Il se construit vraiment ! Mais…

Résultat : 27 % plus lent que l’Open XL non LTO.

Pourquoi ? Les bibliothèques partagées AIX nécessitent une liste d’exportation explicite (exports.exp). Avec LTO, le script de CMake a vu ~27 000 symboles à exporter.

Le principal avantage de l’OLT est d’internaliser les fonctions, c’est-à-dire de les marquer comme étant locales afin qu’elles puissent être optimisées ou mises en ligne. Lorsque tu es obligé d’exporter 27 000 symboles, aucun d’entre eux ne peut être internalisé. Les frais généraux de l’OLT (fichiers intermédiaires plus volumineux, liaison plus lente) demeurent, mais l’avantage disparaît.

C’est comme si tu payais un abonnement à une salle de sport et qu’on te disait ensuite que tu ne peux utiliser aucun des équipements.

PGO : Les profils qui n’ont jamais existé

L’optimisation guidée par le profil semblait prometteuse :

  1. Construis avec -fprofile-generate
  2. Charge de travail pour l’entraînement à la course à pied
  3. Reconstruis avec -fprofile-use
  4. Profite d’un code plus rapide

L’étape 1 a fonctionné. Étape 2… les profils ne sont jamais apparus.

J’ai lié manuellement le runtime de profilage LLVM à la bibliothèque partagée. Toujours pas de profils.

La cause première : Le runtime de profilage de LLVM utilise atexit() ou __attribute__((destructor)) pour écrire des profils à la sortie. Sur AIX avec XCOFF, la sémantique des destructeurs de bibliothèques partagées est différente de celle d’ELF. Le gestionnaire n’est tout simplement pas appelé de manière fiable pour les configurations complexes à plusieurs bibliothèques comme MariaDB.

Les cas de test simples fonctionnent. Les applications réelles ne fonctionnent pas.

Chapitre 6 : La révélation LPAR

J’avais maintenant un compilateur rapide. Il est temps de tester les processeurs dédiés et d’éliminer le problème d’invalidation du cache de l’hyperviseur.

La matrice de test

Config LPARGCCOpen XL
12 vCPUs partagés0.190s0.063s
12 plafonds dédiés0.205s0.082s
21 dédiés plafonnés0.320s0.067s

Attends. Les services partagés sont plus rapides que les services dédiés ?

Le facteur WoF

POWER9 dispose d’une fonction appelée Workload Optimized Frequency (WoF). En mode partagé avec une faible utilisation, un seul cœur peut atteindre ~3,8 GHz. Les processeurs dédiés plafonnés sont bloqués à 2750 MHz.

Pour une requête à un seul fil, le mode partagé obtient 38 % de vitesse d’horloge en plus. Cela bat la pénalité d’invalidation du cache pour cette charge de travail.

Imagine que tu choisisses entre une voiture de sport sur une autoroute avec une circulation occasionnelle (partagée) et un camion avec une voie réservée mais une limite de vitesse (dédiée plafonnée).

Le désastre du mode donateur de PowerVM

Il existe une troisième option : les processeurs dédiés en mode “Donating”, qui redonnent les cycles inactifs au pool partagé.

ModeGCCOpen XL
Plafonné0.205s0.082s
Faire un don0.325s0.085s

60% de régression avec GCC.

Chaque fois qu’une requête explose, il y a un temps de latence pour récupérer les cycles donnés. Pour les charges de travail en rafale et à un seul fil, comme les requêtes de base de données, c’est dévastateur.

Recommandation: N’utilise jamais le mode Don pour les charges de travail des bases de données.

Le 21-Core Sweet Spot

Avec 21 cœurs dédiés (contre 24 pour Linux), Open XL a atteint 0,067s – égalant presque les 0,063s du mode partagé. Le cache L3 supplémentaire apporté par plus de cœurs compense l’absence d’augmentation de la fréquence du WoF.

Chapitre 7 : Le tableau d’affichage final (rebondissement)

Nouveaux benchmarks sur du matériel POWER9 identique, janvier 2026 :

PlateformeCœurs30 requêtes
Linux24 dédié0.057s
AIX + Open XL12 partagés0.063s
AIX + Open XL21 dédié0.067s
AIX + GCC12 partagé0.190s
AIX + GCC21 dédié0.320s

Attends. Le système AIX a 21 cœurs contre 24 pour Linux. Cela représente 12,5 % de cœurs en moins, ce qui signifie 12,5 % de cache L3 en moins.

L’écart mesuré ? 10-18%.

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

Avec IBM Open XL, AIX offre des performances par cœur identiques à celles de Linux. L’écart de 23x que nous avons constaté au début ? Il n’a jamais été question de la lenteur d’AIX. C’était le cas :

  1. Un cache mal configuré (16 Mo au lieu de 4 Go)
  2. Taille des pages incorrecte (4KB au lieu de 64KB)
  3. Le mauvais compilateur (GCC au lieu d’Open XL)

Le mythe “AIX est lent” est mort.

Le musée complet 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” :

Ce que nous avons essayéRésultatNotes
mhnsw_max_cache_size = 4GB5 fois plus rapideÉlimine les tressautements de la mémoire cache
LDR_CNTRL 64K pages~40% plus rapideRéduit les erreurs de la TLB
MAP_ANON_64K patch mmap~8% plus rapideAmélioration mineure du TLB
IBM Open XL 17.1.33x plus rapideMeilleur codegen POWER9
LPAR partagé (vs dédié)~25% plus rapideAugmentation de la fréquence du WoF
Open XL + LTO27% plus lentConflit d’exportation AIX
Open XL + PGONe fonctionne pasProfils non écrits
GCC LTOImpossibleXCOFF n’est pas pris en charge
GCC PGOÉchecs de constructionErreurs de relocalisation du TOC
-ffast-mathCasse MHNSWCorruption par flottaison
-funroll-loopsPireI-cache bloat
POWER VSX bloom filter41% plus lentPas de multiplication vec 64 bits sur P9
Préfixe logicielAucun effetL’hyperviseur évince les données préfixées
Réglage du DSCRBloquéL’hyperviseur contrôle le DSCR dans les LPAR partagés
Mode de don60% de régressionNe jamais utiliser pour les bases de données

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 que j’ai appris

1. Les défauts de paiement sont plus importants que tu ne le penses

Un cache de 16 Mo par défaut a transformé des requêtes de moins d’une milliseconde en requêtes de 24 ms. C’est une pénalité de 24x pour un seul paramètre mal configuré.

Lorsque tu portes un logiciel, remets en question tous les paramètres par défaut. Ce qui fonctionne sous Linux peut ne pas fonctionner sur ta plateforme.

2. Le mythe de la lenteur d’AIX a toujours été un problème de chaîne d’outils

Avec GCC, nous étions 3 à 4 fois plus lents que Linux. Avec Open XL, nous sommes au même niveau que Linux par cœur.

La plateforme n’a jamais été lente. La chaîne d’outils par défaut n’était tout simplement pas optimisée pour les charges de travail critiques en termes de performances. Choisis le bon compilateur.

3. La virtualisation comporte des compromis cachés

Les LPAR partagés peuvent être plus rapides que les LPAR dédiés pour les charges de travail monothématiques (augmentation de la fréquence du WoF). Le mode dédié est plus efficace pour les charges de travail multithreads soutenues. Le mode don est un piège.

Connais ta charge de travail. Choisis ta configuration LPAR en conséquence.

4. Tous les ports d’optimisation n’ont pas la même valeur

LTO, PGO et la vectorisation SIMD ont tous échoué sur AIX pour diverses raisons. Les techniques qui rendent Linux rapide ne se traduisent pas toujours.

Parfois, l’optimisation “évidente” est le mauvais choix. Mesure tout.

5. Parfois, il n’y a pas d’écart du tout

Nous avons passé des jours à enquêter sur un “écart de performance” qui s’est avéré être :

  • Erreurs de configuration
  • Mauvais compilateur
  • Moins de cœurs sur le système de test

La leçon à retenir : vérifie tes données de base. Assure-toi de comparer des pommes avec des pommes avant de supposer qu’il y a un problème à résoudre.

Recommandations

Pour les utilisateurs d’AIX MariaDB

  1. Utilise la version Open XL (version 3, bientôt disponible)
  2. Règle mhnsw_max_cache_size sur au moins 4 Go pour la recherche vectorielle
  3. Conserver le LPAR partagé pour une latence de requête unique
  4. N’utilise jamais le mode don pour les bases de données
  5. Utilise des pages de 64K via le wrapper LDR_CNTRL

Pour MariaDB en amont

  1. Augmente la valeur par défaut de mhnsw_max_cache_size – 16MB est beaucoup trop petit
  2. Mettre en œuvre l’éviction LRU – jeter tout le cache en cas de débordement est brutal.
  3. N’ajoute pas le filtre bloom POWER VSX – le scalaire est plus rapide sur POWER9

Prochaines étapes

Les RPM sont publiés sur aix.librepower.org. Release 2 includes the configuration fixes. La version 3 avec Open XL est également disponible.

Priorités immédiates:

  • Licence commerciale Open XL : L’évaluation expire bientôt. Il faut vérifier auprès d’IBM si nous sommes d’accord pour utiliser xLC à cette fin.
  • Implémentation native de l’AIO: AIX a POSIX AIO et IOCP compatible avec Windows. Il est temps d’écrire le backend InnoDB.
  • Retour d’information sur le MHNSW en amont: La valeur par défaut de mhnsw_max_cache_size (16 Mo) est trop faible pour les charges de travail réelles ; nous suggérerons une valeur par défaut plus élevée.

Pour les organisations qui exécutent déjà des charges de travail critiques sur AIX – et il y en a beaucoup, des banques aux compagnies aériennes en passant par les systèmes de santé – la possibilité d’exécuter également MariaDB moderne et performant ouvre de nouvelles possibilités.

AIX correspond à Linux. Le mythe est mort. Et MariaDB sur AIX est prêt pour la production.

TL;DR

  • Au départ, l’écart de performance était de 23x (42 QPS contre 971 QPS).
  • Configuration du cache corrigée : Amélioration de 5x
  • Taille de page fixe : ~40% de plus
  • Passage à IBM Open XL: amélioration de 3x par rapport à GCC
  • LPAR partagé utilisé : ~25% plus rapide que le dédié (WoF boost)
  • Résultat final : NO GAP – 10% de différence = 12,5% de cœurs en moins (21 vs 24)
  • AIX atteint les mêmes performances par cœur que Linux grâce à Open XL
  • Open XL LTO : n’aide pas (27% plus lent)
  • Open XL PGO : ne fonctionne pas (problème AIX XCOFF)
  • POWER VSX SIMD : 41% plus lent que le scalaire (pas de multiplication vec 64 bits)
  • Mode donateur : 60% de régression – ne jamais utiliser pour les bases de données
  • “AIX est lent pour les bases de données open source” a toujours été un mythe de la chaîne d’outils.

Des questions ? Des idées ? Tu utilises MariaDB sur AIX et tu veux partager ton expérience ?

This work is part of LibrePower – Unlocking IBM Power Systems through open source. Unmatched RAS. Superior TCO. Minimal footprint 🌍

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

MariaDB sur AIX | 3 Semaines de Développement Technique (Partie 1)

/dans /par

MariaDB sur AIX, la plateforme qui alimente les systèmes les plus critiques au 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 (partie 1) l’histoire de la dernière édition – et les raisons pour lesquelles 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: Défis de CMake pour MariaDB sur AIX

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: Implémentation du Thread Pool pour MariaDB sur AIX via Pollset

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 :

PlateformeAPIStatut
LinuxepollPris en charge
FreeBSD/macOSkqueuePris en charge
Solarisports d’événementsPris en charge
WindowsIOCPPris en charge
AIXpollsetNon pris en charge (jusqu’à présent)

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.

Porter MariaDB sur AIX = Bugs (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
  • Le travailleur fait appel à timeout=0 pour les vérifications non bloquantes.

Avec -O2, la synchronisation était telle que les collisions étaient rares. Avec -O3, le code était plus rapide, les collisions se produisaient plus souvent, et boom – race condition.

v11 (L’illumination)

La solution consistait à créer un mutex dédié protégeant à la fois pollset_poll et toutes les opérations de pollset_ctl:

static pthread_mutex_t pollset_mutex = PTHREAD_MUTEX_INITIALIZER;

int io_poll_wait(...) {
    pthread_mutex_lock(&pollset_mutex);
    ret = pollset_poll(pollfd, native_events, max_events, timeout);
    // ... process and delete events ...
    pthread_mutex_unlock(&pollset_mutex);
}

Oui, il sérialise l’accès au pollset. Oui, c’est théoriquement plus lent. Mais tu sais ce qui est encore plus lent ? Un serveur qui tombe en panne.

Le code final de la v11 a passé 72 heures de tests de résistance avec 1 000 connexions simultanées. Aucun plantage. Aucune fuite de mémoire. Aucun “paquet hors service”.

Chapitre 4 : La chose -blibpath (en fait une caractéristique)

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 5 : Stabilité – Les chiffres qui comptent

Après tout ce travail, où en sommes-nous ?

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 :

TestRésultat
100 connexions simultanées✓
500 connexions simultanées✓
1 000 connexions✓
30 minutes de charge soutenue✓
11+ millions de requêtes✓
Fuites de mémoireZÉRO

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.

Impact du pool de fils

Le travail sur le pool de threads a permis des gains massifs pour les charges de travail simultanées :

ConfigurationMélange de 100 clientspar rapport à la ligne de base
Original -O2 one-thread-per-connection11.34s–
-O3 + pool-of-threads v111.96s83% plus rapide

Pour les charges de travail OLTP à forte concordance, c’est la différence entre “lutter” et “voler”.

Ce que j’ai appris (jusqu’à présent)

  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.

Qu’est-ce qu’on fait maintenant ? La question de la performance

Le serveur est stable. Le pool de discussion fonctionne. Mais il y a une question en suspens à laquelle je n’ai pas encore répondu :

Quelle est sa rapidité par rapport à Linux ?

J’ai effectué un test de recherche vectorielle – le type d’opération qui permet d’améliorer les fonctions de recherche de l’IA. Index MHNSW (Hierarchical Navigable Small World) de MariaDB, 100 000 vecteurs, 768 dimensions.

Linux sur du matériel POWER9 identique : 971 requêtes par seconde.

AIX avec notre nouvelle version : 42 requêtes par seconde.

Vingt-trois fois plus lent.

Mon cœur s’est effondré. Trois semaines de travail, et nous sommes 23x plus lents que Linux ? Sur un matériel identique?

Mais voici ce qu’il en est de l’ingénierie : lorsque les chiffres n’ont pas de sens, il y a toujours une raison. Et parfois, cette raison s’avère être une bonne nouvelle surprenante.

Dans la deuxième partie, je couvrirai :

  • Comment nous avons découvert que l’écart de 23x était surtout une erreur de configuration.
  • Le compilateur qui a tout changé
  • Pourquoi “AIX est lent” s’est avéré être un mythe
  • Le “musée des échecs” complet des optimisations qui n’ont pas fonctionné.

Les RPM sont publiés sur aix.librepower.org. La version GCC est stable et prête pour la production.

Mais l’histoire de la performance ? C’est là que les choses deviennent vraiment intéressantes.

La deuxième partie arrive bientôt.

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).
  • Le serveur est stable: 1 000 connexions, plus de 11 millions de requêtes, aucune fuite de mémoire.
  • Le pool de threads offre une amélioration de 83 % pour les charges de travail simultanées
  • Le premier test de recherche vectorielle montre un écart de 23x par rapport à Linux – mais est-ce que c’est tout ?
  • RPMs publiés sur aix.librepower.org
  • La deuxième partie sera bientôt disponible: L’enquête sur les performances

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

Ce travail fait partie de LibrePower – Unlocking IBM Power Systems through open source. RAS inégalé. Coût total de possession supérieur. Empreinte minimale 🌍

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

LLMs sur AIX : expérimentation technique au-delà de l’engouement pour les GPUs

/dans /par

À LibrePower, nous avons publié Llama-AIX: une preuve de concept pour exécuter l’inférence de modèle LLM léger directement sur AIX 7.x, en utilisant seulement le CPU et la mémoire, sans GPU.

Il faut être clair dès le départ : il s’agit d’amusement technique et d’expérimentation, pas d’un produit, pas d’une promesse commerciale, pas d’une alternative aux grandes plateformes d’IA accélérées par le GPU.

Cela dit, l’expérience repose sur une base technique solide.

La théorie : tous les cas d’utilisation du LLM ne sont pas liés au GPU.

Dans de nombreux scénarios professionnels courants dans les environnements Power :

  • RAG (Retrieval Augmented Generation)
  • Questions sur la documentation interne
  • Assistants techniques sur place
  • Recherche sémantique sur ses propres connaissances
  • Analyse de texte fortement dépendante de la latence et de la proximité des données.

Le goulot d’étranglement n’est pas toujours le calcul de la masse, mais.. :

  • CPU
  • Largeur de la mémoire
  • Temps de latence de l’accès aux données
  • Localisation des données

Dans ces cas, les inférences petites et bien délimitées peuvent être raisonnablement exécutées sans GPU, surtout lorsque le modèle n’est pas le centre du système, mais juste une autre pièce du système.

⚙️ CPU, MMA et accélérateurs basse consommation

L’évolution naturelle ne concerne pas seulement les GPU :

  • Des processeurs de plus en plus vectorisés
  • Extensions en tant que MMA
  • Accélérateurs dédiés et économes en énergie (comme le futur Spyre).
  • Intégration plus étroite avec le système d’exploitation et la pile de données

Ce type d’accélération est particulièrement pertinent dans les architectures de puissance, où la conception donne la priorité au débit soutenu, à la cohérence et à la fiabilité, et pas seulement aux pics de FLOPS.

🧩 Pourquoi AIX ?

L’exécuter sur AIX n’est pas une nécessité, c’est un choix conscient :

  • Comprendre les limites réelles
  • Explorer sa faisabilité technique
  • Démonter les hypothèses simplistes
  • Apprendre comment les LLM s’intègrent dans les systèmes d’alimentation existants

De nombreux clients Power exploitent des infrastructures stables, amorties et critiques, où le déplacement des données vers le cloud ou l’introduction de GPU n’est pas toujours souhaitable ou viable.

🔍 Ce qui est (et ce qui n’est pas) Llama-AIX

  • ✔ Un PoC technique
  • ✔ Une exploration honnête
  • ✔ Un exercice d’ingénierie
  • ✔ Source ouverte
  • ✖ Pas un benchmark
  • ✖ Pas une plateforme d’IA complète
  • ✖ Pas destinée à concurrencer les solutions GPU
  • ✖ Pas de ” marketing de l’IA “.

L’idée est simple : voir au-delà du battage médiatique, comprendre les nuances et évaluer où les LLM apportent une réelle valeur dans les environnements Power et AIX.

Purement par curiosité technique.

Et parce que l’expérimentation reste un élément fondamental de l’ingénierie.

Dans quel cas d’utilisation spécifique un LLM in Power sur site aurait-il du sens pour toi ?

SIXE