Діагностика проблем регулятора ресурсів
Непередбачені результати означають ситуації, в яких різні елементи регулятора ресурсів працюють, але результати не збігаються з очікуваними. Наприклад, неправильно працює класифікація сеансів, або виникають проблеми при створенні або видаленні груп робочого навантаження.
Класифікація сеансів
Сеанси класифікуються в групу робочого навантаження за замовчуванням при виконанні наступних умов.
Обумовлена користувачем функція-класифікатор не існує або не включена.
Обумовлена користувачем функція-класифікатор поміщає сеанси в групу робочого навантаження за замовчуванням, що свідчить про помилкову логіці функції.
Усунення основних неполадок
Якщо обумовлена користувачем функція-класифікатор не працює, розмови автоматично поміщаються в групу робочого навантаження за замовчуванням. Після створення настройки користувача функції-класифікатора потрібно перевірити, що вона зареєстрована в регуляторі ресурсів і що конфігурація, що зберігається в пам'яті, оновлена.
Створення, реєстрація і включення настройки користувача функції-класифікатора являє собою трьохетапний процес.
Спочатку потрібно створити функцію.
Щоб визначити, чи відбувається регулювання пропускної здатності ЦП, потрібно перевірити такі параметри системи.
Перевірте загальний рівень завантаження ЦП сервера. Якщо на сервері зараз виконуються інші додатки крім SQL Server, вони можуть заважати виконанню діагностується запиту.
Перевірте розподіл ресурсу ЦП серед пулів ресурсів. Пул ресурсів може піддатися регулювання, якщо в іншого пулу задано високу мінімальне значення завантаження ЦП. Порівняйте показники очікуваної (обчислюється) завантаження ЦП з реальною завантаженням.
Перевірте всі групи робочого навантаження, призначені відповідного пулу ресурсів. Навантаження від інших груп робочого навантаження може вплинути на роботу користувачів того ж пулу ресурсів.
Перевірте розподіл ресурсу ЦП серед різних планувальників. Розглянутий запит міг бути поміщений в планувальник, що містить довго виконуються запити. В цьому випадку може створюватися враження, що виконання запиту піддається регулюванню, але насправді проблема полягає в нерівномірному розподілі навантаження між планировщиками.
Можливо, робоче навантаження блокується іншими сеансами, а не піддається регулюванню під дією налаштувань регулятора ресурсів.
Перевірте число паралельних сеансів, в даний час виконують запити в системі. У міру зростання числа одночасних запитів на виконання SQL Server намагається виділити кожному з них хоча б мінімальну кількість часу ЦП, щоб запобігти браку ресурсів ЦП для даного запиту.
Обсяг виділення пам'яті
В цьому випадку є підозра, що повільне виконання запиту обумовлено поточним розміром виділеної пам'яті.
Регулятор ресурсів забезпечує дотримання ліміту пам'яті для запиту, знижуючи обсяг виділеної пам'яті, щоб великі запити могли укластися в ліміт. Якщо запит отримує менше 100% потрібного обсягу виділеної пам'яті, може виникнути необхідність скидання тимчасових даних і запису їх на диск, що помітно впливає на продуктивність.
Щоб правильно встановити максимальний розмір пам'яті для запиту, потрібно визначити відсоток великих запитів. Оптимальні параметри можна визначити за допомогою наступних дій.
Дізнатися поточний стан виділення обсягів пам'яті за допомогою запиту до таблиці sys.dm_exec_query_memory_grants. Значення стовпця ideal_memory_kb показує оптимальну величину, обчислену на основі оцінки кількості елементів. Значення стовпця requested_memory_kb показує запитувану величину, яка може бути зменшена після досягнення максимально допустимої кількості запитів. Якщо значення requested_memory_kb істотно нижче значення ideal_memory_kb. запит буде змушений часто скидати тимчасові дані (виходячи з припущення, що оцінка кількості елементів вірна).
Запустіть системний монітор і зберіть дані за допомогою лічильника Reduced memory grants / sec. Значення цього лічильника є відносна кількість запитів на виділення пам'яті, яким виділено менше оптимального обсягу через те, що максимальний обсяг виділеної пам'яті вже було досягнуто раніше. Великі запити можуть виконуватися набагато повільніше тих, які отримують оптимальний обсяг пам'яті, тому що їм доводиться скидати дані на диск, щоб укластися в ліміт виділеної пам'яті.
Щоб компенсувати проблему з виділенням пам'яті, можна збільшити максимальний розмір пулу або максимальний обсяг виділення пам'яті.
Регулятор ресурсів може бути не єдиною причиною неполадки. Можливо, на сервері виконуються і інші додатки, а також необхідність пам'яті є складовою частиною проблеми.
При виникненні помилки браку пам'яті найкраще починати діагностику з журналу помилок. Журнал містить повідомлення приблизно такого вигляду:
Можливі повідомлення, занесені в журнал помилок, такі.
FAIL_PAGE_ALLOCATION, а потім кількість сторінок, по відношенню до яких була зроблена спроба розподілу.
FAIL_VIRTUAL_RESERVE, а потім число байтів, по відношенню до яких була зроблена спроба резервування.
FAIL_VIRTUAL_COMMIT, а потім число байтів, по відношенню до яких була зроблена спроба фіксації.
Важливо розуміти, що завдання, яке викликала поява помилки браку пам'яті, і завдання, яке є першопричиною помилки, часто бувають різними. Якщо мова не йде про що вийшов з-під контролю запиті, помилка нестачі пам'яті зазвичай є результатом одночасного виконання декількох завдань. В результаті при вивченні причин звичайної на вигляд помилки FAIL_PAGE_ALLOCATION часто доводиться розглядати роботу системи в більш широкому плані.
Наступним важливим джерелом інформації, яка міститься в журналі помилок, є стан пам'яті. Залежно від конкретної помилки необхідно перевіряти пов'язані з конкретним клеркам пам'яті кількісні значення по односторінковим і багатосторінковим операціями, операціями віртуального резервування або фіксації. Далі в процесі діагностики важливо визначити об'єкти або процеси, які витрачають найбільше пам'яті. Зазвичай найбільше вимогливі до пам'яті наступні об'єкти або процеси.
Параметр MEMORYCLERK_ * означає, що конфігурація сервера або робоче навантаження вимагає певного виділення пам'яті. Компонентів SQL Server відповідають свої клерки пам'яті, і окремі компоненти можуть мати кілька клерків пам'яті. Додаткові відомості див. У розділі sys.dm_os_memory_clerks. Іноді за даними клерків пам'яті можна з'ясувати, яка робоче навантаження викликає проблему. Але найчастіше доводиться досліджувати об'єкти пам'яті, пов'язані з клерками, для з'ясування того, чим викликане споживання великих обсягів пам'яті.
CACHESTORE_ *, USERSTORE_ *, OBJECTSTORE_ * окреслити основні кешей. Якщо кеш споживає велику кількість пам'яті, це може означати наступне.
Пам'ять в кеші виділена, але ще не вставлена у вигляді запису, яку можна видалити з кеша. Це дуже схоже на описану вище ситуацію з об'єктом MEMORYCLERK.
Всі записи кеша використовуються, так що ні одну з них не можна видалити. Це можна з'ясувати, подивившись на лічильники sys.dm_os_memory_cache_counters і порівнявши значення стовпців entries_count і entries_in_use_count.
Параметр MEMORYCLERK_SQLQERESERVATIONS показує, скільки пам'яті зарезервовано виконанням запиту для запуску запитів з сортуванням або з'єднанням. Якщо цей показник високий і при цьому виникає помилка нестачі пам'яті, це зазвичай є ознакою програмної помилки в сервері.
Показник стану пам'яті в журналі помилок також вказує, який саме пул пам'яті вичерпано. Брокери пам'яті для кожного пулу показують розподіл пам'яті між запозиченої (компіляція), кешованої і зарезервованої (виділеної) пам'яттю. Показники для трьох брокерів відповідають попереднім об'єктів пам'яті, пов'язаним з клерками пам'яті. Можна дізнатися, скільки пам'яті виділено даному пулу за допомогою даного клерка або об'єкта пам'яті, отримавши інформацію з повного дампа за допомогою призначеного для користувача сценарію, а динамічне адміністративне уявлення sys.dm_os_memory_cache_entries показує ідентифікатор пулу pool_id, з яким пов'язана кожна запис.
Якщо необхідно звернутися в служби підтримки користувачів, зберіть наступні дані.
Журнал помилок, в якому показана помилка нестачі пам'яті і висновок стану пам'яті на момент помилки.
Висновок наступних інструкцій: