Comprendre les statistiques du pool de mémoire tampon INNODB

Après avoir lu cette page dans la documentation mysql , j'ai essayé de comprendre notre utilisation actuelle d'InnoDB. Actuellement, nous allouons 6 Go de RAM pour le pool de tampons. La taille de notre base de données est à peu près la même. Voici la sortie de show engine innodb status\G(nous exécutons la v5.5)

----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 6593445888; in additional pool allocated 0
Dictionary memory allocated 1758417
Buffer pool size   393215
Free buffers       853
Database pages     360515
Old database pages 133060
Modified db pages  300
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 7365790, not young 23099457
0.00 youngs/s, 0.00 non-youngs/s
Pages read 1094342, created 185628, written 543182148
0.00 reads/s, 0.00 creates/s, 37.32 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 360515, unzip_LRU len: 0
I/O sum[2571]:cur[0], unzip sum[0]:cur[0]

Je voulais savoir dans quelle mesure nous utilisons le cache tampon. Après avoir jeté un premier coup d'œil à la sortie, il est apparu que nous l'utilisons effectivement, basé sur le Pages made younget not youngavons des chiffres en eux et Buffer pool hit rate is 1000 / 10000(ce que j'ai vu ailleurs sur le Web que cela signifie qu'il est utilisé assez intensément. Vrai?)

Ce qui me lance dans une boucle, c'est pourquoi le young-making rateet notsont tous deux à 0/1000 et les accès young/set non-young/ssont tous les deux à 0. Tout cela indiquerait qu'il n'est pas utilisé du tout, non?

Quelqu'un peut-il aider à comprendre cela?

 Buffer pool hit rate is 1000 / 1000

C'est la seule valeur vraiment significative dans la situation dans laquelle vous vous trouvez ... et cette situation est que vous avez la chance d'avoir un pool de tampons avec un taux de réussite parfait de 100%. Ne pas sur-analyser le reste, car il n'y a rien que vous devez changer, sauf si le système d'exploitation du serveur manque de mémoire, ce qui provoque un échange.

Les valeurs young / not young ne sont pas intéressantes dans un cas où il n'y a aucune pression sur le pool de mémoire tampon. InnoDB l'utilise, il ne fait rien sans lui. Si le pool est trop petit, les pages sont expulsées et de nouvelles pages sont lues et les autres statistiques vous aident à comprendre cela ... mais c'est un problème que vous ne semblez pas avoir.

L'espace "inutilisé" gratuit dans la piscine ne sera jamais négligé ou laissé inactif par InnoDB s'il est nécessaire pour une raison quelconque, donc le fait qu'il soit gratuit signifie seulement que vous avez une certaine marge de manœuvre pour vous étendre en fonction de la taille de votre travail l'ensemble de données augmente.

C'est tout ce que cela signifie, à moins, bien sûr, que vous ayez récemment redémarré le serveur, auquel cas il est incomplet. Le serveur doit exécuter une période complète d'utilisation "normale" (y compris des sauvegardes complètes) avant que les statistiques racontent toute l'histoire. ... que ce soit une heure, un jour, une semaine, un mois ou une année, cela dépend de votre application.

The Buffer pool size 393215 Il s'agit de pages et non d'octets.

Pour voir la taille du pool de mémoire tampon en Go, exécutez ceci:

SELECT FORMAT(BufferPoolPages*PageSize/POWER(1024,3),2) BufferPoolDataGB FROM
(SELECT variable_value BufferPoolPages FROM information_schema.global_status
WHERE variable_name = 'Innodb_buffer_pool_pages_total') A,
(SELECT variable_value PageSize FROM information_schema.global_status
WHERE variable_name = 'Innodb_page_size') B;

Database pages 360515 Il s'agit du nombre de pages contenant des données dans le pool de tampons

Pour voir la quantité de données dans la taille du pool de mémoire tampon en Go, exécutez ceci:

SELECT FORMAT(BufferPoolPages*PageSize/POWER(1024,3),2) BufferPoolDataGB FROM
(SELECT variable_value BufferPoolPages FROM information_schema.global_status
WHERE variable_name = 'Innodb_buffer_pool_pages_data') A,
(SELECT variable_value PageSize FROM information_schema.global_status
WHERE variable_name = 'Innodb_page_size') B;

Pour voir le pourcentage du pool de tampons utilisé, exécutez ceci:

SELECT CONCAT(FORMAT(DataPages*100.0/TotalPages,2),' %') BufferPoolDataPercentage FROM
(SELECT variable_value DataPages FROM information_schema.global_status
WHERE variable_name = 'Innodb_buffer_pool_pages_data') A,
(SELECT variable_value TotalPages FROM information_schema.global_status
WHERE variable_name = 'Innodb_buffer_pool_pages_total') B;

Modified db pages 300Il s'agit du nombre de pages du pool de tampons qui doivent être réécrites dans la base de données. Ils sont également appelés pages sales.

Pour voir l'espace occupé par les pages sales, exécutez ceci:

SELECT FORMAT(DirtyPages*PageSize/POWER(1024,3),2) BufferPoolDirtyGB FROM
(SELECT variable_value DirtyPages FROM information_schema.global_status
WHERE variable_name = 'Innodb_buffer_pool_pages_dirty') A,
(SELECT variable_value PageSize FROM information_schema.global_status
WHERE variable_name = 'Innodb_page_size') B;

Pour voir le pourcentage de pages sales, exécutez ceci:

SELECT CONCAT(FORMAT(DirtyPages*100.0/TotalPages,2),' %') BufferPoolDirtyPercentage FROM
(SELECT variable_value DirtyPages FROM information_schema.global_status
WHERE variable_name = 'Innodb_buffer_pool_pages_dirty') A,
(SELECT variable_value TotalPages FROM information_schema.global_status
WHERE variable_name = 'Innodb_buffer_pool_pages_total') B;

En ce qui concerne les autres choses à l'écran, exécutez ceci:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool%';

Vous verrez toutes les variables d'état pour le pool de tampons. Vous pouvez appliquer les mêmes requêtes à tout ce que vous devez examiner.

Je ne suis pas d'accord avec l'évaluation selon laquelle "vous avez la chance d'avoir un pool de tampons avec un taux de réussite parfait de 100%"

En haut de la sortie (qui est coupée), se trouve une ligne quelque chose comme:

Per second averages calculated from the last 16 seconds

Cela me dit qu'aucune lecture n'a eu lieu au cours des 16 dernières secondes, ce qui vous donne (artificiellement) un score parfait de «1000/1000».

0.00 reads/s, 0.00 creates/s, 37.32 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000

Pendant ce temps, il y a eu quelques écritures. Ces écritures ont peut-être été différées pour vider les pages «sales» ou nettoyer les index du «tampon de changement».

Il n'y avait probablement pas non plus d'activité dans la zone jeune / chaude au cours des 16 dernières secondes.

Le pool de tampons est divisé en deux parties, une liste jeune et une liste non jeune. Le taux de création indique le nombre de pages dans les pools de mémoire tampon qui sont mélangées entre les deux listes.

Les pages rendues jeunes ne sont pas des pages jeunes créées (c'est-à-dire qu'elles sont lues hors du cache. Les pages non jeunes sont des pages déplacées de la liste des jeunes parce qu'elles sont trop anciennes ou parce que la liste des jeunes est pleine.

Le taux de déplacement des pages entre les deux dépend de la quantité de pool de tampons actuellement utilisée par rapport à la taille du jeune pool. Définir à zéro signifie que votre ensemble actif (les pages que vous utilisez) est plus petit que le jeune pool.