Introduction de méthodes pour optimiser MYSQL sous plusieurs aspects afin d'obtenir des performances. L'optimisation est une tâche complexe car elle nécessite en fin de compte une compréhension de l'ensemble du système. Bien qu'il soit possible de réaliser une optimisation locale avec peu de connaissances de votre système/application, plus vous souhaitez optimiser votre système, plus vous devez savoir que c'est le cas. et plus encore. Par conséquent, ce chapitre tentera d'expliquer et de donner quelques exemples de différentes manières d'optimiser MySQL. Mais rappelez-vous qu'il existe toujours certaines méthodes (de plus en plus difficiles) qui sont plus rapides pour le système. La partie la plus importante pour rendre votre système plus rapide est bien sûr la conception de base. Vous devez également savoir que votre système va faire des choses comme celle-ci, et c'est votre goulot d'étranglement. Les goulots d'étranglement les plus courants sont :
Recherche de disque. Le temps nécessaire à un disque pour trouver une donnée. Le temps moyen d'un disque moderne utilisé en 1999 était généralement inférieur à 10 ms, donc en théorie, nous pourrions rechercher environ 1 000 fois par seconde. Ce temps s'améliore lentement avec les plus récents. disques et est difficile à mesurer. L'optimisation d'une table. La façon de l'optimiser est de répartir les données sur plusieurs disques. Les disques sont en lecture/écriture lorsque les disques sont au bon endroit où nous devons lire les données. un transfert de disque équivaut à 10-20 Mb/s. Cela doit être plus facile à optimiser car vous pouvez lire à partir de plusieurs disques dans des cycles CPU parallèles. Lorsque nous lisons des données en mémoire (ou si elles sont déjà là), nous devons les traiter pour y parvenir. nos résultats. Quand Il s'agit du facteur limitant le plus courant lorsque nous avons des tables avec une mémoire relativement petite, mais avec de petites tables, la vitesse n'est généralement pas un problème. La bande passante du cache devient un goulot d'étranglement dans la mémoire lorsque le processeur a besoin de plus de données que ce qui peut en contenir. dans le cache du processeur. Il s'agit d'un goulot d'étranglement rare sur la plupart des systèmes, mais vous devez en être conscient. 10.2 Réglage du système/de la compilation et des paramètres de démarrage Nous commençons par les éléments au niveau du système, car certaines de ces décisions sont prises très tôt. D'autres fois, un rapide coup d'œil à cette section peut suffire car elle n'est pas essentielle pour obtenir un gain important, mais il est toujours bon d'avoir une idée de l'ampleur du gain à ce niveau. Le système d'exploitation par défaut utilisé est important pour une utilisation maximale ! plusieurs processeurs dans une certaine mesure, vous devez utiliser Solaris (car les threads fonctionnent très bien) ou Linux (car le noyau 2.2 a un très bon support SMP) Et sur les machines 32 bits, Linux a une limite de taille de fichier de 2G par défaut. Espérons que cela sera bientôt corrigé lors de la sortie du nouveau système de fichiers (XFS). Étant donné que nous n'exécutons pas MySQL en production sur de nombreuses plates-formes, nous vous conseillons de tester la plate-forme que vous comptez exécuter avant de la choisir.
Autres suggestions :
Si vous disposez de suffisamment de RAM, vous pouvez supprimer tous les périphériques d'échange. Certains systèmes d'exploitation utiliseront un périphérique SWAP dans certains cas même si vous disposez de mémoire libre. Utilisez l'option --skip -locking MySQL pour éviter le verrouillage externe. Fonctionnalité MySQL tant qu'elle ne s'exécute que sur un seul serveur. N'oubliez pas d'arrêter le serveur (ou de verrouiller les parties concernées) avant d'exécuter myisamchk. Sur certains systèmes, ce commutateur est obligatoire car le verrouillage externe n'est disponible sur aucun système dans tous les cas. . Lors de la compilation avec MIT-pthreads, l'option --skip-locking est par défaut activée (on) car flock() n'est pas entièrement pris en charge par MIT-pthreads sur toutes les plates-formes. Le seul cas est si vous exécutez le serveur MySQL (pas). le client) sur les mêmes données, vous ne pouvez pas utiliser --skip-locking, sinon exécutez myisamchk sur la table sans d'abord vider ou verrouiller le serveur mysqld. Vous pouvez toujours utiliser LOCK TABLES/UNLOCK TABLES, même si vous utilisez --skip. -verrouillage.
Comment la compilation et la liaison affectent la vitesse de MySQL
La plupart des tests suivants ont été effectués sous Linux et à l'aide du benchmark MySQL, mais ils devraient donner des indications sur d'autres systèmes d'exploitation et charges de travail. Vous obtenez les exécutables les plus rapides lorsque vous effectuez une liaison avec -static Utilisation de sockets Unix Connexion à une base de données au lieu de TCP. /IP peut également donner de meilleures performances. Sous Linux, vous obtiendrez le code le plus rapide lors de la compilation avec pgcc et -O6. Pour compiler "sql_yacc.cc" avec ces options, vous avez besoin d'environ 200 Mo de mémoire, car gcc/pgcc nécessite beaucoup de mémoire. mémoire pour rendre toutes les fonctions en ligne. Lors de la configuration de MySQL, vous devez également définir CXX=gcc pour éviter d'inclure la bibliothèque libstdc++ (ce n'est pas nécessaire en utilisant simplement un meilleur compilateur ou de meilleures options de compilateur, vous pouvez obtenir un 10). -30% d'accélération dans votre application. Ceci est particulièrement important si vous compilez vous-même le serveur SQL ! Sur Intel, vous devez par exemple utiliser pgcc ou le compilateur Cygnus CodeFusion. Obtenez une vitesse maximale. Nous avons testé le nouveau compilateur Fujitsu, mais ce n'est pas encore le cas. suffisamment sans erreur pour optimiser la compilation de MySQL.
Voici quelques fiches de mesures que nous avons réalisées :
Si vous utilisez pgcc avec -O6 et compilez quoi que ce soit, le serveur mysqld est 11% plus rapide qu'avec gcc (avec la version string 99). Si vous liez dynamiquement (sans -static), le résultat est 13% plus lent. toujours Peut utiliser une bibliothèque MySQL liée dynamiquement. Seul le serveur est essentiel pour les performances. Si vous utilisez TCP/IP au lieu de sockets Unix, le résultat est 7,5 % plus lent. Sur une Sun SPARCstation 10, gcc2.7.3 est plus rapide que Sun Pro C++. 4.2 est 13 % plus rapide. Sur Solaris 2.5.1, les MIT-pthreads sont 8 à 12 % plus lents que Solaris avec des threads natifs sur un seul processeur, la différence devrait devenir encore plus grande, grâce à TcX The MySQL. La distribution Linux est compilée avec pgcc et liée statiquement.
Comme mentionné précédemment, la recherche de disque constitue un gros goulot d'étranglement en termes de performances. Ce problème devient de plus en plus évident lorsque les données commencent à croître, de sorte que la mise en cache devient impossible pour les grandes bases de données, où vous devez être plus ou moins aléatoire. comptez sur le fait que vous aurez besoin d'au moins une recherche de disque pour lire et de plusieurs recherches de disque pour écrire. Pour minimiser ce problème, utilisez des disques avec des temps de recherche faibles pour augmenter le nombre de broches de disque disponibles (et réduire ainsi la surcharge de recherche). il est possible de créer un lien symbolique vers différents disques ou de diviser le disque. En utilisant des liens symboliques, cela signifie que vous liez symboliquement les fichiers d'index/données du répertoire de données normal à l'autre disque (qui peut également être divisé). fois mieux (si le disque n'est pas utilisé pour d'autres choses). Voir 10.2.2.1 Utilisation de liens symboliques vers des bases de données et des tables. Split Split signifie que vous avez plusieurs disques et que vous placez le premier bloc sur un disque, le deuxième bloc est sur le deuxième disque. , et le nième bloc est sur le (n mod number_of_disks)ème disque, etc. Cela signifie que si la taille normale de vos données est inférieure à la taille de fractionnement (ou parfaite (arrangée en conséquence), vous obtiendrez des performances légèrement meilleures. Notez que le fractionnement est très dépendant du système d'exploitation et de la taille de fractionnement. Testez donc votre application avec différentes tailles de fractionnement. Voir 10.8 Utiliser votre propre benchmark. Notez que le fractionnement dépend beaucoup du système d'exploitation et de la taille de fractionnement. les paramètres et le nombre de disques, vous pouvez obtenir des ordres de grandeur de différence. Notez que vous devez choisir d'optimiser pour un accès aléatoire ou séquentiel, vous souhaiterez peut-être utiliser raid RAID 0+ 1 (split + miroir), mais. dans ce cas, vous aurez besoin de 2*N disques pour contenir les données de N disques. Si vous avez de l'argent, c'est probablement la meilleure option. Cependant, vous devrez peut-être également investir dans un logiciel de gestion de volume pour le gérer efficacement ! une bonne option est d'avoir les données les moins importantes (qui peuvent être reproduites) sur un disque RAID 0, et les données vraiment importantes (comme les informations sur l'hôte et les fichiers journaux) sur un disque RAID 0+ 1 ou RAID N si vous en avez beaucoup. d'écritures en raison de la mise à jour des bits de parité, RAID N peut être un problème. Vous pouvez également définir les paramètres du système de fichiers utilisé par la base de données. Un changement simple consiste à monter le système de fichiers avec l'option noatime. l'inode dont il ignore la mise à jour, ce qui évitera certaines recherches sur le disque.
Vous pouvez déplacer des tables et des bases de données du répertoire de bases de données vers un autre emplacement et les remplacer par des symboles liés au nouvel emplacement. Vous souhaiterez peut-être le faire, par exemple, en déplaçant une base de données vers un système de fichiers disposant de plus d'espace libre. Remarques MySQL Une table est un lien symbolique, qui résoudra le lien symbolique et utilisera la table vers laquelle elle pointe réellement. Cela fonctionne sur tous les systèmes qui prennent en charge l'appel realpath() (au moins Linux et Solaris prennent en charge realpath()) ! qui ne prennent pas en charge realpath() Sur votre système, vous ne devez pas accéder à la table via à la fois un chemin réel et un lien symbolique. Si vous le faites, la table sera incohérente après toute mise à jour. MySQL ne prend pas en charge les liens de base de données ! par défaut. Tant que vous ne faites pas de lien symbolique entre les bases de données, tout fonctionnera correctement. Supposons que vous ayez une base de données db1 dans le répertoire de données MySQL et créez un lien symbolique db2 pointant vers db1 :
shell&> cd /chemin/vers/datadir
shell&> ln -s db1 db2
Désormais, pour n'importe quelle table tbl_a dans db1, il y aura également une table tbl_a dans db2. Si un thread met à jour db1.tbl_a et qu'un autre thread met à jour db2.tbl_a, il y aura des problèmes. Si vous en avez vraiment besoin, vous aurez le code suivant. "mysys/mf_format.c" doit être modifié :
if (!lstat(to,&stat_buff)) /* Vérifiez s'il s'agit d'un lien symbolique */
if (S_ISLNK(stat_buff.st_mode) && realpath(to,buff))
Changez le code comme suit :
if (chemin réel (vers, buff))