Les notes suivantes concernant glibc ne s'appliquent que si vous compilez vous-mêmes MySQL. Si vous utilisez Linux sur une machine x86, dans la plupart des cas, il est mieux d'utiliser notre bibliothèque. Nous compilons nos exécutables avec les meilleures versions corrigées de glibc que nous pouvons trouver, avec les meilleures options de compilation possible, pour faire que notre serveur supporte les hautes charges. Pour un utilisateur typique, même pour une configuration avec de nombreuses connexions ou des tables dépassant les 2 Go, notre programme est meilleur choix. Après avoir lu ce texte, si vous doutez toujours, testez notre compilation pour voir si elle répond à vos besoins. Si vous pensez qu'elle n'est pas à la hauteur, alors essayez de compiler par vous-mêmes. Dans ce cas, nous apprécierons de savoir ce que vous avez fait, pour pouvoir améliorer notre propre version.

MySQL utilise les LinuxThreads sur Linux. Si vous utilisez une vieille version de Linux qui n'a pas glibc2, vous devrez installer LinuxThreads avant de compiler MySQL. Vous pouvez obtenir LinuxThreads sur http://dev.mysql.com/downloads/os-linux.html.

Notez que les versions de glibc avant et incluant la version 2.1.1 ont un bug critique dans la gestion de pthread_mutex_timedwait(), qui est utilisée lorsque vous envoyez des commandes INSERT DELAYED. Nous vous recommandons de ne pas utiliser INSERT DELAYED avant de mettre à jour glibc.

Notez que le noyau Linux et la bibliothèque LinuxThreads sont limitées par défaut à 1024. Si vous envisagez d'avoir plus de 1000 connexions simultanées, vous aurez besoin de faire des changement dans LinuxThreads :

La page http://www.volano.com/linuxnotes.html contient des informations supplémentaires pour contourner cette limite de LinuxThreads.

Il y a un autre problème qui limite considérablement les performances de MySQL, notamment sur des systèmes multi-processeurs. L'implémentation mutex de LinuxThreads dans glibc 2.1 est très mauvaise pour les programmes ayant de nombreux threads qui gardent le mutex pour une courte période de temps. Cela produit un résultat paradoxal : si vous compilez MySQL avec un version originale de LinuxThreads, supprimer des processeurs de votre architecture va améliorer les performances. Nous avons fait un correctif de glibc 2.1.3 pour corriger ce comportement (http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch).

Avec glibc 2.2.2, MySQL 3.23.36 va utiliser un mutex adaptatif, qui est bien meilleur que la version corrigée de glibc 2.1.3. Soyez prévenu, que dans certaines conditions, le code courant du mutex de glibc 2.2.2 surchauffe, ce qui bride MySQL. La probabilité de rencontrer cette condition sera réduite en donnant à mysqld la plus haute priorité. Nous avons été capable de corriger le problème avec un correctif, disponible à http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch. Il combine la correction avec l'augmentation du nombre limite de threads et de la taille de pile. Vous devez l'appliquer dans le dossier linuxthreads avec patch -p0 </tmp/linuxthreads-2.2.2.patch. Nous espérons qu'il sera inclut dans une version future de glibc 2.2. Dans tous les cas, si vous compilez avec glibc 2.2.2, vous devrez corriger STACK_SIZE et PTHREAD_THREADS_MAX. Nous espérons que les valeurs par défaut seront corrigées et remplacées par des valeurs plus raisonnables pour les configurations à haut rendement de MySQL : les manipulations futures pour compiler MySQL seront alors réduites à ./configure; make; make install.

Nous recommandons que vous utilisiez ces correctifs pour compiler une version spéciale statique de libpthread.a et que vous l'utilisiez pour compiler MySQL. Nous savons que les correctifs sont sécuritaires pour MySQL, et améliore significativement les performances, mais nous ne pouvons pas nous avancer pour les autres applications. Si vous compilez d'autres applications qui requièrent les LinuxThreads avec la version statique corrigée de la bibliothèque, faîtes le à vos risques et périls.

Si vous rencontrez des problèmes étranges durant l'installation de MySQL, ou si vous voyez les utilitaires se geler, il est très probable que vous ayez un problème de compilateur ou de bibliothèque. Dans ce cas, utiliser notre binaire résoudra vos problèmes.

Si vous compilez vos propres clients MySQL, vous pouvez rencontrer l'erreur suivante durant l'exécution :

ld.so.1: fatal: libmysqlclient.so.#:
open failed: No such file or directory

Ce problème peut être évité avec les méthodes suivantes :

Si vous utilisez le compilateur Fujitsu (fcc/FCC), vous aurez des problèmes pour compiler MySQL car le fichier d'entête Linux est très orienté gcc. La ligne de configuration configure devrait fonctionner avec fcc/FCC :

CC=fcc CFLAGS="-O -K fast -K lib -K omitfp -Kpreex -D_GNU_SOURCE \
    -DCONST=const -DNO_STRTOLL_PROTO" \
CXX=FCC CXXFLAGS="-O -K fast -K lib \
    -K omitfp -K preex --no_exceptions --no_rtti -D_GNU_SOURCE \
    -DCONST=const -Dalloca=__builtin_alloca -DNO_STRTOLL_PROTO \
    '-D_EXTERN_INLINE=static __inline'" \
./configure \
    --prefix=/usr/local/mysql --enable-assembler \
    --with-mysqld-ldflags=-all-static --disable-shared \
    --with-low-memory