Notes sur la distribution source de Linu

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

: Augmentez PTHREAD_THREADS_MAX

dans sysdeps/unix/sysv/linux/bits/local_lim.h

à 4096 et réduisez STACK_SIZE

dans linuxthreads/internals.h

à 256 ko. Les chemins sont relatifs à la racine de glibc

. (Notez que MysQL ne sera pas stable autour de 600 à 1000 connexions si STACK_SIZE

vaut les 2 Mo par défaut.

•

Recompilez LinuxThreads

pour avoir un nouveau libpthread.a

, et recompilez MySQL

avec.

•

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 : Compilez le client avec l'option −Wl,r/full/path/to/libmysqlclient.so

plutôt que −Lpath

). • Copiez libmysqclient.so dans /usr/lib . •

Ajoutez le chemin du dossier où libmysqlclient.so

est situé dans la variable d'environnement

LD_RUN_PATH

avant 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 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

2.6.1.4 Notes de post−installation pour Linux mysql.server

est stocké dans le dossier support−files

dans le dossier d'installation MySQL, ou dans le dossier des sources. Vous pouvez l'installer dans /etc/init.d/mysql

pour assurer le démarrage et l'extinction automatique de MySQL. Lancer et arrêter automatiquement MYSQL .

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.local

sur 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'outil sysctl

, 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 constante STACK_SIZE

des LinuxThreads

contrô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 de mysqld

. Malheureusement, l'implémentation Linux de mmap()

, 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é de

mysqld

et 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. Avec mysqld

, 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 corriger LinuxThreads

pour améliorer l'utilisation de la pile. Notes pour les distributions sources de Linux . Si vous ne voulez pas corriger LinuxThreads

, vous ne devez pas dépasser 500 pour la valeur de max_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 ou RPM

3.23.25 ou plus, vous pouvez mettre max_connections

à 1500 sans problèmes, en supposant que vous n'avez ni de grosses tables heap ni grands tampons de clefs. Plus vous réduirez STACK_SIZE

dans LinuxThreads

plus 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 sur

http://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 processus mysqld

avec la priorité maximal sur le noyau 2.4 pour atteindre les meilleures performances. Cela peut se faire en ajoutant la commande renice −20 $$

dans mysqld_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.

Si vous voyez un processus mysqld

mort avec ps

, c'est que vous avez découvert un bug dans MySQL ou qu'une des tables est corrompue. Que faire si MySQL crashe constamment .

Pour obtenir un core dump

sur Linux si mysqld

se termine avec un signal SIGSEGV

, vous pouvez lancer mysqld

avec l'option −−core−file

. Notez que vous aurez probablement à augmenter la taille du fichier core en ajoutant la commande ulimit −c 1000000

à mysqld_safe

ou en lançant mysqld_safe

avec −−core−file−size=1000000

.

safe_mysqld

, le script père de mysqld

.

Dans le document [PDF] Manuel MySQL 4 apprendre les principaux bases sur les bases de donnees MySql | Cours mysql (Page 154-158)