Як підвищити продуктивність незайманих запитів у MS SQL Server?

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

Мій db - 16Gb, у мене на серверній машині доступна 32Gb фізичної оперативної пам’яті.

Я розумію, що стратегія кешування MS SQL Server намагається зберегти дані в оперативній пам'яті, щоб прискорити виконання аналогічних запитів, якщо вони потребують повторного завантаження тих же даних. На додаток до цього він намагатиметься використовувати доступну оперативну пам’ять замість tempdb для прискорення продуктивності, не викликаючи доступу до диска.

Я припускаю, що коли надходить запит, який потребує збереження чогось у tempdb SQL Server, і недостатньо оперативної пам’яті, SQL Server має два варіанти:

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 Гбіт для RAM диска), якщо він продовжує робити вибір №2, що сповільнить ці незаймані запити, які спричиняють розлив tempdb.

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

Роз'яснення:

У цьому вікні не працює жодна інша програма, вона присвячена SQL Server . Веб-сайт працює в окремому вікні.

Це 64-розрядна версія SQL Server 2008 R2 Standard Edition у Windows Server 2008 R2 Enterprise 64 біт.

Я запускаю лише запити лише для читання, і база даних встановлюється лише для читання .

Припустимо, що вже є хороші показники . Це питання про те, що SQL Server робить вибір №1 проти вибору №2, як це зробити, якщо є спосіб керувати ним і якщо диск RAM допомагає зробити правильний вибір для запитів незайманих.

В основному ваше запитання може бути перефразоване як "Як працює графіка пам'яті запиту?". Добре читати з цього питання - Розуміння грамоти пам'яті SQL-сервера . Перед запуском запиту до виконання він може вимагати надання пам’яті для сортування та хешей та інших операцій з головною пам’яттю. Цей грант пам'яті є оцінкою . Виходячи з поточного стану системи (кількість запитів, що працюють та очікують на розгляд, наявна пам'ять тощо), система надає запиту грант пам'яті до необхідного обсягу. Після надання пам’яті запит запускає виконання (можливо, доведеться почекати в жахливій черзі «ресурсу семафор», перш ніж він отримає грант). При його виконанні гарантія пам’яті гарантованасистемою. Цей об'єм пам’яті можна розділити на сторінках даних (оскільки вони завжди можуть передаватися на диск), але ніколи з іншим використанням пам’яті (тобто, це не може бути предметом «крадіжки»). Отже, коли запит починає просити виділену пам'ять з його дозволу, двигун розгорнуть те, що ви називаєте "стратегія №1": сторінки даних можуть бути вилучені (змиті, якщо брудні), щоб надати запиту пам'ять, яку він обіцяв. Тепер, якщо оцінка була правильною і грант становив 100% запитуваної пам’яті, запит не повинен «розпливатися». Але якщо оцінка була неправильною (зводиться до оцінок кардинальності, тому підлягає несвіжій статистиці) або якщо запит не отримав увесь грант, про який він просив, запит буде "розлитим". Це коли tempdb вводить зображення та продуктивність, як правило, танки.

Єдина у вас в розпорядженні кнопка, яка щось контролює в цьому процесі, - це Управління ресурсами . Так як RG може використовуватися для вказівки MIN настройки для пулу, він може бути використаний для резервної пам'яті для певної робочого навантаження , так що він фактично отримує грант пам'яті запитується. Звичайно, після того, як ви провели належне розслідування, яке показує, що винуватцем зменшеного обсягу пам’яті є винуватець, і, звичайно, після того, як було оцінено вплив на інші навантаження. І перевірено, звичайно.

Тепер повернемося до свого початкового питання. Якщо ваше розслідування є правильним (дуже великим, якщо), я хотів би зазначити дві проблеми:

• Ви працюєте з виробничими запитами, які потребують дозволу на пам'ять веб-сайту . Це великий ні-ні. Грант пам’яті вказує на аналітичні запити, яким немає місця в обслуговуванні HTTP-запитів.
• ваші запити, ймовірно, не є подією отримання граніту пам'яті, який вони запитують. Знову ж таки, ще більше "ні-ні" для критичного навантаження за завантаженням, як це веб-сайти.

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

Те, про що ви не згадували, - це те, які запити запускаються до бази даних, і чи є правильні індекси для прискорення ефективності ваших запитів.

Вам також потрібно переконатися, що в цьому ж полі запущені інші програми. Незважаючи на те, що в коробці є 32 ГБ оперативної пам’яті, ви встановили на сервері баз даних будь-які параметри максимальної пам’яті, щоб поставити будь-який штучний ліміт. Якщо на одному сервері працюють програми, то SQL та інші додатки можуть конкурувати за ресурси та зауважте, що SQL дуже голодний.

SQL Server буде використовувати tempdb для внутрішнього сортування або хеш-з'єднань / агрегатів або операторів котушки тощо, і ви не можете контролювати цю поведінку. Що ви можете зробити - обмежити кількість повернених даних.

Ви перевірили статистику очікування на цьому полі? Кожен раз, коли SQL Server чекає ресурсу, SQL Server відстежує ресурс очікування і, дивлячись, що ця інформація допомагає.

Подивіться на діагностичні запити Глена Беррі, і це буде гарним початком для вас.

Також дивіться на ПАРАМЕТЕРІЗАЦІЮ, ЯКІ ЗНАЧЕННЯ, як згадується в http://weblogs.sqlteam.com/dang/archive/2009/06/27/Forced-Parameterization-A-Turbo-Button.aspx

Наразі це запитання читається як рішення рішення проблеми. Ви вирішили, що диск RAM - це рішення, і вам потрібно, щоб хтось підтвердив цей вибір. Вибачте, не відбудеться.

Якщо ви виміряли та спостерігали розлив tempdb, це майже напевно буде пов’язано з сортуванням або хеш-операцією та недостатнім дозволом на запит пам’яті. Залежно від обсягу даних, що підлягають обробці, це може бути неминучим, але хороші шанси запит та / або індексація можуть бути покращені, щоб уникнути цього.

Погляньте на управління буфером, щоб краще зрозуміти, як SQL Server керує пам’яттю та керуванням пам’яттю SQL Server. Пояснено деякі основні інструменти та запити DMV, щоб зрозуміти, куди розподіляється ваша пам'ять.

Як ще я можу підвищити продуктивність усіх незайманих SQL запитів?

Це велика тема. Опублікуйте запит та план, і ви отримаєте цільовий відгук.