Я понимаю, что установка привилегий для страниц блокировки в памяти для учетной записи службы, содержащей службы SQL2005 / 2008 в 64-битной системе, использует API AWE и эффективно предотвращает выгрузку пула буферов SQL на диск, что повышает стабильность.
Но если у вас есть выделенный блок с достаточным объемом свободной памяти, поэтому вы уверены, что SQL не будет страницы - быстрее ли управление памятью на 64-битном SQL?
Короткий ответ: если использовать правильноБлокировка страниц в памяти может повысить производительность SQL Server в 64-разрядных системах.
Длинный ответ заставляет нас сделать несколько шагов назад.
Прежде всего, вы должны понимать, что существует разница между подкачкой и подкачкой на диск. В современных операционных системах ВСЯ память распределяется по страницам в пределах ВАШ (Виртуальное адресное пространство). Это неплохо, вот как это работает.
Есть две проблемы с тем, как SQL Server работает с памятью буферного пула, когда страницы блокировки не используются:
Во-первых, это больше дорого выделять память. Когда процесс запускается или запрашивает дополнительную память, ОС по запросу создает для него новые страницы. Итак, обычно, когда SQL Server работает, он будет запрашивать, получать, освобождать страницы, постоянно общаясь с ОС, что дорого.
Во-вторых, NUMA работает не очень хорошо. Правильная поддержка NUMA означает, что приложение может рассчитывать на то, что страница находится в физической памяти, которая находится ближе всего к процессору, на котором работает поток, но когда ОС берет на себя подкачку страниц, SQL Server не может этого гарантировать. Он должен проверять резидентность NUMA для каждого запроса страницы, что дорого также.
Когда вы включаете блокировку страниц в памяти, SQL Server не должен иметь дело ни с одной из этих проблем для буферного пула, поскольку он использует API AWE для управления памятью.
Во-первых, когда он просит памяти, это делает это только один раз, и сразу получает список страниц из ОС. Затем, в будущем, он может распределять эти страницы по мере необходимости, не запрашивая их у ОС.
Во-вторых, поскольку он блокирует страницы из ОС, он знает, что свойства этих страниц не изменятся. Поэтому, если страница является страницей NUMA, она поместит ее в пул буферов NUMA, и вам не придется беспокоиться о том, что она находится в NUMA при следующей проверке.
Вы заметите эти улучшения как по мере наращивания базы данных (когда произойдет выделение памяти), так и со временем (когда обычно SQL Server будет иметь дело с ОС для выделения / освобождения страниц).
Если вы хотите получить более подробную информацию, есть отличная техническая статья по этому поводу Слава Окс, когда он был в команде SQL Server. У него также есть Вопросы и ответы опубликовать по теме еще одну отличную статью о как работает NUMA в SQL Server.
Насколько я понимаю настройку заблокированных страниц в памяти из моих разговоров с командой разработчиков SQL Server, единственное, что контролирует этот параметр, - это то, что он позволяет SQL Server игнорировать инструкции ОС, чтобы выгружать все данные на диск и очищать память.
В нормальных условиях отключение заблокированных страниц в памяти не принесет вам ничего хорошего или плохого. Это странный случай, когда наличие заблокированных страниц в памяти поможет вам. Примером может служить ошибка в Windows 2003 RTM, когда при запуске SQL Server вы инициировали сеанс удаленного рабочего стола на сервере, ОС сообщала SQL Server о необходимости сбросить всю память на диск без причины. Если бы у вас был включен параметр «Блокировать страницы в памяти», ваш SQL-сервер проигнорировал бы эту инструкцию, если бы этот параметр не был установлен, ваш SQL-сервер сбросил бы буферный кеш на диск в соответствии с инструкциями.
Есть и другие случаи, когда драйверы RAID и диски HBA содержат ошибки, которые вызывают ту же проблему.
Я говорю об этом Вот и Боб Уорд из команды SQL Server говорит об этом Вот.
По моему опыту, любой прирост производительности компенсируется проблемой, которая однажды вас укусит. Я бы сказал, что если у вас относительно медленный рост данных и мало изменений кода базы данных, вы можете эффективно реализовать это и получить небольшую выгоду. Однако, если ваша база данных интенсивно используется и иногда страницы sql отсутствуют, я бы сказал, не включайте ее. Как спросить у команды производительности в статье говорится:
«После того, как вы настроили свой сервер на основе результатов анализа монитора производительности, это решение действительно остается за вами».
Я еще не нашел оправдания, чтобы включить его ни в одной из моих систем.