2.6 Notes spécifiques aux systèmes d'exploitation
2 Installation de MySQL
Manuel de Référence MySQL 4.1 : Version Française
->Notes relatives à Linux (toutes versions)
. Notes relatives à Windows
. Remarques pour Solaris
. Notes relatives à BSD
. Notes relatives à Mac OS X
. Notes sur les autres Unix
. Notes relatives à OS/2
. Notes relatives à BeOS
. Notes relatives à Novell NetWare
|
2.6.1 Notes relatives à Linux (toutes versions)
Les notes suivantes relatives à
glibc
ne s'appliquent que dans la situation
où vous construisez MySQL vous-même. 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ée 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ès
vous être assurés que notre binaire ne répond pas à vos attentes. Dans ce cas, nous
apprécierons une note à 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épassant 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ède pas
glibc2
, vous devz installer LinuxThreads avant
d'essayer de compiler MySQL. Vous pouvez obtenir LinuxThreads à l'adresse suivante :
http://www.mysql.com/Downloads/Linux/ .
Note
: Nous avons rencontré quelques problèmes étranges avec Linux 2.2.14
et MySQL sur les systèmes SMP. Si vous avez un système SMP, nous vous recommandons
de mettre à jour à Linux 2.4 dès que possible ! Votre système n'en sera que plus
rapide et plus stable !
Notez que les versions de
glibc
inférieure ou égale à la 2.1.1 ont un bogue fatal
dans la gestion de
pthread_mutex_timedwait
, qui est utilisé lors que vous exécutez
INSERT DELAYED
. Nous vous recommandons de ne pas utiliser
INSERT DELAYED
avant de mettre à jour glibc.
Si vous planifiez d'avoir plus de 1000 connexions simultanées, vous aurez besoin d'apporter
quelques modifications à LinuxThreads, le recompiler, et relier MySQL avec le nouveau
libpthread.a
. Augmentez
PTHREAD_THREADS_MAX
dans
sysdeps/unix/sysv/linux/bits/local_lim.h
à 4096 et diminuez
STACK_SIZE
dans
linuxthreads/internals.h
à 256 KB. Les chemins sont relatifs
à la racine de
glibc
. Notez que MySQL ne sera pas stable autour de 600-1000 connexions
si
STACK_SIZE
est à 2 MB (par défaut).
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 connaitre le nombre de gestionnaires de fichiers alloués
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émoire, 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é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
|
Vous devez aussi ajouter ce qui suit à
/etc/my.cnf
:
[safe_mysqld]
open-files-limit=8192
|
Cela devrait permettre à MySQL de créer jusqu'à 8192 fichiers de conexion.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, 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 application 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êmes et ne voulez pas vous amuser à patcher
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 128K et 256K.
Si vous utilisez beaucoup de connexions simultanées vous souffrirez peut-être
d'une "fonctionnalité" du noyau 2.2 qui pénalise un processus lors du fork
ou du clonage d'un enfant en essayant de prévenir 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 systems. 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 performance 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èmes
4-voies and 8-voies. Si vous avez accès à un tel système et que vous
avez effectués quelques tests de performances, envoyez-nous un mail à
docs@mysql.com avec les résultats, 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
better than even the patched one in
glibc-2.1.3
. Be warned, however,
that under some conditions, 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èmes étranges lors de l'installation de MySQL,
ou quoi que ce soit qui s'en rapproche, il est fort possible que cela soit
un problème de librairie ou de compilateur. Si c'est le cas, l'utilisation
de notre binaire les résoudra.
Un problème connu avec la distribution binaire est que avec les anciens
systèmes Linux qui utilisent
libc
(comme RedHat 4.x ou Slackware), vous
obtiendrez quelques erreurs non-fatales de résolutions de noms d'hôtes.
Notes relatives à Linux pour les distribution binaires .
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érer les connexions, et un autre pour gérer les alarmes
et les signaux.
Notez que le noyau Linux et la librairie LinuxThread ne peuvent avoir par défaut
que 1024 threads. Cela signifie que vous ne pouvez avoir que 1021 connexions à
MySQL sur un système non-patché. La page
http://www.volano.com/linuxnotes.php contient des informations pour
contourner cette limite.
Si vous voyez un processus de démon
mysqld
mort avec
ps
, cela
signifie le plus souvent que vous avez trouvé un bogue dans MySQL ou que vous avez
une table corrompue. Que faire si MySQL crashe constamment .
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
.
safe_mysqld
, le script père de
mysqld
.
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écution, le problème peut être contourné des façons 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épertoire où se trouve
libmysqlclient.so
à
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èmes en compilant MySQL car les fichiers d'entêtes Linux sont très orientés
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
|
Sommaire :
|
