Utilisation maximale de la mémoire par MySQL
Je voudrais savoir comment il est possible de définir une limite supérieure à la quantité de mémoire utilisée par MySQL sur un serveur Linux.
À l’heure actuelle, MySQL utilisera continuellement de la mémoire à chaque nouvelle requête pour ne plus avoir de mémoire. Existe-t-il un moyen de définir une limite afin que MySQL n'utilise pas plus que cette quantité?
L'utilisation maximale de la mémoire par MySQL dépend en grande partie du matériel, de vos paramètres et de la base de données .
Matériel
Le matériel est la partie évidente. Plus il y a RAM, plus les disques sont rapides, plus rapides ftw . Ne croyez pas ces lettres mensuelles ou hebdomadaires cependant. MySQL ne s'adapte pas de manière linéaire, pas même sur le matériel Oracle. C'est un peu plus compliqué que ça.
La ligne du bas est la suivante: il n’existe pas de règle générale pour ce qui est recommandé pour votre configuration de MySQL . Tout dépend de l'utilisation actuelle ou des projections.
Paramètres et base de données
MySQL offre d'innombrables variables et commutateurs pour optimiser son comportement. Si vous rencontrez des problèmes, vous devez vraiment vous asseoir et lire le manuel (f'ing).
En ce qui concerne la base de données - quelques contraintes importantes:
- moteur de table (
InnoDB,MyISAM, ...) - taille
- des indices
- usage
La plupart des astuces MySQL sur stackoverflow vous expliquent 5 à 8 paramètres dits importants. Tout d’abord, ils ne sont pas tous importants - par exemple: allouer beaucoup de ressources à InnoDB et ne pas utiliser InnoDB n'a pas beaucoup de sens car ces ressources sont gaspillées.
Ou - beaucoup de gens suggèrent d'augmenter la variable max_connection - eh bien, ils ne savent pas que cela implique également que MySQL allouera plus de ressources pour répondre à ces max_connections - si besoin est. La solution la plus évidente pourrait être de fermer la connexion à la base de données dans votre DBAL ou de baisser le wait_timeout pour libérer ces threads.
Si vous voyez ce que je veux dire, il y a vraiment beaucoup à lire et à apprendre.
Moteurs
Les moteurs de table sont une décision assez importante, beaucoup de gens oublient cela tôt et se retrouvent soudainement aux prises avec une table de 30 Go MyISAM de 30 Go qui verrouille et bloque toute leur application.
Je ne veux pas dire que MyISAM est nul , mais InnoDB peut être modifié pour répondre presque ou presque aussi vite que MyISAM et offre une fonction telle que row -locking on UPDATE alors que MyISAM verrouille la table entière lorsqu’elle est écrite.
Si vous êtes libre d’exécuter MySQL sur votre propre infrastructure, vous pouvez également consulter le serveur percona car parmi de nombreuses contributions de sociétés telles que Facebook et Google (elles savent vite), il inclut également le propre remplacement de Percona pour InnoDB, appelé XtraDB.
Voir mon Gist pour la configuration de percona-server (et -client) (sur Ubuntu): http://Gist.github.com/637669
Taille
La taille de la base de données est très, très importante - croyez-le ou non, la plupart des gens sur Intarwebs n’ont jamais géré une configuration MySQL volumineuse et intense, mais ceux-ci existent vraiment. Certaines personnes vont troll et diront quelque chose comme: "Utilisez PostgreSQL! 111", mais ignorons-les pour l'instant.
Le résultat est le suivant: à en juger par la taille, le choix du matériel est à prendre. Vous ne pouvez pas vraiment faire fonctionner une base de données de 80 Go avec 1 Go de RAM.
Indices
Ce n'est pas: plus on est de fous, plus on rit. Seuls les index nécessaires doivent être définis et l'utilisation doit être vérifiée avec EXPLAIN. Ajoutez à cela que EXPLAIN de MySQL est vraiment limité, mais c'est un début.
Configurations suggérées
À propos de ces fichiers my-large.cnf et my-medium.cnf - je ne sais même pas pour qui ils ont été écrits. Rouler le vôtre.
Apprêt d'accord
Le bon début est le amorce de réglage . Il s’agit d’un script bash (indice: vous aurez besoin de Linux) qui récupère le résultat de SHOW VARIABLES et SHOW STATUS et l’enveloppe dans une recommandation utile. Si votre serveur a fonctionné un certain temps, la recommandation sera meilleure car il y aura des données sur lesquelles les baser.
L'amorce de réglage n'est pas une sauce magique cependant. Vous devriez quand même lire toutes les variables suggérées.
En train de lire
J'aime vraiment recommander le mysqlperformanceblog . C'est une excellente ressource pour toutes sortes de conseils relatifs à MySQL. Et ce n’est pas seulement MySQL, ils savent aussi beaucoup de choses sur le bon matériel ou recommandent des configurations pour AWS, etc. Ces gars ont des années et des années d’expérience.
Une autre grande ressource est planet-mysql , bien sûr.
Nous utilisons ces paramètres:
etc/my.cnf
innodb_buffer_pool_size = 384M
key_buffer = 256M
query_cache_size = 1M
query_cache_limit = 128M
thread_cache_size = 8
max_connections = 400
innodb_lock_wait_timeout = 100
pour un serveur avec les spécifications suivantes:
Dell Server
CPU cores: Two
Processor(s): 1x Dual Xeon
Clock Speed: >= 2.33GHz
RAM: 2 GBytes
Disks: 1×250 GB SATA
L'utilisation de la mémoire de base de données est un sujet complexe. Le MySQL Performance Blog couvre bien votre question et répertorie de nombreuses raisons pour lesquelles il est extrêmement difficile de "réserver" de la mémoire.
Si vous voulez vraiment imposer une limite stricte, vous pouvez le faire, mais vous devez le faire au niveau du système d'exploitation car il n'y a pas de paramètre intégré. Sous Linux, vous pourriez utiliser limit , mais vous devrez probablement modifier le mode de démarrage de MySQL pour l'imposer.
La meilleure solution consiste à désactiver votre serveur afin qu'une combinaison des paramètres de mémoire MySQL habituels entraîne généralement une utilisation réduite de la mémoire par votre installation MySQL. Cela aura bien sûr un impact négatif sur les performances de votre base de données, mais certains des paramètres que vous pouvez modifier dans my.ini sont les suivants:
key_buffer_size
query_cache_size
query_cache_limit
table_cache
max_connections
tmp_table_size
innodb_buffer_pool_size
Je commencerais par là et verrais si vous pouvez obtenir les résultats souhaités. Il y a plusieursarticles à propos de l'ajustement des paramètres de mémoire de MySQL.
Modifier:
Notez que certains noms de variables ont changé dans les nouvelles versions de MySQL 5.1.x .
Par exemple:
table_cache
Est maintenant:
table_open_cache
mysqld.exe utilisait 480 Mo dans la RAM. J'ai trouvé que j'avais ajouté ce paramètre à my.ini
table_definition_cache = 400
qui a réduit l'utilisation de la mémoire de 400 000 kb à 105 000 kb
dans /etc/my.cnf:
[mysqld]
...
performance_schema = 0
table_cache = 0
table_definition_cache = 0
max-connect-errors = 10000
query_cache_size = 0
query_cache_limit = 0
...
Bon travail sur le serveur avec 256 Mo de mémoire.