J'ai récemment eu des problèmes avec le thrashing suite à un manque de mémoire. (Mon VPS a 256M au total)
J'essaie de régler MySQL en utilisant mysqltuner.pl et d'obtenir les résultats suivants:
-------- Statistiques générales ---------------------------------------- ----------
[-] Vérification de version ignorée pour le script MySQLTuner
[OK] Actuellement en cours d'exécution MySQL version 5.0.51a-3ubuntu5.4 pris en charge
[OK] Fonctionnant sur une architecture 64 bits
-------- Statistiques du moteur de stockage --------------------------------------- ----
[-] Statut: + Archive -BDB -Federated -InnoDB -ISAM -NDBCluster
[-] Données dans les tableaux MyISAM: 114M (tableaux: 454)
[!!] Total des tableaux fragmentés: 34
-------- Indicateurs de performance ---------------------------------------- ---------
[-] Prêt pour: 40s (570 q [14.250 qps], 23 conn, TX: 154K, RX: 23K)
[-] Lectures / écritures: 100% / 0%
[-] Nombre total de tampons: 338,0 millions global + 2,7 millions par thread (20 threads max)
[!!] Utilisation maximale possible de la mémoire: 392,9 M (153% de la RAM installée)
[OK] Requêtes lentes: 0% (5/570)
[OK] Utilisation la plus élevée des connexions disponibles: 15% (3/20)
[!!] Taille du tampon clé / total des index MyISAM: 8,0 M / 9,4 M
[!!] Taux de réussite du tampon clé: 57,1% (7 mises en cache / 3 lectures)
[OK] Efficacité du cache de requête: 21,9% (7 sélections en cache / 32 sélections)
[OK] Query cache pruneaux par jour: 0
[OK] Tri nécessitant des tables temporaires: 0% (0 tri temporaire / 1 tri)
[OK] Tables temporaires créées sur disque: 0% (0 sur disque / 32 au total)
[OK] Taux de réussite du cache de threads: 86% (3 connexions créées / 23 connexions)
[OK] Taux de réussite du cache de table: 26% (128 ouvert / 484 ouvert)
[OK] Limite d'ouverture de fichiers utilisée: 25% (259 / 1K)
[OK] Verrous de table acquis immédiatement: 100% (492 verrous immédiats / 492 verrous)
-------- Recommandations ----------------------------------------- ------------
Recommandations générales:
Exécutez OPTIMIZE TABLE pour défragmenter les tables pour de meilleures performances
MySQL a démarré au cours des dernières 24 heures - les recommandations peuvent être inexactes
Réduisez votre empreinte mémoire globale MySQL pour la stabilité du système
Variables à ajuster:
*** L'utilisation maximale de la mémoire de MySQL est dangereusement élevée ***
*** Ajoutez de la RAM avant d'augmenter les variables du tampon MySQL ***
key_buffer_size (> 9.4M)
Mais je suis un peu confus sur la façon de réduire l'utilisation maximale de la mémoire? Il semble être basé sur key_buffer et max_connections, mais il doit aussi y avoir autre chose impliqué?
my.cnf:
key_buffer = 8M max_allowed_packet = 12M thread_stack = 128K thread_cache_size = 8 max_connections = 20 table_cache = 128 tmp_table_size = 256M max_heap_table_size = 256M join_buffer_size = 256K query_cache_limit = 8M query_cache_size = 64M
J'ai essayé de lire les articles sur le réglage de MySQL, mais ils semblent destinés aux gens qui savent déjà ce qu'ils font! Toute aide serait appréciée. Merci!
Réponses:
Vous avez un serveur avec 256M, mais vous ne pouvez pas utiliser tout cela - rappelez-vous qu'il y a une surcharge du système d'exploitation. Ajoutez à cela le fait que vous vous êtes trop engagé comme d'autres l'ont mentionné et vous allez définitivement vous battre ici. 256M ne suffit que pour une petite base de données, 20 connexions, c'est beaucoup avec ce que vous avez configuré.
1) réduisez votre nombre maximal de connexions à 4 (vous utilisez 3 sur 20)
2) optimisez mieux votre cache de requêtes; 8M est vraiment grand, et 64M au total est beaucoup basé sur vos hits / pruneaux; essayez un combo 4/32 et voyez comment ça se passe. Vraiment, je pense qu'un combo 2/24 fonctionnerait pour vous.
3) vous n'avez aucun tri nécessitant des tables temporaires, pourquoi ce verbe max_heap_table_size là-dedans? Commentez cela, utilisez les valeurs par défaut
4) avez-vous réellement 128 tables? Essayez de couper ce table_cache en deux à 64 ou 48
5) Réduisez thread_cache_size à 4
6) optimiser ces tables pour réduire la fragmentation
Ce sont des choses pour commencer. Il semble que vous ayez jeté un tas de chiffres dans une configuration sans profilage réel pour savoir ce dont vous aviez besoin et avoir créé un gâchis; si tout le reste échoue, revenez aux valeurs par défaut et supprimez vos paramètres personnalisés et recommencez à l'aide de certains guides de réglage des performances que vous pouvez trouver sur Google. Obtenez la sortie de SHOW VARIABLES et SHOW STATUS, trouvez l'un des guides de réglage d'un bajillion et branchez vos nombres réels et réels dans leurs équations et cela vous dira les nombres exacts que vous devez mettre dans votre fichier de configuration.
la source
Je ne suis pas un gourou de MySQL et je ne peux pas diagnostiquer le problème avec ces informations, mais j'ai essayé de rechercher la formule dans le code source. C'est ici:
Où:
et:
Vous devez maintenant vérifier chacune de ces valeurs et déterminer laquelle est responsable de ce nombre énorme. Et ne faites pas confiance à ce script sans réserve - j'ai essayé de l'exécuter sur l'un de mes serveurs de base de données et il a calculé que la mémoire maximale est de 140% de la quantité totale de mémoire physique, mais le système fonctionne depuis des années sans aucun problème de stabilité.
Bonne chance!
la source
Si je me souviens bien, MySQL Tuner utilise la formule suivante pour estimer l'utilisation maximale:
Gardez à l'esprit que ce n'est pas correct à 100%, et n'est en fait qu'une estimation, car certains paramètres de MySQL n'ont pas de limite définie.
Vous pouvez commencer à atténuer certains des paramètres de votre fichier de configuration et à réexécuter le tuner, mais je vous conseillerais de demander l'aide d'un expert si vous n'avez pas le temps de perdre à changer my.cnf, à le redémarrer et à exécuter le tuner.
la source
L'utilisation du logiciel mysqlcalculator.com peut vous faire économiser de nombreuses heures.
la source