Forums, scripts, cours, services pour webmaster, manuels (PHP, MySQL, HTML...) en français !
PHP / MySql
Recherche
 
ManuelPHP.com
Installation de MySQL
<<<
Notes relatives à Linux (toutes versions) Notes relatives à Windows
>>>

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 :

<< Notes relatives à Linux (toutes versions) >>
Installation de MySQL Notes spécifiques aux systèmes d'exploitation Notes relatives à Windows





Google

Services webmasters

Les manuels
 

ManuelPHP.com © 2003-2012 Tigersun - Crédits
Webmaster Site Internet - Télécharger des Logiciels - Programme TV - Entraide Informatique - Agence de Communication
2017-08-17