Notes relatives à Linux (toutes versions)

Cette section présente les problèmes que nous avons rencontré avec Linux. Les premières sections décrivent les problèmes liés aux opérations générales, les problèmes qui arrivent avec les distributions binaires ou source, puis les problèmes de post-installation. Les autres sections discutent de problèmes qui surviennent sur des plates-formes spécifiques.

Notez que la plupart des problèmes surviennent sur les anciennes versions de Linux. Si vous utilisez une version récente, vous ne les verrez jamais ou presque.

2.8.1.1. Notes sur Linux

MySQL requiert au moins Linux Version 2.0.

Attention : Nous avons rencontré d'étranges problèmes avec Linux 2.2.14 et MySQL sur des architectures SMP. Nous avons aussi des rapports d'utilisateurs MySQL qui ont rencontré de sérieux problèmes de stabilité avec le noyau 2.2.14. Si vous utilisez ce noyau, il est recommandé de passer en version 2.2.19 (ou plus récente) ou en 2.4. Si vous avez un serveur multi-processeurs, vous devriez considérer sérieusement la migration vers la version 2.4 car elle vous apportera un gain de vitesse significatif. Votre système sera aussi plus stable.

Lorsque vous utilisez lesLinuxThreads, vous verrez un minimum de trois processusmysqld. Ce sont en fait des threads. Il y a un thread de gestionLinuxThreads, un thread pour gérer les connexions et un thread pour gérer les alertes et signaux.

2.8.1.2. Notes relatives à Linux pour les distributions binaires

MySQL requière au moins la version 2.0 de Linux.

Attention : Certains utilisateurs de MySQL nous ont avertis qu'ils ont rencontré de graves problèmes de stabilité avec MySQL et le noyau 2.2.14 de Linux. Si vous utilisez ce noyau, vous devez mettre à jour à la 2.2.19 (ou plus récent) ou a un noyau 2.4. Si vous utilisez un ordinateur multi-processeurs, vous devriez sérieusement songer à passer au noyau 2.4 qui vous apportera de grandes performances niveau vitesse.

La version binaire est liée avec-static, ce qui signifie que normalement vous n'avez pas besoin de vous soucier des versions des bibliothèques système que vous avez. Vous n'avez pas besoin d'installerLinuxThreadsnon plus. Un programme lié avec-static est légèrement plus grand qu'un programme liée dynamiquement mais aussi un peu plus rapide (3-5%). Un problème, toutefois, est que vous ne pouvez utiliser de fonctions définies par l'utilisateur avec un programme lié statiquement. Si vous allez écrire ou utiliser des fonctionsUDF(c'est réservé aux développeurs C ou C++), vous devez compiler MySQL vous-même, en utilisant les liaisons dynamiques.

Si vous utilisez un système basé surlibc(au lieu deglibc2), vous aurez probablement quelques problèmes de résolution des noms d'hôtes et des problèmes avecgetpwnam()avec les versions binaires. (Cela vient du fait queglibcdépend malheureusement de quelques bibliothèques externes pour résoudre les noms d'hôtes etgetpwent(), même quand elle est compilée avec-static). Dans ce cas, vous obtiendrez probablement l'erreur suivante quand vous exécuterezmysql_install_db:

Sorry, the host 'xxxx' could not be looked up

ou l'erreur suivante quand vous essayez de démarrermysqldavec l'option--user:

getpwnam: No such file or directory

Vous pouvez résoudre ce problème de la fa¸on suivante :

• Obtenez une distribution des sources MySQL (un distributionRPMou letar.gz) et installez la à la place.

• Exécutezmysql_install_db --force; cela n'exécutera pas le testresolveipdansmysql_install_db. Le mauvais côté est que vous ne pourrez pas utiliser de noms d'hôtes dans les tables de droits; vous devez utiliser les adresses IP à la place (sauf

pourlocalhost). Si vous utilisez une vielle version de MySQL qui ne supporte pas--force, vous devez supprimer le test resolveipdansmysql_installà l'aide d'un éditeur.

• Démarrezmysqldavecsuau lieu d'utiliser--user.

Le binaire Linux-Intel et lesRPMde MySQL sont configurés pour la vitesse la plus grande possible. Nous essayons toujours d'utiliser le compilateur le plus rapide disponible.

Le support Perl de MySQL requière la version 5.004_03 de Perl ou plus récent.

Sur quelques version de Linux 2.2, vous pouvez obtenir l'erreurResource temporarily unavailablequand vous faites beaucoup de nouvelles connexions à un serveurmysqlden utilisant TCP/IP.

Le problème est que Linux possède un délai entre votre fermeture de la socket TCP/IP et sa libération par le système. Vu qu'il y a un nombre fini de places pour les branchements TCP/IP, vous obtiendrez l'erreur précédente si vous essayez de faire beaucoup de connexions TCP/IP en peu de temps, comme quand vous exécutez le benchmark MySQLtest-connectvia TCP/IP.

Nous avons envoyé des questions plusieurs fois à propos de ce problème à différentes listes de diffusions Linux mais n'avons jamais réussi à résoudre ce problème proprement.

Le seul correctif connu pour ce problème est d'utiliser des connexions persistantes dans vos clients ou d'utiliser les sockets, si vous utilisez le serveur de bases de données et le client sur la même machine. Nous espérons que le noyau deLinux 2.4corrigera ce problème bientôt.

2.8.1.3. Notes sur la distribution source de Linux

Les notes suivantes concernantglibcne 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 deglibcque 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 lesLinuxThreadssur Linux. Si vous utilisez une vieille version de Linux qui n'a pasglibc2, vous devrez installer LinuxThreadsavant de compiler MySQL. Vous pouvez obtenirLinuxThreadssur

http://dev.mysql.com/downloads/os-linux.html.

Notez que les versions deglibcavant 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 commandesINSERT DELAYED. Nous vous recommandons de ne pas utiliserINSERT DELAYEDavant de mettre à jourglibc.

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

• AugmentezPTHREAD_THREADS_MAXdanssysdeps/unix/sysv/linux/bits/local_lim.hà 4096 et réduisez STACK_SIZEdanslinuxthreads/internals.hà 256 ko. Les chemins sont relatifs à la racine deglibc. (Notez que MysQL ne sera pas stable autour de 600 à 1000 connexions siSTACK_SIZEvaut les 2 Mo par défaut.

• RecompilezLinuxThreadspour avoir un nouveaulibpthread.a, et recompilez MySQL avec.

La pagehttp://www.volano.com/linuxnotes.htmlcontient 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 deLinuxThreadsdansglibc2.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 deLinuxThreads, supprimer des processeurs de votre architecture va améliorer les performances. Nous avons fait un correctif deglibc2.1.3 pour corriger ce comportement (http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch).

Avecglibc2.2.2, MySQL 3.23.36 va utiliser un mutex adaptatif, qui est bien meilleur que la version corrigée deglibc2.1.3. Soyez prévenu, que dans certaines conditions, le code courant du mutex deglibc2.2.2 surchauffe, ce qui bride MySQL. La probabilité de

Installer MySQL

rencontrer cette condition sera réduite en donnant àmysqldla 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 dossierlinuxthreadsavecpatch -p0 </tmp/linuxthreads-2.2.2.patch. Nous espérons qu'il sera inclut dans une version future deglibc2.2. Dans tous les cas, si vous compilez avecglibc2.2.2, vous devrez corrigerSTACK_SIZEetPTHREAD_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 delibpthread.aet 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 lesLinuxThreadsavec 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 :

• Compilez le client avec l'option-Wl,r/full/path/to/libmysqlclient.soplutôt que-Lpath).

• Copiezlibmysqclient.sodans/usr/lib.

• Ajoutez le chemin du dossier oùlibmysqlclient.soest situé dans la variable d'environnementLD_RUN_PATHavant de lancer votre client.

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 configurationconfiguredevrait fonctionner avecfcc/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

2.8.1.4. Notes de post-installation pour Linux

mysql.serverest stocké dans le dossiersupport-filesdans le dossier d'installation MySQL, ou dans le dossier des sources.

Vous pouvez l'installer dans/etc/init.d/mysqlpour assurer le démarrage et l'extinction automatique de MySQL. See Section 2.5.2.2, « Lancer et arrêter MySQL automatiquement ».

Si MySQL n'arrive pas à ouvrir assez de fichiers, ou à créer assez de connexions, il se peut que vous n'ayez pas configuré Linux pour qu'il gère assez de fichiers.

Dans Linux 2.2 ou plus, vous pouvez connaître le nombre de gestionnaires de fichiers alloués en faisant :

shell> cat /proc/sys/fs/file-max shell> cat /proc/sys/fs/dquot-max shell> cat /proc/sys/fs/super-max

Si vous avez plus de 16 Mo de mémoire, vous devez ajouter quelque chose comme ce qui suit dans vos scripts d'initialisation (/

etc/init.d/boot.localsur SuSE Linux) :

echo 65536 > /proc/sys/fs/file-max echo 8192 > /proc/sys/fs/dquot-max echo 1024 > /proc/sys/fs/super-max

Vous pouvez aussi exécuter les commandes précédentes à partir de la ligne de commande en tant que root, mais les changements seront perdus au prochain redémarrage de l'ordinateur.

Vous pouvez sinon définir ces paramètres lors du démarrage de la machine en utilisant l'outilsysctl, qui est utilisé par plusieurs distributions Linux (SuSE l'a aussi ajouté, à partir de SuSE Linux 8.0). Ajoutez simplement les valeurs suivantes dans un fichier nommé /etc/sysctl.conf:

# Increase some values for MySQL fs.file-max = 65536

fs.dquot-max = 8192 fs.super-max = 1024

Il est recommandé d'ajouter aussi la ligne suivante dans le fichier/etc/my.cnf:

[mysqld_safe]

open-files-limit=8192

Cela va autoriser le serveur à un maximum de 8192 de connexions et fichiers ouvertes simultanément.

La constanteSTACK_SIZEdesLinuxThreadscontrôle l'espacement des piles de threads dans l'espace d'adressage. Elle doit être assez grande pour qu'il y ait plusieurs chambres pour la pile de chaque thread individuel, mais assez petite pour empêcher les piles de certains threads d'agir sur les données globales demysqld. Malheureusement, l'implémentation Linux demmap(), comme nous l'avons découvert, va libérer une région réservée, si vous lui demandez de libérer une adresse déjà utilisée, détruisant les données de la page, au lieu de retourner une erreur. Donc, la sécurité demysqldet des autres applications qui dépendent d'un comportement civils du code qui gère les threads. L'utilisateur doit s'assurer que le nombre de threads fonctionnant simultanément est suffisamment bas pour éviter d'entrer dans la pile globale. Avecmysqld, vous devez suivre cette règle de bon fonctionnement en donnant une valeur raisonnable àmax_connections.

Si vous compilez MySQL vous-mêmes, vous pouvez corrigerLinuxThreadspour améliorer l'utilisation de la pile. See Section 2.8.1.3, « Notes sur la distribution source de Linux ». Si vous ne voulez pas corrigerLinuxThreads, vous ne devez pas dépasser 500 pour la valeur demax_connections. Cela devrait même être moins si vous avez un tampon de clefs assez large, de grosses tables heap, ou d'autres choses qui peuvent faire allouer beaucoup de mémoire àmysqld, ou si vous utilisez un noyau 2.2 avec un patch 2G. Si vous utilisez notre binaire ouRPM3.23.25 ou plus, vous pouvez mettremax_connectionsà 1500 sans problèmes, en supposant que vous n'avez ni de grosses tables heap ni grands tampons de clefs. Plus vous réduirezSTACK_SIZEdans

LinuxThreadsplus les threads créés seront sûrs. Nous recommandons une valeur entre 128 ko et 256 ko.

Si vous utilisez beaucoup de connexions simultanées, vous pouvez souffrir d'une ``fonctionnalité'' du noyau 2.2, qui tente d'éviter les DOS par fork en pénalisant les processus qui forkent ou qui clonent des fils. Cela fait que MySQL ne se comporte pas bien si vous augmentez le nombre de clients simultanés. Sur les systèmes mono-processeurs, nous avons vu des symptômes sous la forme de ralentissement : il prenait un très long temps pour se connecter (parfois une minute), et il fallait autant de temps pour terminer le processus. Sur les systèmes multi-processeurs, nous avons observé une décroissance graduelle des performances des requêtes chez de nombreux clients. Durant nos recherches pour corriger le problème, nous avons re¸u un patch d'un client qui prétendait avoir résolu le problème pour son site. Ce patch est disponible surhttp://www.mysql.com/Downloads/Patches/linux-fork.patch. Nous avons maintenant fait des tests exhaustifs de ce patch en développement et en production. Il a amélioré significativement les performances sans causer de problèmes, et nous l'avons recommandé à nos utilisateurs qui fonctionnent avec des serveurs chargés et un noyau 2.2.

Ce problème a été réglé avec le noyau 2.4 : si vous n'êtes pas satisfait avec les performances courantes de votre système, au lieu de le corriger, passez donc votre noyau 2.2 en 2.4. Sur les systèmes multi-processeurs, la mise à jour vous donnera d'ailleurs un regain de puissance, en plus de corriger le bug.

Nous avons testé MySQL sur des noyaux 2.4 et sur des machines bi-processeurs, et nous avons trouvé que MySQL se comporte beaucoup mieux. Il n'y avait pratiquement pas de ralentissement de requêtes même avec 1000 client, et gain de puissance était de 180%

(calculé avec le ratio de vitesse maximale divisé par la vitesse moyenne d'un client). Nous avons observé des résultats similaires sur une machine quadri-processeurs : virtuellement aucun ralentissement alors que le nombre de clients est monté jusqu'à 1000, et le gain de puissance a atteind 300%. En se basant sur ces résultats, pour un serveur haute performances multi-processeurs, nous vous

recommandons de passer en noyau 2.4.

Nous avons découvert qu'il est essentiel de faire fonctionner les processusmysqldavec la priorité maximal sur le noyau 2.4 pour atteindre les meilleures performances. Cela peut se faire en ajoutant la commanderenice -20 $$dansmysqld_safe. Durant nos tests sur une machine quadri-processeurs, augmenter la priorité a engendré 60% d'amélioration avec 400 clients.

Nous essayons aussi de rassembler plus d'informations sur comment MySQL se comporte sur un système 2.4 quadri- ou octo-processeurs. Si vous avez accès a de telles données, envoyez nous un email à<benchmarks@mysql.com>avec les résultats. Nous allons les étudier pour les inclure dans le manuel.

Installer MySQL

Si vous voyez un processusmysqldmort avecps, c'est que vous avez découvert un bug dans MySQL ou qu'une des tables est corrompue. SeeSection A.4.2, « Que faire si MySQL plante constamment ? ».

Pour obtenir uncore dumpsur Linux simysqldse termine avec un signalSIGSEGV, vous pouvez lancermysqldavec l'option --core-file. Notez que vous aurez probablement à augmenter la taille du fichier core en ajoutant la commandeulimit -c 1000000àmysqld_safeou en lan¸antmysqld_safeavec--core-file-size=1000000. SeeSection 5.1.3,

«safe_mysqld, le script père demysqld».

2.8.1.5. Notes relatives à Linux x86

MySQL requière la version 5.4.12 delibcou plus récent. Il est connu pour fonctionner aveclibc5.4.46. La version 2.0.6 deglibc ou plus récente devrait aussi fonctionner. Il y a eu quelques problèmes avec lesRPMdeglibcde Red Hat, et donc, si vous avez des problèmes, vérifiez s'il existe des mises à jour ! LesRPMdeglibc2.0.7-19 et 2.0.7-29 sont connus pour fonctionner.

Si vous utilisezgcc3.0 ou plus récent pour compiler MySQL, vous devez installer la bibliothèquelibstdc++v3avant de compiler MySQL; si vous ne le faites pas vous obtiendrez une erreur à propos d'un symbole__cxa_pure_virtualmanquant durant la liaison! Pour corriger ce problème, lancezmysqldavec l'option--thread-stack=192K. Utilisez la syntaxe-O

thread_stack=192Kavant MySQL 4.) La taille de la pile est maintenant par défaut pour les versions MySQL 4.0.10 et plus récente, alors vous ne devriez pas rencontrer de problème.

Si vous utilisezgcc3.0 et plus récent pour compiler MySQL, vous devez installer la bibliothèquelibstdc++v3avant de compiler MySQL; si vous ne le faites pas, vous aurez des erreurs à propos de__cxa_pure_virtualqui manque, durant la résolution des symboles.

Sur quelques vieilles distributions de Linux,configurepeut produire une erreur comme celle qui suit :

Syntax error in sched.h. Change _P to __P in the /usr/include/sched.h file.

See the Installation chapter in the Reference Manual.

Faites ce que le message d'erreur dit et ajoutez un_à la macro_Pqui n'en a qu'un, puis essayez à nouveau.

Vous pouvez obtenir quelques avertissements en compilant; celles qui suivent peuvent être ignorées :

mysqld.cc -o objs-thread/mysqld.o

mysqld.cc: In function `void init_signals()':

mysqld.cc:315: warning: assignment of negative value `-1' to

`long unsigned int'

mysqld.cc: In function `void * signal_hand(void *)':

mysqld.cc:346: warning: assignment of negative value `-1' to

`long unsigned int'

Simysqldprovoque toujours un plantage au démarrage, le problème peut être que vous avez un vieux/lib/libc.a. Renommez le, puis supprimezsql/mysqldet faites à nouveau unmake installpuis réessayez. Ce problème a été reporté sur quelques

Simysqldprovoque toujours un plantage au démarrage, le problème peut être que vous avez un vieux/lib/libc.a. Renommez le, puis supprimezsql/mysqldet faites à nouveau unmake installpuis réessayez. Ce problème a été reporté sur quelques

Dans le document Installation de MySQL avec l’assistant – Cours et formation gratuit (Page 134-140)