Notes relatives `a Linux (toutes versions)

Les notes suivantes relatives `a glibc ne s’appliquent que dans la situation o`u vous constru- isez MySQL vous-mˆeme. Si vous n’utilisez pas Linux sur une machine x86 machine, dans la plupart des cas, il sera mieux pour vous d’utiliser nos binaires. Nous lions nos binaires avec la meilleur version patch´ee de glibc que nous pouvons fournir et avec les meilleurs options du compilateur, en essayant de les rendre bons pour un serveur qui connait de fortes charges. Et donc, si vous lisez le texte suivant et que vous avez un doute sur ce que vous devez faire, essayez d’abord notre binaire pour voir s’il vous convient, et ne vous souciez de vosz propres constructions qu’apr`es vous ˆetre assur´es que notre binaire ne r´epond pas `a vos attentes. Dans ce cas, nous appr´ecierons une note `a propos de cela, pour que nous puissions faire mieux la prochaine fois. Pour les besoins d’un utilisateur de base, pour des

configurations avec beaucoup de connexions et/ou des tables d´epassant la limite des 2G, notre binaire est dans la plupart des cas le meilleur choix.

MySQL utilise LinuxThreads sur Linux. Si vous utilisez une vielle version de Linux qui ne poss`ede pas glibc2, vous devz installer LinuxThreads avant d’essayer de compiler MySQL. Vous pouvez obtenir LinuxThreads `a l’adresse suivante : http://www.mysql.com/downloads/os-linux.html.

Note : Nous avons rencontr´e quelques probl`emes ´etranges avec Linux 2.2.14 et MySQL sur les syst`emes SMP. Si vous avez un syst`eme SMP, nous vous recommandons de mettre `a jour `a Linux 2.4 d`es que possible ! Votre syst`eme n’en sera que plus rapide et plus stable ! Notez que les versions de glibc inf´erieure ou ´egale `a la 2.1.1 ont un bogue fatal dans la gestion de pthread_mutex_timedwait, qui est utilis´e lors que vous ex´ecutez INSERT DELAYED. Nous vous recommandons de ne pas utiliser INSERT DELAYED avant de mettre `a jour glibc.

Si vous planifiez d’avoir plus de 1000 connexions simultan´ees, vous aurez be- soin d’apporter quelques modifications `a LinuxThreads, le recompiler, et relier MySQL avec le nouveau ‘libpthread.a’. Augmentez PTHREAD_THREADS_MAX dans ‘sysdeps/unix/sysv/linux/bits/local_lim.h’ `a 4096 et diminuez STACK_SIZE dans ‘linuxthreads/internals.h’ `a 256 KB. Les chemins sont relatifs `a la racine de glibc. Notez que MySQL ne sera pas stable autour de 600-1000 connexions si STACK_SIZE est `a 2 MB (par d´efaut).

Si MySQL n’arrive pas `a ouvrir assez de fichiers, ou `a cr´eer assez de connexions, il se peut que vous n’ayez pas configur´e Linux pour qu’il g`ere assez de fichiers.

Dans Linux 2.2 ou plus, vous pouvez connaitre le nombre de gestionnaires de fichiers allou´es en faisant :

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

Si vous avez plus de 16 MB de m´emoire, vous devez ajouter qauelque 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´ecuter les commandes pr´ec´edentes `a partir de la ligne de commande en tant que root, mais les changements seront perdus au prochain red´emarrage de l’ordinateur. Vous pouvez sinon d´efinir ces param`etres lors du d´emarrage de la machine en utilisant l’outil sysctl, qui est utilis´e par plusieurs distributions Linux (SuSE l’a aussi ajout´e, `a partir de SuSE Linux 8.0). Ajoutez simplement les valeurs suivantes dans un fichier nomm´e ‘/etc/sysctl.conf’ :

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

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

[safe_mysqld]

open-files-limit=8192

Cela devrait permettre `a MySQL de cr´eer jusqu’`a 8192 fichiers de conexion.

La constante STACK_SIZE des LinuxThreads contrˆole l’espacement des piles de threads dans l’espace d’adressage. Elle doit ˆetre assez grande pour qu’il y ait plusieurs chambres pour la pile de chaque thread individuel, mais assez petite pour empˆecher les piles de certains threads d’agir sur les donn´ees globales de mysqld. Malheureusement, l’impl´ementation Linux de mmap(), comme nous l’avons d´ecouvert, will successfully unmap an already mapped region if you ask it to map out an address already in use, zeroing out the data on the entire page, instead of returning an error. So, the safety of mysqld or any other threaded applica- tion depends on the "gentleman" behaviour of the code that creates threads. The user must take measures to make sure the number of running threads at any time is sufficiently low for thread stacks to stay away from the global heap. With mysqld, you should enforce this "gentleman" behaviour by setting a reasonable value for the max_connections variable. Si vous construisez MySQL vous-mˆemes et ne voulez pas vous amuser `a patcher Linux- Threads, vous ne devez pas d´epasser 500 pour la valeur de max_connections. Cela devrait mˆeme ˆetre 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´emoire `a 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 `a 1500 sans probl`emes, en supposant que vous n’avez ni de grosses tables heap ni grands tampons de clefs. Plus vous r´eduirez STACK_SIZE dans Lin- uxThreads plus les threads cr´e´es seront sˆurs. Nous recommandons une valeur entre 128K et 256K.

Si vous utilisez beaucoup de connexions simultan´ees vous souffrirez peut-ˆetre d’une "fonc- tionnalit´e" du noyau 2.2 qui p´enalise un processus lors du fork ou du clonage d’un enfant en essayant de pr´evenir un attaque du type fork bomb. This will cause MySQL not to scale well as you increase the number of concurrent clients. On single-CPU systems, we have seen this manifested in a very slow thread creation, which means it may take a long time to connect to MySQL (as long as 1 minute), and it may take just as long to shut it down. On multiple-CPU systems, we have observed a gradual drop in query speed as the number of clients increases. In the process of trying to find a solution, we have received a kernel patch from one of our users, who claimed it made a lot of difference for his site. The patch is available at http://www.mysql.com/Downloads/Patches/linux-fork.patch. We have now done rather extensive testing of this patch on both development and production sys- tems. It has significantly improved MySQL performance without causing any problems and we now recommend it to our users who are still running high-load servers on 2.2 kernels. This issue has been fixed in the 2.4 kernel, so if you are not satisfied with the current per- formance of your system, rather than patching your 2.2 kernel, it might be easier to just upgrade to 2.4, which will also give you a nice SMP boost in addition to fixing this fairness bug.

We have tested MySQL on the 2.4 kernel on a 2-CPU machine and found MySQL scales much better—there was virtually no slowdown on queries throughput all the way up to 1000 clients, and the MySQL scaling factor (computed as the ratio of maximum throughput to the throughput with one client) was 180%. We have observed similar results on a 4-CPU system—virtually no slowdown as the number of clients was increased up to 1000, and 300% scaling factor. So for a high-load SMP server we would definitely recommend the 2.4 kernel

at this point. We have discovered that it is essential to run mysqld process with the highest possible priority on the 2.4 kernel to achieve maximum performance. This can be done by adding renice -20 $$ command to safe_mysqld. In our testing on a 4-CPU machine, increasing the priority gave 60% increase in throughput with 400 clients.

Nous essayons aussi actuellement d’obtenir des informations sur le bon fonctionnement de MySQL sur le noyaux 2.4 sur les syst`emes 4-voies and 8-voies. Si vous avez acc`es `a un tel syst`eme et que vous avez effectu´es quelques tests de performances, envoyez-nous un mail `a docs@mysql.com avec les r´esultats, nous les inclurons dans le manuel.

There is another issue that greatly hurts MySQL performance, especially on SMP systems. The implementation of mutex in LinuxThreads in glibc-2.1 is very bad for programs with many threads that only hold the mutex for a short time. On an SMP system, ironic as it is, if you link MySQL against unmodified LinuxThreads, removing processors from the machine improves MySQL performance in many cases. We have made a patch available for glibc 2.1.3 to correct this behaviour (http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch).

With glibc-2.2.2 MySQL version 3.23.36 will use the adaptive mutex, which is much bet- ter than even the patched one in glibc-2.1.3. Be warned, however, that under some condi- tions, the current mutex code in glibc-2.2.2 overspins, which hurts MySQL performance. The chance of this condition can be reduced by renicing mysqld process to the highest priority. We have also been able to correct the overspin behaviour with a patch, available at http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch. It combines the correction of overspin, maximum number of threads, and stack spacing all in one. You will need to apply it in the linuxthreads directory with patch -p0 </tmp/linuxthreads- 2.2.2.patch. We hope it will be included in some form in to the future releases of glibc- 2.2. In any case, if you link against glibc-2.2.2 you still need to correct STACK_SIZE and PTHREAD_THREADS_MAX. We hope that the defaults will be corrected to some more acceptable values for high-load MySQL setup in the future, so that your own build can be reduced to ./configure; make; make install.

We recommend that you use the above patches to build a special static version of libpthread.a and use it only for statically linking against MySQL. We know that the patches are safe for MySQL and significantly improve its performance, but we cannot say anything about other applications. If you link other applications against the patched version of the library, or build a patched shared version and install it on your system, you are doing it at your own risk with regard to other applications that depend on LinuxThreads.

Si vous rencontrez des probl`emes ´etranges lors de l’installation de MySQL, ou quoi que ce soit qui s’en rapproche, il est fort possible que cela soit un probl`eme de librairie ou de compilateur. Si c’est le cas, l’utilisation de notre binaire les r´esoudra.

Un probl`eme connu avec la distribution binaire est que avec les anciens syst`emes Linux qui utilisent libc (comme RedHat 4.x ou Slackware), vous obtiendrez quelques erreurs non- fatales de r´esolutions de noms d’hˆotes. Voir Section 2.6.1.1 [Binary notes-Linux], page 117. Lors de l’utilisation des LinuxThreads vous verrez un minimum de trois processus en cours. Il s’agit en fait de threads, il y’a a un pour le gestionnaire des LinuxThreads, un pour g´erer les connexions, et un autre pour g´erer les alarmes et les signaux.

Notez que le noyau Linux et la librairie LinuxThread ne peuvent avoir par d´efaut que 1024 threads. Cela signifie que vous ne pouvez avoir que 1021 connexions `a MySQL sur un syst`eme non-patch´e. La page http://www.volano.com/linuxnotes.html contient des informations pour contourner cette limite.

Si vous voyez un processus de d´emon mysqld mort avec ps, cela signifie le plus souvent que vous avez trouv´e un bogue dans MySQL ou que vous avez une table corrompue. Voir Section A.4.1 [Crashing], page 697.

To get a core dump on Linux if mysqld dies with a SIGSEGV signal, you can start mysqld with the --core-file option. Note that you also probably need to raise the core file size by adding ulimit -c 1000000 to safe_mysqld or starting safe_mysqld with --core- file-size=1000000. Voir Section 4.7.2 [safe_mysqld], page 292.

Si vous liez votre propre client MySQL et que vousobtenez l’erreur suivante : ld.so.1: ./my: fatal: libmysqlclient.so.4:

open failed: No such file or directory

lors de son ex´ecution, le probl`eme peut ˆetre contourn´e des fa¸cons suivantes :

• Liez le client avec les options suivantes (au lieu de -Lpath) : -Wl,r/path- libmysqlclient.so.

• Copiez libmysqclient.so dans ‘/usr/lib’.

• Ajoutez le chemin vers le r´epertoire o`u se trouve ‘libmysqlclient.so’ `a la variable d’environnement LD_RUN_PATH avant de mettre en marche votre client.

Si vous utilisez le compilateur Fujitsu (fcc / FCC) vous aurez quelques probl`emes en com- pilant MySQL car les fichiers d’entˆetes Linux sont tr`es orient´es gcc.

La ligne suivante de 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.1 Notes relatives `a Linux pour les distributions binaires

MySQL requi`ere au moins la version 2.0 de Linux.

Attention : Certains utilisateurs de MySQL nous ont avertis qu’ils ont rencontr´e de graves probl`emes de stabilit´e avec MySQL et le noyau 2.2.14 de Linux. Si vous utilisez ce noyau, vous devez mettre `a jour `a la 2.2.19 (ou plus r´ecent) ou a un noyau 2.4. Si vous utilisez un ordinateur multi-processeurs, vous devriez s´erieusement songer `a passer au noyau 2.4 qui vous aportera de grandes performances niveau vitesse.

La version binaire est li´ee avec -static, ce qui signifie que normalement vous n’avez pas besoin de vous soucier des versions des librairies syst`eme que vous avez. Vous n’avez pas besoin d’installer LinuxThreads non plus. Un programme li´e avec -static est l´eg`erement plus grand qu’un programme li´ee dynamiquement mais aussi un peu plus rapide (3-5%).

Un probl`eme, toutefois, est que vous ne pouvez utiliser de fonctions d´efinies par l’utilisateur avec un programme li´e statiquement. Si vous allez ´ecrire ou utiliser des fonctions UDF (c’est r´eserv´e aux d´eveloppeurs C ou C++), vous devez compiler MySQL vous-mˆemes, en utilisant les liaisons dynamiques.

Si vous utilisez un syst`eme bas´e sur libc (au lieu de glibc2), vous aurez probablement quelques probl`emes de r´esolution des noms d’hˆotes et des probl`emes avec getpwnam() avec les versions binaires. (Cela vient du fait que glibc d´epend malheureusement de quelques librairies externes pour r´esoudre les noms d’hˆotes et getpwent(), mˆeme quand elle est compil´ee avec -static). Dans ce cas, vous obtiendrez probablement l’erreur suivante quand vous ex´ecuterez mysql_install_db :

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

ou l’erreur suivante quand vous essayez de d´emarrer mysqld avec l’option --user : getpwnam: No such file or directory

Vous pouvez r´esoudre ce probl`eme de la fa¸con suivante :

• Obtenez une distribution des sources MySQL (un distribution RPM ou le tar.gz) et

installez la `a la place.

• Ex´ecutez mysql_install_db --force; cela n’ex´ecutera pas le test resolveip dans

mysql_install_db. Le mauvais cˆot´e est que vous ne pourrez pas utiliser de noms d’hˆotes dans les tables de droits; vous devez utiliser les adresses IP `a la place (sauf pour localhost). Si vous utilisez une vielle version de MySQL qui ne supporte pas --force, vous devez supprimer le test resolveip dans mysql_install `a l’aide d’un ´editeur.

• D´emarrez mysqld avec su au lieu d’utiliser --user.

Le binaire Linux-Intel et les RPM de MySQL sont configur´es pour la vitesse la plus grande possible. Nous essayons toujours d’utiliser le compilateur le plus rapide disponible.

Le support Perl de MySQL requi`ere la version 5.004 03 de Perl ou plus r´ecent.

Sur quelques version de Linux 2.2, vous pouvez obtenir l’erreur Resource temporarily unavailable quand vous faites beaucoup de nouvelles connexions `a un serveur mysqld en utilisant TCP/IP.

Le probl`eme est que Linux poss`ede un d´elai entre votre fermeture de la socket TCP/IP et sa lib´eration par le syst`eme. Vu qu’il y’a un nombre fini de places pour les branche- ments TCP/IP, vous obtiendrez l’erreur pr´ec´edente si vous essayez de faire beaucoup de connexions TCP/IP en peu de temps, comme quand vous ex´ecutez le benchmark MySQL ‘test-connect’ via TCP/IP.

Nous avons envoy´e des questions plusieurs fois `a propos de ce probl`eme `a diff´erentes listes de diffusions Linux mais n’avons jamais r´eussi `a r´esoudre ce probl`eme proprement.

Le seul ’correctif’ connu pour ce probl`eme est d’utiliser des connexions persistantes dans vos clients ou d’utiliser les sockets, si vous utilisez le serveur de bases de donn´ees et le client sur la mˆeme machine. Nous esp´erons que le noyau de Linux 2.4 corrigera ce probl`eme bientˆot.

2.6.1.2 Notes relatives `a Linux x86

MySQL requi`ere la version 5.4.12 de libc ou plus r´ecent. Il est connu pour fonctionner avec libc 5.4.46. La version 2.0.6 de glibc ou plus r´ecente devrait aussi fonctionner. Il

y’a eu quelques probl`emes avec les RPM de glibc de RedHat, et donc, si vous avez des probl`emes, v´erifiez s’il existe des mises `a jour ! Les RPM de glibc 2.0.7-19 et 2.0.7-29 snot connus pour fonctionner.

Si vous utilisez gcc 3.0 ou plus r´ecent pour compiler MySQL, vous devez installer la librairie libstdc++v3 avant de compiler MySQL; si vous ne le faites pas vous obtiendrez une erreur `a propos d’un symbole __cxa_pure_virtual manquant durant la liaison !

Sur quelques vieilles distributions de Linux, configure peut 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 `a la macro _P qui n’en a qu’un, puis essayez `a nouveau.

Vous pouvez obtenir quelques avertissements en compilant; celles qui suivent peuvent ˆetre ignor´ees :

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’

Sur Debian GNU/Linux, si vous voulez que MySQL d´emarre automatiquement lors du d´emarrage de votre syst`eme, faites ce qui suit :

shell> cp support-files/mysql.server /etc/init.d/mysql.server shell> /usr/sbin/update-rc.d mysql.server defaults 99

mysql.server peut ˆetre trouv´e dans le dossier ‘share/mysql’ dans le dossier d’installation de MySQL ou dans le dossier ‘support-files’ de l’arborescence des sources de MySQL. Si mysqld provoque toujours un core dump au d´emarrage, le probl`eme peut ˆetre que vous avez un vieux ‘/lib/libc.a’. Renommez le, puis supprimez ‘sql/mysqld’ et faites `a nou- veau un make install puis r´eassayez. Ce probl`eme a ´et´e report´e sur quelques installations