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. 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.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. See Section 2.8.1.3, « Notes sur la distribution source 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. See Section A.4.2, « Que faire si MySQL plante 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. See Section 5.1.3, « safe_mysqld, le script père de mysqld ».