Que définir innodb_buffer_pool et pourquoi ..?

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

Je dois réajuster la taille innodb_buffer_pool pour de meilleures performances.La taille maximale d'une table InnoDB (Index + données) 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 régler la RAM en fonction des statistiques actuelles d'innodb, c'est pourquoi j'ai besoin de la taille du pool de tampons pour que nous puissions y avoir de la RAM disponible.

Fichier par table est activé.

J'utilise une machine Linux.

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 de base de données, étant donné l'ensemble de données actuellement chargé dans le pool de mémoire tampon InnoDB du serveur de base de données 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 sur 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 de RAM Amazon EC2, utilisez 75% de la RAM pour le serveur de base de données Amazon EC2.

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

Avant que le serveur ne soit en production

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 importantes de notre base de données, nous devons déterminer celles qui sont les plus 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

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.

Une fois le serveur en production

Quel est le taux de réussite actuel pour Innodb?

1 - (innodb_buffer_pool_reads / innodb_buffer_pool_read_requests).

Quel est le taux de réussite du cache de clé

1 - (Key_reads / Key_read_requests)

J'essaie généralement d'obtenir le rapport le plus près possible de 100%.

Dans quelle mesure vos tables s'intègrent-elles dans le pool de mémoire tampon?

Vous pouvez également voir dans quelle mesure vos données de table s'intègrent dans votre buffer_pool en vous référant à ce lien, qui fournit un moyen d'afficher "combien de pages sont dans le pool de tampons pour une table donnée (cnt), combien d'entre elles sont sales (sales) , et quel est le pourcentage d'ajustements d'index en mémoire (fit_pct). " S'applique uniquement au serveur Percona

http://www.mysqlperformanceblog.com/2010/12/09/how-well-does-your-table-fits-in-innodb-buffer-pool/