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 utilisons 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 young et not young contiennent des chiffres et Buffer pool hit rate is 1000 / 10000 (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 rate et not sont tous les deux à 0/1000 et le young/s et non-young/s les accès sont tous les deux à 0. Tout cela indiquerait que ce n'est pas du tout utilisé, non?
Quelqu'un peut-il aider à comprendre cela?
Buffer pool hit rate is 1000 / 1000
C'est la valeur seulement 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 de 100% parfait. Ne pas sur-analyser le reste, car il n'y a rien que vous devez changer, à moins que 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ù la pression sur le pool de tampons est nulle. 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 jamais sera négligé ou laissé inactif par InnoDB si cela est nécessaire pour une raison quelconque, donc le fait qu'il soit gratuit signifie seulement que vous avez une marge de manœuvre pour vous étendre à mesure que la taille de votre ensemble de données de travail 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 300 Il 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 que non les lectures se sont produites au cours des 16 dernières secondes, vous donnant ainsi (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. Il s'agissait peut-être d'écrits différés 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 mémoire tampon 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 dans le 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.