Понимание статистики буферного пула INNODB

Прочитав эту страницу в документации по MySQL , я попытался разобраться в нашем текущем использовании InnoDB. В настоящее время мы выделяем 6 ГБ ОЗУ для пула буферов. Размер нашей базы данных примерно одинаков. Вот вывод из show engine innodb status\G(мы работаем 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]

Я хотел знать, насколько хорошо мы используем буферный кеш. После того, как первоначально поглядывая на выходе, оказалось , что мы на самом деле использовать его, основанный прочь Pages made youngи not youngимеют номера в них и Buffer pool hit rate is 1000 / 10000(которые я видел в другом месте в Интернете , что это означает , что это используется довольно тяжело. Правда?)

То, что бросает меня через цикл, - это то, почему young-making rateи notоба имеют 0/1000, а young/sи non-young/sдоступы имеют оба значения 0. Все это указывает на то, что он вообще не используется, верно?

Может ли кто-нибудь помочь разобраться в этом?

 Buffer pool hit rate is 1000 / 1000

Это единственное действительно значимое значение в ситуации, в которой вы находитесь ... и эта ситуация заключается в том, что вам повезло иметь буферный пул с идеальным 100% коэффициентом попадания. Не переоценивайте остальную часть этого, потому что вам нечего менять, если только у серверной ОС недостаточно памяти, что приводит к перестановке.

Молодые / не молодые значения не интересны в случае нулевого давления на буферный пул. InnoDB использует его, он ничего не делает без него. Если пул слишком мал, страницы выселяются, а новые страницы считываются, и другие статистические данные помогают вам понять это ... но это проблема, которой у вас, похоже, нет.

InnoDB никогда не будет пренебрегать свободным «неиспользуемым» пространством в пуле и не оставлять его без дела, если это вообще необходимо по какой-либо причине, поэтому тот факт, что это свободное пространство, означает лишь то, что у вас есть пространство для дыхания, которое можно расширить в соответствии с размером вашей работы набор данных растет.

Это все, что означает, если, конечно, вы недавно не перезапустили сервер, и в этом случае он не завершен. Сервер должен пройти полный период «нормального» использования (включая полное резервное копирование), прежде чем статистика расскажет всю историю. ... будь то час, день, неделя, месяц или год, зависит от вашего приложения.

The Buffer pool size 393215 Это на страницах, а не в байтах.

Чтобы увидеть размер пула буферов в ГБ, запустите:

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 Это количество страниц с данными внутри пула буферов.

Чтобы увидеть объем данных в размере пула буферов в ГБ, запустите:

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;

Чтобы увидеть процент использования пула буферов, запустите:

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Это количество страниц в пуле буферов, которые необходимо записать обратно в базу данных. Они также упоминаются как грязные страницы.

Чтобы увидеть пространство, занятое грязными страницами, запустите:

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;

Чтобы увидеть процент грязных страниц, запустите это:

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;

Что касается других вещей на дисплее, запустите это:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool%';

Вы увидите все переменные состояния для пула буферов. Вы можете применять те же запросы к тому, что вам нужно изучить.

Я не согласен с оценкой, что «вам достаточно повезло, что у вас есть буферный пул с идеальным 100% -ным коэффициентом попадания»

В верхней части вывода (который отрублен) есть строка, похожая на:

Per second averages calculated from the last 16 seconds

Это говорит мне о том, что за последние 16 секунд не было ни одного чтения, тем самым (искусственно) давая вам идеальный счет «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

Между тем было несколько писем. Возможно, это были отложенные записи либо для очистки «грязных» страниц, либо для очистки индексов из «буфера изменений».

Вероятно, в последние 16 секунд не было активности в молодой / горячей области.

Буферный пул разделен на две части: список молодых и список не молодых. Скорость создания показывает, сколько страниц в буферных пулах перетасовывается между двумя списками.

Страницы, созданные молодыми, создаются не молодыми страницами (т.е. считываются из кэша. Страницы, созданные молодыми, являются страницами, перемещенными из списка молодых, потому что они либо слишком старые, либо потому, что молодой список заполнен.

Скорость перемещения страниц между ними зависит от того, какая часть буферного пула в настоящее время используется по сравнению с размером молодого пула. Установка на ноль означает, что ваш активный набор (страницы, которые вы используете) меньше, чем молодой пул.