Как повысить производительность первичных запросов в MS SQL Server?

У меня есть веб-сайт ASP.NET, который выполняет свое независимое кэширование данных, и данные не меняются в течение длительных периодов времени, поэтому нет необходимости запрашивать SQL Server второй раз с тем же запросом. Мне нужно улучшить производительность запросов с первого раза (девственных), которые идут к этому SQL Server. Некоторые запросы обрабатывают так много данных, что могут вызвать использование SQL Server tempdb. Я не использую переменные временных таблиц или временные таблицы, поэтому SQL Server решает использовать tempdbсам, когда это необходимо.

Мой размер базы данных составляет 16 ГБ, на моем сервере доступно 32 ГБ физической памяти.

Я понимаю, что стратегия кэширования MS SQL Server пытается сохранить данные в оперативной памяти, чтобы ускорить выполнение аналогичных запросов, если им необходимо снова загрузить те же данные. В дополнение к этому он будет пытаться использовать доступную оперативную память вместо базы данных tempdb для ускорения работы без доступа к диску.

Я предполагаю, что когда приходит запрос, который должен что-то хранить в базе данных tempdb, SQL Server и не хватает ОЗУ, у SQL Server есть 2 варианта:

1) выгрузить некоторые кэшированные данные и использовать сэкономленную оперативную память вместо базы данных tempdb, чтобы избежать записи на диск

2) сохранить кэшированные данные для будущих запросов и начать использовать базу данных tempdb, что приводит к записи на медленный диск.

Я не знаю, какой выбор будет делать SQL Server в этой ситуации, но мне бы хотелось, чтобы он сделал выбор № 1, потому что меня волнует только выполнение первичных (целочисленных) запросов, потому что я никогда больше не отправляю тот же запрос на SQL Server. (хотя я могу отправить аналогичный запрос).

Какова стратегия кэширования SQL Server для этого сценария?

Как это уравновешивает использование оперативной памяти между отказом от базы данных tempdb для первичных запросов и скоростью запросов второго раза?

Можно ли настроить SQL Server таким образом, чтобы он сделал выбор № 1? Если да, то как?

Как еще можно повысить производительность всех первичных SQL-запросов?

Поскольку я не знаю стратегии кэширования SQL Server, я хочу разместить базу данных на RAM-диске. Это обеспечит высокую скорость загрузки некэшированных данных, даже если SQL Server всегда выбирает № 1. Риск этого заключается в том, что SQL Server может начать использовать больше базы данных tempdb с меньшим объемом доступной оперативной памяти (осталось только 16 ГБ после того, как я использую 16 ГБ для ОЗУ диска), если он продолжит делать выбор № 2, что замедлит выполнение тех девственных запросов, которые вызывают разливы tempdb.

Меня интересует решение для SQL 2008 R2, но я думаю, что оно, вероятно, то же самое для SQL 2008, SQL 2005 и может быть SQL 2000.

Разъяснения:

На этом ящике не работают другие приложения, он предназначен для SQL Server . Сайт работает на отдельной коробке.

Это 64-разрядная версия SQL Server 2008 R2 Standard Edition в 64-разрядной версии Windows Server 2008 R2 Enterprise.

Я запускаю только запросы только для чтения, а база данных настроена только для чтения .

Давайте предположим, что уже есть хорошие показатели . Этот вопрос о том, как SQL Server делает выбор № 1 против выбора № 2, как он это делает, если есть способ управлять им и если RAM Disk помогает ему сделать правильный выбор для первичных запросов.

Ваш вопрос можно перефразировать как «Как работает запрос памяти?». Хорошее прочтение на эту тему - Понимание предоставления памяти SQL-сервером . Перед запуском запроса в исполнение может потребоваться предоставление памяти для сортировки и хэширования и других операций, требующих памяти. Это предоставление памяти является оценочным . На основании текущего состояния системы (количество запущенных и ожидающих запросов, доступной памяти и т. Д.) Система предоставляет запросу разрешение на использование памяти до требуемого количества. Как только память предоставлена, запрос начинает выполнение (возможно, ему придется подождать в страшной очереди «семафор ресурса», прежде чем он получит грант). При выполнении этого предоставление памяти гарантированопо системе. Этот объем памяти может использоваться совместно со страницами данных (поскольку они всегда могут быть записаны на диск), но никогда не может использоваться с другим использованием памяти (т. Е. Он не может быть объектом 'украсть'). Поэтому, когда запрос начинает запрашивать выделенную память из своего гранта, механизм развернет то, что вы называете «стратегией № 1»: страницы данных могут быть удалены (сброшены, если загрязнены), чтобы дать запросу память, которая была обещана. Теперь, если оценка верна и грант составляет 100% запрошенной памяти, запрос не должен «пролить». Но если оценка была неверной (сводится к оценкам количества элементов, следовательно, подлежит устаревшей статистике) или если запрос не получил весь запрашиваемый грант, запрос будет «разлит». Это когда tempdb входит в картину и производительность, как правило, танки.

Единственная ручка, которой вы располагаете, которая контролирует что-то в этом процессе, - это регулятор ресурсов . Поскольку RG может использоваться для указания параметра MIN для пула, его можно использовать для резервирования памяти для определенной рабочей нагрузки, чтобы он фактически получал запрашиваемое разрешение на использование памяти. Конечно, после того, как вы провели надлежащее расследование, которое показывает, что сокращение количества предоставленных памяти является причиной, и, конечно, после того, как было оценено влияние на другие рабочие нагрузки. И проверено, конечно.

Теперь вернемся к исходному вопросу. Если ваше расследование правильное (очень большое, если), я хотел бы указать на две проблемы:

• вы выполняете производственные запросы, которые требуют предоставления памяти для веб-сайта . Это большой нет-нет. Предоставление памяти указывает на аналитические запросы, которым нет места в обслуживании HTTP-запросов.
• Ваши запросы, вероятно, не являются событием, получающим запрошенную память. Опять же, даже больше нет-нет для критической рабочей нагрузки, связанной с задержкой, как веб-сайты.

Так что это говорит мне о том, что у вас есть фундаментальная проблема дизайна и архитектуры. Веб-сайты управляются задержками и должны создавать рабочую нагрузку, аналогичную OLTP, без предоставления памяти и без нагрузки на память при запросах. Не говоря уже о разливах. Аналитические запросы должны выполняться в автономных заданиях и сохранять предварительно обработанные результаты для быстрой доступности, когда их запрашивают HTTP-запросы.

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

Вам также необходимо убедиться, что на этом же компьютере запущены другие приложения. Несмотря на то, что на устройстве установлено 32 ГБ ОЗУ, вы должны установить максимальный объем памяти на сервере базы данных, чтобы установить искусственное ограничение. Если на одном сервере запущены приложения, то SQL и другие приложения могут конкурировать за ресурсы, и имейте в виду, что SQL очень требователен к памяти.

SQL Server будет использовать базу данных tempdb для внутренней сортировки или хеш-соединений / агрегатов или операторов буферизации и т. Д., И вы не можете контролировать это поведение. Что вы можете сделать, это ограничить объем данных, возвращаемых обратно.

Вы проверили статистику ожидания на этом поле? Каждый раз, когда SQL Server ожидает ресурс, SQL Server будет отслеживать ресурс ожидания, и просмотр этой информации помогает.

Посмотрите на диагностические запросы Гленна Берри, и это станет хорошим началом для вас.

Также посмотрите на PARAMETERIZATION FORCED, как упомянуто в http://weblogs.sqlteam.com/dang/archive/2009/06/27/Forced-Parameterization-A-Turbo-Button.aspx

Этот вопрос в настоящее время читается как решение проблемы. Вы решили, что решением является RAM-диск, и вы хотите, чтобы кто-то подтвердил этот выбор. Извините, не произойдет.

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

Взгляните на Buffer Management, чтобы лучше понять, как SQL Server управляет памятью, а SQL Server Memory Management объяснил некоторые основные инструменты и запросы DMV, чтобы понять, где выделена ваша память.

Как еще можно повысить производительность всех первичных SQL-запросов?

Это большая тема. Разместите запрос и план, и вы получите целевую обратную связь.