Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
InnoDB поддерживает область хранения, названную пулом
буферов для того, чтобы кэшировать данные, и индексирует в памяти. Знание, как InnoDB работы пула буферов, и использование в своих интересах этого, чтобы сохранить
данные, к которым часто получают доступ, в памяти, являются важным аспектом настройки MySQL.
Идеально, Вы устанавливаете размер пула буферов к столь же большому значению как практичный, оставляя достаточно
памяти для других процессов на сервере, чтобы работать без чрезмерного оповещения. Чем больше пул буферов, тем
больше InnoDB действия как база данных в памяти, читая данные из диска однажды и
затем получая доступ к данным из памяти во время последующих чтений. Пул буферов даже данные кэшей, измененные
вставкой и операциями обновления, так, чтобы записи на диск могли группироваться для лучшей производительности.
В зависимости от типичной рабочей нагрузки на Вашей системе Вы могли бы скорректировать пропорции частей в пределах пула буферов. Можно настроить способ, которым выбирает пул буферов, какие блоки кэшировать, как только это заполняется, чтобы сохранить данные, к которым часто получают доступ, в памяти несмотря на внезапные шипы действия для операций, таких как резервные копии или создание отчетов.
С 64-разрядными системами с размерами памяти большой емкости можно разделить пул буферов на многократные части, чтобы минимизировать конкуренцию для структур памяти среди параллельных операций. Для получения дополнительной информации см. Раздел 14.2.4.2.27, "Улучшения Производительности от Многократных Пулов буферов".
InnoDB управляет пулом как списком, используя изменение последнего использованного
алгоритма (LRU). Когда комната необходима, чтобы добавить новый блок к пулу, InnoDB
выселяет последний использованный блок и добавляет новый блок к середине списка. Эта "стратегия вставки средней точки" обрабатывает
список как два подсписка:
В голове, подсписке "новых" (или "молодой") блоки, к которым недавно получили доступ.
В хвосте, подсписке "старых" блоков, к которым получили доступ менее недавно.
Этот алгоритм сохраняет блоки, которые в большой степени используются запросами в новом подсписке. Старый подсписок содержит менее используемые блоки; эти блоки являются кандидатами на замещение.
Алгоритм LRU работает следующим образом по умолчанию:
3/8 пула буферов посвящается старому подсписку.
Средняя точка списка является границей, где хвост нового подсписка встречает главу старого подсписка.
Когда InnoDB читает блок в пул буферов, это
первоначально вставляет это в средней точке (глава старого подсписка). Блок может быть считан в том,
потому что он требуется для определенной пользователем работы, такой как SQL-запрос, или как часть
работы чтения вперед,
выполняемой автоматически InnoDB.
Доступ к блоку в старом подсписке делает это "молодым", перемещая это к главе пула буферов (глава нового подсписка). Если блок был считан в том, потому что он требовался, первый доступ сразу происходит, и блок делается молодым. Если блок был считан в должном, чтобы читать вперед, первый доступ сразу не происходит (и не мог бы произойти вообще прежде, чем блок выселяется).
Поскольку база данных работает, блоки в пуле буферов, к которым не получают доступ "возраст", перемещаясь к хвосту списка. Блоки и в новом и в старом возрасте подсписков как другие блоки делаются новыми. Блоки в старом подсписке также возраст как блоки вставляются в средней точке. В конечном счете блок, который остается неиспользованным довольно долго, достигает хвоста старого подсписка и выселяется.
По умолчанию блоки, считанные запросами сразу, перемещаются в новый подсписок, означая, что они будут оставаться
в пуле буферов в течение долгого времени. Сканирование таблицы (такой как выполняющийся для mysqldump работы, или a SELECT
оператор без WHERE пункт), может принести большой объем данных в пул буферов и
выселить эквивалентное количество более старых данных, даже если новые данные никогда не используются снова.
Точно так же блоки, которые загружаются фоновым потоком чтения вперед и затем получаются доступ только однажды
перемещение главе нового списка. Эти ситуации могут продвинуть часто используемые блоки к старому подсписку, где
они становятся подвергающимися замещению.
Несколько InnoDB системные переменные управляют размером пула буферов и позволяют
Вам настраивать алгоритм LRU:
Определяет размер пула буферов. Если Ваш пул буферов является небольшим, и у Вас есть достаточная
память, делая больше пул может улучшить производительность, уменьшая количество дискового
ввода-вывода, необходимого как доступ запросов InnoDB таблицы.
Делит пул буферов на пользовательское конкретное количество отдельных областей, каждого с его
собственным списком LRU и связанными структурами данных, чтобы уменьшить конкуренцию во время
параллельных операций чтения памяти и операций записи. Эта опция вступает в силу только, когда Вы
устанавливаете innodb_buffer_pool_size к размеру 1 гигабайта или
больше. Полный размер, который Вы определяете, делится среди всех пулов буферов. Для лучшей
эффективности определите комбинацию innodb_buffer_pool_instances и innodb_buffer_pool_size так, чтобы каждый экземпляр пула буферов
составил по крайней мере 1 гигабайт.
Определяет приблизительный процент пула буферов это InnoDB
использование для старого блочного подсписка. Диапазон значений 5 - 95. Значение по умолчанию 37 (то
есть, 3/8 пула).
Определяет, сколько времени в миллисекундах (мс) блок, вставленный в старый подсписок, должен остаться там после его первого доступа прежде, чем это сможет быть перемещено в новый подсписок. Значение по умолчанию 0: блок, вставленный в старый подсписок, перемещается в новый подсписок, когда Innodb выселил 1/4 страниц вставленного блока от пула буферов, независимо от того как вскоре после вставки доступ происходит. Если значение больше чем 0, блоки остаются в старом подсписке, пока доступ не происходит, по крайней мере, что много мс после первого доступа. Например, значение 1000 причин блокирует, чтобы остаться в старом подсписке в течение 1 секунды после первого доступа прежде, чем они станут имеющими право переместиться в новый подсписок.
Установка innodb_old_blocks_time
больше чем 0 препятствует тому, чтобы одноразовые сканирования таблицы лавинно разослали новый подсписок с
блоками, используемыми только для сканирования. К строкам в блочном чтении в для сканирования получают доступ
много раз в быстрой последовательности, но блок неиспользован после этого. Если innodb_old_blocks_time устанавливается в значение, больше чем время
обработать блок, блок остается в "старом"
подсписке и возрастах к хвосту списка быть выселенным быстро. Таким образом, блоки, используемые только для
одноразового сканирования, не действуют в ущерб в большой степени используемым блокам в новом подсписке.
innodb_old_blocks_time
может быть установлен во времени выполнения, таким образом, можно изменить его временно, выполняя операции,
такие как сканирования таблицы и дампы:
SET GLOBAL innodb_old_blocks_time = 1000;... perform
queries that scan tables ...SET GLOBAL innodb_old_blocks_time = 0;
Эта стратегия не применяется, если Ваше намерение состоит в том, чтобы "нагреть"
пул буферов, заполняя ее контентом таблицы. Например, оценочные испытания часто выполняют таблицу или
индексируют сканирование при запуске сервера, потому что те данные обычно были бы в пуле буферов после периода
нормальной эксплуатации. В этом случае, отпуск innodb_old_blocks_time набор к 0, по крайней мере пока фаза разминки не
полна.
Вывод от Монитора Стандарта InnoDB содержит несколько полей в BUFFER POOL AND
MEMORY раздел, которые принадлежат работе пула буферов алгоритм LRU:
Old database pages: Число страниц в старом подсписке
пула буферов.
Pages made young, not young: Число старых страниц,
которые были перемещены к главе пула буферов (новый подсписок), и число страниц, которые остались в
старом подсписке, не будучи сделанным новым.
youngs/s non-youngs/s: Число доступов к старым
страницам, которые привели к созданию их молодой или нет. Эта метрика отличается от того из предыдущего
элемента двумя способами. Во-первых, это имеет отношение только к старым страницам. Во-вторых, это
основано на числе доступов к страницам а не числе страниц. (Могут быть многократные доступы к данной
странице, все из которых считаются.)
young-making rate: Хиты, которые заставляют блоки
перемещаться к главе пула буферов.
not: Хиты, которые не заставляют блоки перемещаться к
главе пула буферов (из-за задержки, не встречаемой).
young-making уровень и not уровень не будет обычно
составлять в целом полную частоту успешных обращений пула буферов. Хиты для блоков в старом подсписке заставляют
их перемещаться в новый подсписок, но хиты к блокам в новом подсписке заставляют их перемещаться к главе списка,
только если они - определенное расстояние от главы.
Предыдущая информация от Монитора может помочь Вам принять LRU настраивающиеся решения:
Если Вы видите очень низко youngs/s значения, когда у
Вас нет большого продолжения сканирований, которое указывает, что Вы, возможно, должны были бы или
уменьшить время задержки, или увеличили бы процент пула буферов, используемого для старого подсписка.
Увеличение процента делает старый подсписок больше, таким образом, блоки в том подсписке занимают больше
времени, чтобы переместиться в хвост и быть выселенными. Это увеличивает вероятность, что к ним получат
доступ снова и сделаны молодым.
Если Вы не видите много из non-youngs/s когда Вы
делаете большие сканирования таблицы (и много из youngs/s), чтобы настроить
Ваше значение задержки, чтобы быть больше.
В секунду средние числа, обеспеченные в InnoDB Вывод монитора основан
на прошедшем времени между текущим временем и в прошлый раз InnoDB Вывод
монитора был напечатан.
Для получения дополнительной информации о Мониторах InnoDB, см. Раздел
14.2.4.4,"SHOW ENGINE INNODB STATUS и InnoDB
Мониторы".