Que définir innodb_buffer_pool et pourquoi ..?

Question

J'ai 170 Go d'index et de données InnoDB.

Je dois réajuster la taille innodb_buffer_pool pour de meilleures performances. La taille maximale d'une table InnoDB (données Index +) est de 28 Go.

Quelle devrait donc être la taille optimale de innodb_buffer_pool.

MISE À JOUR

nous allons migrer notre base de données locale vers ec2, nous allons donc définir le RAM selon les statistiques actuelles d'innodb, c'est pourquoi j'ai besoin de la taille du pool de tampons pour pouvoir disposer de RAM là-bas.

Le fichier par table est activé.

J'utilise une machine Linux.

RolandoMySQLDBA · Accepted Answer

Le plus grand tableau que vous avez représente 16,47% (28/170) du total des données. Même si la table a été fortement écrite et très lue, les 28 G de la table ne sont pas tous chargés dans le pool de mémoire tampon à un moment donné. Ce que vous devez calculer est la quantité de pool de tampons InnoDB chargée à un moment donné sur le serveur DB actuel .

Voici une façon plus granulaire de déterminer innodb_buffer_pool_size pour un nouveau serveur DB étant donné l'ensemble de données actuellement chargé dans le pool de mémoire tampon InnoDB du serveur DB actuel.

Exécutez ce qui suit sur votre instance MySQL actuelle (serveur à partir duquel vous migrez)

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_data'; -- IBPDataPages SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_total'; -- IBPTotalPages SHOW GLOBAL STATUS LIKE 'Innodb_page_size'; -- IPS

Exécutez la formule IBPPctFull = IBPDataPages * 100.0 / IBPTotalPages.

SET @IBPDataPages = (SELECT VARIABLE_VALUE FROM information_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_pages_data'); -- SELECT @IBPDataPages; SET @IBPTotalPages = (SELECT VARIABLE_VALUE FROM information_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_pages_total'); -- SELECT @IBPTotalPages; SET @IBPPctFull = CAST(@IBPDataPages * 100.0 / @IBPTotalPages AS DECIMAL(5,2)); SELECT @IBPPctFull;

Si IBPPctFull est de 95% ou plus, vous devez définir innodb_buffer_pool_size à 75% de la RAM du serveur de base de données.

Si IBPPctFull est inférieur à 95%, exécutez cette formule: IBPSize = IPS X IBPDataPages / (1024*1024*1024) X 1.05.

SET @IBPSize = (SELECT VARIABLE_VALUE FROM information_schema.global_status WHERE VARIABLE_NAME = 'Innodb_page_size'); -- SELECT @IBPSize; SET @IBPDataPages = (SELECT VARIABLE_VALUE FROM information_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_pages_data'); -- SELECT @IBPDataPages; SET @IBPSize = concat(ROUND(@IBPSize * @IBPDataPages / (1024*1024*1024) * 1.05, 2), ' GB' ); SELECT @IBPSize;

Le nombre pour IBPSize (en Go) est le nombre qui correspond le mieux à votre ensemble de données de travail réel.

Maintenant, si IBPSize est encore trop grand pour la plus grande configuration Amazon EC2 RAM, utilisez 75% de la RAM pour le serveur de base de données Amazon EC2).

Craig Efrein · Answer

Je fournis cette réponse comme information complémentaire à la réponse de Rolando ci-dessous.

Avant la mise en production du serveur

Calculez innodb_buffer_pool_size sur la base des plus grandes tables qui sont le plus souvent utilisées par MySQL. Pour identifier les plus grandes tables en fonction de leur taille dans la base de données, vous pouvez utiliser ce script:

select table_schema, table_name, round(data_length/1024/1024,2) as size_mb from information_schema.tables where table_schema like 'my_database' order by size_mb desc; +--------------+-------------------------+---------+ | table_schema | table_name | size_mb | +--------------+-------------------------+---------+ | heavybidder | user | 522.55| | heavybidder | bid | 121.52| | heavybidder | item_for_sale | 10.52| | heavybidder | account_user | 5.02 | | heavybidder | txn_log | 4.02 | | heavybidder | category | 0.02 | +--------------+-------------------------+---------+

Maintenant que nous savons quelles tables sont les plus grandes de notre base de données, nous devons déterminer celles qui sont les plus fréquemment utilisées. Pour ce faire, j'utiliserais un programme de profilage comme Jet Profiler (JP) pour voir quelles tables sont les plus utilisées. JP vous montrera quelles tables sont consultées le plus fréquemment. Voici une capture d'écran de cette section dans JP

enter image description here

Donc, avec cela à l'esprit, je sais maintenant que les tables d'utilisateurs et d'enchères occupent environ 640 Mo d'espace disque, elles sont très fréquemment utilisées selon JP et ce qui signifie que MySQL va stocker leurs index et données dans le pool de tampons comme Rolando mentionne ci-dessous dans ses commentaires.

Pour m'assurer que MySQL avait suffisamment de mémoire pour stocker les données de mes tables les plus grandes et les plus fréquemment utilisées, je définirais alors innodb_buffer_pool_size à 640 Mo.

Il y a quelques considérations supplémentaires, mais elles ne s'appliquent pas à la taille innodb_buffer_pool_size.

S'agit-il d'un système 32 bits ou 64 bits? Dans un système 32 bits, vous êtes limité à 4 Go, sauf si vous activez PAE. Sous Windows, cela signifie exécuter les éditions Windows Enterprise ou Datacenter.

De combien de mémoire les autres processus en cours d'exécution sur votre système ont-ils besoin? Sur un serveur MySQL dédié, je laisserai entre 5% et 10% pour l'OS. Sous Windows, vous pouvez utiliser Process Explorer pour analyser l'utilisation de la mémoire. Sous Linux, vous avez sysstat, free, htop, top et vmstat.

La base de données est-elle composée uniquement de tables Innodb ou d'un mélange d'Innodb et de MyISAM? S'il s'agit d'un mélange des deux, je mettrai de la mémoire de côté pour le key_cache, les variables de jointure, le cache de requête, etc. Vous pourrez ensuite calculer votre taux d'accès MyISAM une fois le serveur en production.