Meilleurs paramètres de cache MySQL pour un serveur MySQL dédié de 8 Go de RAM utilisant uniquement InnoDB (base de données de 5 Go)

Je suis un gros noeud quand il s'agit de configurer MySQL pour les performances. Et honnêtement, je ne m'inquiète pas du réglage fin pour extraire chaque dernier bit de performance de MySQL, mais je sais que la chose la plus importante à faire qui fournit certains des meilleurs résultats est de configurer correctement les caches / tampons.

J'ai essayé de garder les choses simples en utilisant uniquement InnoDB comme moteur de stockage. Et j'ai un serveur dédié pour MySQL. Il a 8 Go de RAM, comment dois-je l'allouer pour maximiser les performances? J'aimerais pouvoir mettre toute ma base de données en mémoire pour les meilleures performances. La base de données fait environ 5 Go. Est-ce possible?

Quelle quantité de mémoire dois-je allouer au cache de requêtes? Combien au pool de tampons InnoDB? Combien pour le reste de l'ordinateur (c'est-à-dire les processus non liés à MySQL)? Etc.

Comme je n'utilise pas MyISAM, je n'ai pas vraiment besoin de mettre beaucoup de mémoire dans le cache de clés, n'est-ce pas?

C'est difficile sans en savoir beaucoup sur la base de données elle-même. Il y a quelques outils que vous devez connaître;

• http://mysqltuner.pl/
• MySQL Tuning Primer

À propos du stockage de la base de données entière en mémoire; Toutes les requêtes qui effectuent des modifications sur la base de données resteront ouvertes jusqu'à ce que l'écriture soit effectuée sur le disque. La seule chose qui peut éviter que le disque soit un goulot d'étranglement, c'est un contrôleur de disque avec un cache d'écriture.

Je commencerais par les modifications suivantes par rapport aux valeurs par défaut:

key_buffer_size = 128M
thread_stack = 128K
thread_cache_size = 8
table_cache = 8192
max_heap_table_size = 256M
query_cache_limit = 4M
query_cache_size = 512M

innodb_buffer_pool_size = 4G 

# This is crucial to avoid checkpointing all the time:
innodb_log_file_size = 512M

# If you have control on who consumes the DB, and you don't use hostnames when you've set up permissions - this can help as well.
skip_name_resolve

Ensuite, je verrais comment les choses se passeraient et j'essaierais différentes choses en fonction (entre autres) de la sortie des outils mentionnés ci-dessus. Je m'assurerais également de représenter graphiquement les tendances avec un outil de surveillance, tel que Munin ou Cacti , pour voir à quel type de charge de travail je fais réellement face. Personnellement, j'ai une grande expérience avec les plugins MySQL fournis avec Munin.

À mon humble avis, vous devriez être en mesure d'aller avec

innodb_buffer_pool_size=5G

Ce serait 62,5% de RAM avec une quantité suffisante de RAM pour le système d'exploitation du serveur plus la mémoire pour les connexions DB

@kvisle a recommandé d'utiliser mysqltuner.pl. Ce script est excellent pour juger de la quantité de RAM à consacrer à join_buffer_size, sort_buffer_size, read_buffer_size et read_rnd_buffer_size. Ces 4 tampons additionnés sont multipliés par max_connections. Cette réponse est ajoutée aux tampons statiques (innodb_buffer_pool_size + key_buffer_size). Les sommes combinées sont déclarées. Si cette somme combinée dépasse 80% de la RAM, c'est à ce moment que vous devez réduire ces tailles de mémoire tampon. mysqltuner.pl sera très utile à cet égard.

Étant donné que toutes vos données sont InnoDB, vous pouvez rendre key_buffer_size (tampon de cache de clé pour les index MyISAM) très faible (je recommande 64 Mo).

Voici un article que j'ai fait dans le DBA StackExchange pour calculer une taille recommandée pour innodb_buffer_pool_size .

MISE À JOUR 2011-10-15 19:55 EDT

Si vous savez que vous disposerez de 5 Go de données, ma première recommandation était OK. Cependant, j'ai oublié d'ajouter une chose:

[mysqld]
innodb_buffer_pool_size=5G
innodb_log_file_size=1280M

La taille du fichier journal doit être de 25% du pool de tampons InnoDB

MISE À JOUR 2011-10-16 13:36 EDT

La règle des 25% est strictement basée sur l'utilisation de deux fichiers journaux. Bien qu'il soit possible d'utiliser plusieurs fichiers journaux innodb, deux fonctionnent généralement mieux.

D'autres ont exprimé en utilisant 25%

• http://lists.mysql.com/mysql/203879
• http://teaching-2.cs.uml.edu/MySQLdocs/MySQL_Manual/InnoDB_start.html
• http://www.issociate.de/board/post/395589/innodb_buffer_pool_size._How_to_setup_with_more_than_5G_?.html

Cependant, en toute honnêteté, quelqu'un de la société InnoBase Oy d'origine a déclaré ne pas utiliser la règle des 25% en raison du plus grand pool de tampons InnoDB .

Naturellement, la règle des 25% ne peut pas fonctionner avec de grandes quantités de RAM. En fait, la plus grande taille innodb_log_file_size autorisée en utilisant seulement 2 fichiers journaux est 2047M, car la taille combinée du fichier journal doit être inférieure à 4G (4096M)

CAS EN POINT: Un des clients de mon employeur a un serveur DB avec 192 Go de RAM. Il n'y a aucun moyen d'avoir des fichiers journaux 48G. J'utilise simplement la taille de fichier maximale pour un fichier journal innodb, 2047M. @ Le commentaire de Kvisle sur ma réponse donne simplement un lien indiquant que vous n'avez pas à vous limiter à deux fichiers journaux. Si vous avez N fichiers journaux, ils ne peuvent pas totaliser la 4G. Ma règle des 25% est juste dans un monde parfait (serveur DB avec 8 Go ou moins).