Как буферный пул обрабатывает условия нехватки памяти?
Пересказ статьи Randolph West. How does the buffer pool handle low memory conditions?
Одним из больших клише в профессиональном словаре данных (после "это зависит") является то, что вы всегда даете SQL Server столько RAM, сколько можете себе позволить, поскольку он будет всю ее использовать. Но что произойдет, если SQL Server не хватает памяти?
Недавно в комментариях к моей статье о том, как работает буферный пул , задали вопрос:
Это отличный вопрос. Я потратил 30 минут на написание ответа, а затем решил написать статью, чтобы немного прояснить это.
В комментарии спрашивается, может ли TempDB играть роль буферного пула в условиях нехватки памяти, и простой ответ - нет. Если вы хотите увеличить емкость буферного пула вы делаете одно из:
Но это непростой вопрос, поэтому простой ответ не годится. Более правильным ответом является то, что SQL Server управляет буферным пулом, используя сочетание контрольных точек базы данных для грязных страниц, алгоритм FIFO для чистых страниц и TempDB на стороне.
Чтобы освежить вашу память (каламбур), файл данных хранит ваши данные в состоянии покоя. Буферный пул (большая часть вашей RAM) управляет страницами данных, которые читаются и изменяются. Все изменения записываются в журнал транзакций до того, как они изменились в памяти. Поэтому, если что-то пойдет не так, и SQL Server должен восстановиться после сбоя, он просто должен прочитать журнал транзакций от последнего известного корректного состояния во времени и откатить незафиксированные изменения, а затем накатить зафиксированные изменения. Это "последнее известное корректное состояния во времени" называется контрольной точкой.
Хотя SQL Server гарантирует, что все изменения записываются в файл журнала транзакций прежде, чем данные изменятся в памяти, ядро базы данных не записывает все изменения в файл данных, когда они происходят, поскольку это замедляло бы работу. Это делает асинхронный процесс, называемый ленивой записью, в фоновом режиме. Это не так важно, поскольку, в конечном итоге, изменения записываются в файл журнала транзакций.
Кроме того, контрольная точка устанавливается периодически. Приблизительно каждые 6 секунд (эта установка настраивается) SQL Server просматривает буферный пул и записывает все грязные (модифицированные) страницы на жесткий диск, а также любые записи журнала транзакций, которые еще находятся в памяти. Контрольные точки - это фундаментальная часть системы восстановления после сбоя.
Кажется, вся эта штука с контрольными точками упускает суть заданного вопроса: когда SQL Server обрабатывает набор данных и испытывает недостаток памяти в буферном пуле, чтобы разместить их там, что тогда?
В случае большого количества чтений (например, полное сканирование кластеризованного индекса или полное сканирование таблицы), когда таблица не помещается в память, SQL Server ищет самые старые чистые (немодифицированные) страницы и говорит им до свидания. Точнее, она помечает эту часть памяти как свободную для работы, поэтому новые страницы данных могут размещаться на этом месте. Счетчик ожидаемой продолжительности жизни страницы (Page Life Expectancy) срабатывает, когда эта страница очищается.
Запрос будет "сливать на диск" и использовать временное место в TempDB, только если это необходимо для выполнения того, что требует этого (типа операций сортировки), что, в свою очередь, также зависит от памяти, выделенной запросу. Многие вещи сливают данные на диск постоянно, и Erik Darling писал о том, когда и почему это происходит.
Ключевым моментом является то, что если происходит чтение (SELECT), то никакие данные не меняются. В буферном пуле могут находиться новые страницы данных, но они не являются грязными страницами, поэтому они могут быть очищены в любой момент. Если на SQL Server происходит сбой, и TempDB была заново создана, потери данных не произошло, потому что Гордон не получил свой отчет. Затем каждые шестьдесят секунд или около того грязные страницы также сбрасываются на диск с целью восстановления после сбоя.
Для больших записей, которые не помещаются в буферный пул, на помощь приходит журнал транзакций. Каждый запрос, который выполняет модификацию (INSERT, DELETE, UPDATE) записывается в журнал. Точнее, в файл журнала сначала записываются данные, которые будут подвергаться изменению запросом. Поэтому, если по какой-либо причине запросу потребуется выполнить откат, журнал будет содержать транзакционно согласованную версию данных. Затем выполняется модификация с записью в журнал транзакций. Как только транзакция фиксируется, страницы изменяются в памяти, после чего операция контрольной точки сбрасывает изменения на диск.
Если места в памяти недостаточно, запись изменения займет больше времени, а количество операций автоматической установки контрольной точки может увеличиться за это время. Кроме того, запросы просто не стартуют, пока в буферном пуле не будет достаточно места, а вы сможете мониторить Wait Statistics (статистика ожиданий), чтобы увидеть, имеет ли это место.
Если ваш сервер испытывает проблемы с памятью, и Гордону действительно необходим этот отчет к пятничному обеду, SQL Server будет, вероятно, использовать пространство в TempDB, чтобы помочь выполнить отчет, но это не является заменой буферного пула. Чистые страницы будут удаляться по мере необходимости. Если другие люди вносят изменения в другие части базы данных, эти грязные страницы (как только они фиксируются) также сбрасываются на диск во время операции контрольной точки. Вам нужно столько памяти, сколько вы можете получить.
Что случится, если страницы данных нет в буферном пуле, и в буферном пуле недостаточно места? Будет ли буферный пул использовать TempDB, [и] будет ли TempDB помещать свои грязные страницы в буферный пул?
Это отличный вопрос. Я потратил 30 минут на написание ответа, а затем решил написать статью, чтобы немного прояснить это.
Грязные страницы и контрольные точки
В комментарии спрашивается, может ли TempDB играть роль буферного пула в условиях нехватки памяти, и простой ответ - нет. Если вы хотите увеличить емкость буферного пула вы делаете одно из:
- уменьшаете то, что попадает в буферный пул;
- покупаете больше физической памяти;
- включаете расширение буферного пула.
Но это непростой вопрос, поэтому простой ответ не годится. Более правильным ответом является то, что SQL Server управляет буферным пулом, используя сочетание контрольных точек базы данных для грязных страниц, алгоритм FIFO для чистых страниц и TempDB на стороне.
Чтобы освежить вашу память (каламбур), файл данных хранит ваши данные в состоянии покоя. Буферный пул (большая часть вашей RAM) управляет страницами данных, которые читаются и изменяются. Все изменения записываются в журнал транзакций до того, как они изменились в памяти. Поэтому, если что-то пойдет не так, и SQL Server должен восстановиться после сбоя, он просто должен прочитать журнал транзакций от последнего известного корректного состояния во времени и откатить незафиксированные изменения, а затем накатить зафиксированные изменения. Это "последнее известное корректное состояния во времени" называется контрольной точкой.
Хотя SQL Server гарантирует, что все изменения записываются в файл журнала транзакций прежде, чем данные изменятся в памяти, ядро базы данных не записывает все изменения в файл данных, когда они происходят, поскольку это замедляло бы работу. Это делает асинхронный процесс, называемый ленивой записью, в фоновом режиме. Это не так важно, поскольку, в конечном итоге, изменения записываются в файл журнала транзакций.
Кроме того, контрольная точка устанавливается периодически. Приблизительно каждые 6 секунд (эта установка настраивается) SQL Server просматривает буферный пул и записывает все грязные (модифицированные) страницы на жесткий диск, а также любые записи журнала транзакций, которые еще находятся в памяти. Контрольные точки - это фундаментальная часть системы восстановления после сбоя.
Что насчет TempDB?
Кажется, вся эта штука с контрольными точками упускает суть заданного вопроса: когда SQL Server обрабатывает набор данных и испытывает недостаток памяти в буферном пуле, чтобы разместить их там, что тогда?
В случае большого количества чтений (например, полное сканирование кластеризованного индекса или полное сканирование таблицы), когда таблица не помещается в память, SQL Server ищет самые старые чистые (немодифицированные) страницы и говорит им до свидания. Точнее, она помечает эту часть памяти как свободную для работы, поэтому новые страницы данных могут размещаться на этом месте. Счетчик ожидаемой продолжительности жизни страницы (Page Life Expectancy) срабатывает, когда эта страница очищается.
Запрос будет "сливать на диск" и использовать временное место в TempDB, только если это необходимо для выполнения того, что требует этого (типа операций сортировки), что, в свою очередь, также зависит от памяти, выделенной запросу. Многие вещи сливают данные на диск постоянно, и Erik Darling писал о том, когда и почему это происходит.
Ключевым моментом является то, что если происходит чтение (SELECT), то никакие данные не меняются. В буферном пуле могут находиться новые страницы данных, но они не являются грязными страницами, поэтому они могут быть очищены в любой момент. Если на SQL Server происходит сбой, и TempDB была заново создана, потери данных не произошло, потому что Гордон не получил свой отчет. Затем каждые шестьдесят секунд или около того грязные страницы также сбрасываются на диск с целью восстановления после сбоя.
Для больших записей, которые не помещаются в буферный пул, на помощь приходит журнал транзакций. Каждый запрос, который выполняет модификацию (INSERT, DELETE, UPDATE) записывается в журнал. Точнее, в файл журнала сначала записываются данные, которые будут подвергаться изменению запросом. Поэтому, если по какой-либо причине запросу потребуется выполнить откат, журнал будет содержать транзакционно согласованную версию данных. Затем выполняется модификация с записью в журнал транзакций. Как только транзакция фиксируется, страницы изменяются в памяти, после чего операция контрольной точки сбрасывает изменения на диск.
Если места в памяти недостаточно, запись изменения займет больше времени, а количество операций автоматической установки контрольной точки может увеличиться за это время. Кроме того, запросы просто не стартуют, пока в буферном пуле не будет достаточно места, а вы сможете мониторить Wait Statistics (статистика ожиданий), чтобы увидеть, имеет ли это место.
Заключение
Если ваш сервер испытывает проблемы с памятью, и Гордону действительно необходим этот отчет к пятничному обеду, SQL Server будет, вероятно, использовать пространство в TempDB, чтобы помочь выполнить отчет, но это не является заменой буферного пула. Чистые страницы будут удаляться по мере необходимости. Если другие люди вносят изменения в другие части базы данных, эти грязные страницы (как только они фиксируются) также сбрасываются на диск во время операции контрольной точки. Вам нужно столько памяти, сколько вы можете получить.
Обратные ссылки
Нет обратных ссылок
Автор не разрешил комментировать эту запись
Комментарии
Показывать комментарии Как список | Древовидной структурой