Споживання "загальної пам'яті сервера" SQL Server місяцями застоюється з 64 ГБ + більше

У мене виникла дивна проблема, коли 64-розрядна версія SQL Server 2016 Standard Edition, схоже, обмежилася приблизно на половині всієї пам'яті, виділеної на неї (64 ГБ 128 ГБ).

Вихід @@VERSION:

Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119) - 13.0.4466.4 (X64) 22 грудня 2017 11:25:00 Авторські права (c) Microsoft Corporation Standard Edition (64-розрядна версія) на Windows Server 2012 R2 Datacenter 6.3 ( Збірка 9600:) (Гіпервізор)

Вихід sys.dm_os_process_memory:

Коли я запитую sys.dm_os_performance_counters, я бачу, що це Target Server Memory (KB)є 131072000і Total Server Memory (KB)знаходиться трохи нижче половини цього 65308016. У більшості сценаріїв я б розумів, що це нормальна поведінка, оскільки SQL Server ще не визначив, що йому потрібно виділити будь-яку подальшу пам'ять для себе.

Однак він "застряг" на ~ 64 ГБ вже більше 2 місяців. За цей проміжок часу ми виконали значну кількість операцій, що займають пам'ять, на деяких базах даних і додали до екземпляра ще близько 40 баз даних. Ми сидимо в загальній кількості 292 баз даних, кожна з попередньо виділеними файлами даних на 4 ГБ зі швидкістю саморостання 256 МБ та файлами журналів 2 ГБ зі швидкістю автоматичного зростання 128 МБ. Я виконую повне резервне копіювання один раз щоночі о 12:00, і починаю резервне копіювання журналу транзакцій з понеділка по п’ятницю, починаючи з 6:00 до 20:00 з інтервалом кожні 15 хвилин. Ці бази даних відносно низькі за загальною пропускною спроможністю, але я скептично налаштований, що щось не так, зважаючи на те, що SQL Server не підкрався доTarget Server Memory природно через нові доповнення до бази даних, звичайні виконання запитів, а також запущені пам’яті трубопроводи ETL.

Сам екземпляр SQL Server сидить на віртуалізованому (VMware) сервері Windows Server 2012R2 з 12 процесором, 144 Гб пам’яті (128 ГБ для SQL сервера, 16 ГБ зарезервовано для Windows) та 4 загальних віртуальних дисків, які сидять на версії vSAN з 15 К накопичувачами SAS. . Windows сидить природно на диску 64 Гб: диск із файлом сторінки 32 Гб. Файли даних розміщуються на 2TB D: диску, файли журналів розміщуються поверх 2TB L: диска, а tempdb знаходиться на 256 Гб T: диск з файлами 8x16GB без автоматичного зростання.

Я переконався, що на сервері немає інших екземплярів SQL Server MSSQLSERVER.

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

Я використовую RedGate SQL Monitor для аналізу, а нижче - історія останніх 18 днів Total Server Memory. Як бачимо, використання пам'яті залишилося повністю застійним, окрім єдиного підходу в розмірі ~ 300 Мб на початку квітня.

Що може бути причиною цього? Що я можу детальніше розглянути, щоб визначити, чому SQL Server не хоче використовувати додаткові 64 ГБ + пам'яті, виділеної для нього?

Вихід працює sp_Blitz:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Пріоритет 50: Продуктивність :

• Планувальники процесора в режимі офлайн - Деякі ядра CPU недоступні для SQL Server через маскування афінності або проблеми з ліцензуванням.

• Вузли пам’яті в режимі офлайн - Через проблеми маскування спорідненості або ліцензування частина пам'яті може бути недоступною.

Пріоритет 50: Надійність :

• Remote DAC Disabled - Віддалений доступ до виділеного адміністратора (DAC) не увімкнено. ЦАП може значно полегшити віддалене усунення несправностей, коли SQL Server не відповідає.

Пріоритет 100: Продуктивність :

• Багато планів на один запит - 300 планів представлені для одного запиту в кеші планів - це означає, що у нас, ймовірно, є проблеми параметризації.

• Увімкнено активатори сервера

  • Тригер сервера [RG_SQLLighthouse_DDLTrigger] увімкнено. Переконайтеся, що ви розумієте, що робить цей спусковий механізм - чим менше роботи він робить, тим краще.

  • Тригер сервера [SSMSRemoteBlock] увімкнено. Переконайтеся, що ви розумієте, що робить цей спусковий механізм - чим менше роботи він робить, тим краще.

Пріоритет 150: Продуктивність :

• Запити, що змушують підказувати приєднання - з часу перезапуску було записано 1480 випадків підказки про приєднання. Це означає, що запити обробляють оптимізатор SQL Server навколо, і якщо вони не знають, що роблять, це може принести більше шкоди, ніж користі. Це також може пояснити, чому зусилля з налаштування DBA не працюють.

• Запити, що примушують підказки замовлення - з моменту перезавантаження було зафіксовано 2153 випадки натяку на замовлення. Це означає, що запити обробляють оптимізатор SQL Server навколо, і якщо вони не знають, що роблять, це може принести більше шкоди, ніж користі. Це також може пояснити, чому зусилля з налаштування DBA не працюють.

Пріоритет 170: Конфігурація файлу :

• Системна база даних на C Drive

  • master - Основна база даних має файл на диску C. Якщо розмістити системні бази даних на дисководі C, це може призвести до збою сервера, коли у нього не вистачає місця.

  • модель - База даних моделей має файл на диску C. Якщо розмістити системні бази даних на дисководі C, це може призвести до збою сервера, коли у нього не вистачає місця.

  • msdb - База даних msdb має файл на диску C. Якщо розмістити системні бази даних на дисководі C, це може призвести до збою сервера, коли у нього не вистачає місця.

Пріоритет 200: Інформація :

• Агентські завдання, що починаються одночасно - кілька завдань агента SQL Server налаштовані на запуск одночасно. Детальні списки розкладу див. Запит у URL-адресі.

• Таблиці в майстер бази даних Master - Таблиця CommandLog в базовій базі даних була створена кінцевими користувачами 30 липня 2017 року 17:22. Таблиці в основній базі даних не можуть бути відновлені у разі катастрофи.

• TraceFlag On

  • Прапор трасування 1118 включений у всьому світі.

  • Прапор сліду 1222 включений у всьому світі.

  • Прапор трасування 2371 включений у всьому світі.

Пріоритет 200: Налаштування сервера, що не використовується за замовчуванням :

• XP агента - Цей параметр sp_configure змінено. Його значення за замовчуванням - 0, і воно встановлено на 1.

• резервна копія контрольної суми за замовчуванням - Цей параметр sp_configure змінено. Його значення за замовчуванням - 0, і воно встановлено на 1.

• за замовчуванням стиснення резервного копіювання - цей параметр sp_configure змінено. Його значення за замовчуванням - 0, і воно встановлено на 1.

• Поріг вартості паралелізму - Цей параметр sp_configure змінено. Його значення за замовчуванням - 5 і встановлено 48.

• максимальна ступінь паралелізму - Цей параметр sp_configure змінено. Його значення за замовчуванням дорівнює 0 і воно встановлено на 12.

• Максимальна пам'ять сервера (МБ) - ця опція налаштування sp_configure була змінена. Його значення за замовчуванням - 2147483647, воно встановлено на 128000.

• оптимізувати для спеціальних навантажень - цю опцію sp_configure було змінено. Його значення за замовчуванням - 0, і воно встановлено на 1.

• Показати розширені параметри - Цей параметр sp_configure змінено. Його значення за замовчуванням - 0, і воно встановлено на 1.

• xp_cmdshell - Цей параметр sp_configure змінено. Його значення за замовчуванням - 0, і воно встановлено на 1.

Пріоритет 200: Надійність :

• Розширені збережені процедури в Master

• master - Розширена збережена процедура [sqbdata] знаходиться в головній базі даних. CLR може бути використаний, і головна база даних тепер повинна бути частиною вашого плану резервного копіювання / відновлення.

  • master - Розширена збережена процедура [sqbdir] знаходиться в головній базі даних. CLR може бути використаний, і головна база даних тепер повинна бути частиною вашого плану резервного копіювання / відновлення.

  • master - Розширена збережена процедура [sqbmemory] знаходиться в головній базі даних. CLR може бути використаний, і головна база даних тепер повинна бути частиною вашого плану резервного копіювання / відновлення.

  • master - Розширена збережена процедура [sqbstatus] знаходиться в головній базі даних. CLR може бути використаний, і головна база даних тепер повинна бути частиною вашого плану резервного копіювання / відновлення.

  • master - [sqbtest] розширена збережена процедура знаходиться в головній базі даних. CLR може бути використаний, і головна база даних тепер повинна бути частиною вашого плану резервного копіювання / відновлення.

  • master - [sqbtestcancel] розширена збережена процедура знаходиться в головній базі даних. CLR може бути використаний, і головна база даних тепер повинна бути частиною вашого плану резервного копіювання / відновлення.

  • master - Розширена збережена процедура [sqbteststatus] знаходиться в головній базі даних. CLR може бути використаний, і головна база даних тепер повинна бути частиною вашого плану резервного копіювання / відновлення.

  • master - Розширена збережена процедура [sqbutility] знаходиться в головній базі даних. CLR може бути використаний, і головна база даних тепер повинна бути частиною вашого плану резервного копіювання / відновлення.

  • master - Розширена збережена процедура [sqlbackup] знаходиться в головній базі даних. CLR може бути використаний, і головна база даних тепер повинна бути частиною вашого плану резервного копіювання / відновлення.

Пріоритет 210: Налаштування бази даних за замовчуванням :

• Прочитати ввімкнене виділення знімків знімків - це налаштування бази даних не є типовим.

  • RedGate

  • RedGateMonitor

• Ізоляція знімків включена - цей параметр бази даних не є типовим.

  • RedGate

  • RedGateMonitor

Пріоритет 240: Статистика очікування :

• 1 - SOS_SCHEDULER_YIELD - 1770,8 годин очікування, 115,9 хвилин середній час очікування на годину, 100,0% очікування сигналу, 1419212079 завдання очікування, 4,5 мс середній час очікування.

Пріоритет 250: Інформація :

• SQL Server працює під обліковим записом NT Service - я працюю як NT Service \ MSSQLSERVER. Я б хотів, щоб у мене був обліковий запис служби Active Directory.

Пріоритет 250: Інформація про сервер :

• Зміст трас за замовчуванням - слід за замовчуванням містить 36 годин даних між 14 квітня 2018 року 23:21 та 16 квітня 2018 11:13 ранку. Файли трасування за замовчуванням знаходяться у: C: \ Програмні файли \ Microsoft SQL Server \ MSSQL13.MSSQLSERVER \ MSSQL \ Log

• Привід C Space - 196816.00MB безкоштовно на диску C

• Диск D Space - 894823.00MB безкоштовно на електронному диску

• Привід L Space - 1361367.00MB безкоштовно на F приводі

• Диск T Space - 114441.00MB безкоштовно на диску G

• Апаратне забезпечення - Логічні процесори: 12. Фізична пам'ять: 144 Гб.

• Обладнання - NUMA Config

  • Вузол: 0 Стан: ONLINE Онлайн-планувальники: 4 Офлайн-планувальники: 2 Група процесорів: 0 Вузол пам’яті: 0 Запам'ятована VAS пам’яті ГБ: 186

  • Вузол: 1 Стан: OFFLINE Онлайн-планувальники: 0 Офлайн-планувальники: 6 Група процесорів: 0 Вузол пам’яті: 0 Бронювання пам’яті VAS ГБ: 186

• Миттєва ініціалізація файлів увімкнена - обліковий запис сервісу має дозвіл Виконати завдання з обслуговування обсягу.

• План живлення - Ваш сервер має процесор 2,60 ГГц і перебуває в режимі збалансованого живлення - Ага ... ви хочете, щоб ваші процесори працювали на повній швидкості, правда?

• Останній перезапуск сервера - 9 березня 2018 7:27 ранку

• Ім'я сервера - [відредаговано]

• Послуги

  • Сервіс: сервер SQL (MSSQLSERVER) працює під обліковим записом служби NT Service \ MSSQLSERVER. Останній час запуску: 9 березня 2018 7:27. Тип запуску: Автоматичний, зараз працює.

  • Сервіс: Агент SQL Server (MSSQLSERVER) працює в обліковому записі служби LocalSystem. Останній час запуску: не показано .. Тип запуску: Автоматичний, на даний момент працює.

• Останній перезапуск SQL Server - 9 березня 2018 6:27

• Сервіс SQL Server - Версія: 13.0.4466.4. Рівень виправлення: SP1. Сукупне оновлення: CU7. Видання: Стандартне видання (64-розрядне). Групи доступності увімкнено: 0. Статус менеджера груп доступності: 2

• Віртуальний сервер - Тип: (HYPERVISOR)

• Версія Windows - Ви використовуєте досить сучасну версію Windows: Server 2012R2 епохи, версія 6.3

Пріоритет 254: Порядок роботи :

• Журнал капітана: зоряно щось і щось ...

Надіюсь, ви налаштували віртуальні процесори таким чином, що деякі вузли процесора та / або вузли пам'яті перебувають у режимі офлайн.

Завантажте sp_Blitz (відмова від відповідальності: я один з авторів цього безкоштовного сценарію з відкритим кодом) та запустіть його:

sp_Blitz @CheckServerInfo = 1;

Шукайте попередження щодо відключення процесора та / або вузлів пам'яті в автономному режимі. SQL Server Standard Edition бачить лише перші 4 сокети CPU, і ви, можливо, налаштували VM як щось на зразок 6 двоядерних процесорів. Це врешті-решт вирішить проблему, аналогічну тому, як 20-ядерний ліміт Enterprise Edition обмежує об'єм пам'яті, який ви можете бачити .

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

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Оновлення 2018/04/16 - підтверджено. Ви додали висновок sp_Blitz (спасибі за це!), І це дійсно показує, що у вас немає вузлів процесора та пам'яті в автономному режимі. Хто побудував VM, він налаштував його як 12 одноядерних процесорів, тому SQL Server Standard Edition бачить лише перші 4 сокети (ядра) та пам'ять, що додається до них.

Щоб виправити це, вимкніть VM, налаштуйте його як 2-роз'ємний, 6-ядерний VM, і тоді стандартне видання SQL Server побачить усі ядра та пам'ять. Це також зменшить ваші очікування SOS_SCHEDULER_YIELD - зараз ваш SQL Server забиває перші 4 ядра, але це все. Після цього виправлення він зможе працювати на всіх 12 ядрах.

Як доповнення до плану дій Брента Озара , я хотів поділитися результатами. Як зазначав Brent, у VMware ми неправильно налаштували Віртуальну машину з 12 одноядерними процесорами. Це призвело до того, що решта 8 ядер була недоступною для SQL Server, і, як наслідок, призвело до проблеми з пам'яттю, описаної в моєму первісному питанні. Ми вчора ввечері розмістили наші послуги в режимі обслуговування, щоб відповідним чином налаштувати VM. Ми не тільки спостерігаємо, як пам'ять повзає нормально, але, як і Brent також натякнув, кількість очікувань знизилася в експоненціальному масштабі, і наша загальна продуктивність SQL Server зросла. Конфігурації vNUMA тепер щасливі маленькі компоненти, які прорізуються через наше навантаження.

Для тих, хто може використовувати VMware vSphere 6.5, короткі кроки для завершення пункту дій, описаного Brent, наступні.

1. Увійдіть до веб-клієнта vSphere для кластера VMware та перейдіть до віртуальної машини, на якій розміщено SQL Server. Ваш VM повинен бути в автономному режимі, щоб налаштувати конфігурацію процесора та пам'яті.

2. На первинній панелі перейдіть до Configure > VM hardware, натисніть Editкнопку у верхньому правому куті. Ви відкриєте це контекстне меню Edit Settings. Для довідки, на наведеному нижче зображенні є неправильна конфігурація. Зауважте, що я Cores per Socketвстановив 1. Зважаючи на обмеження стандартної версії SQL Server, це погана конфігурація.

   

3. Виправлення настільки ж просто, як і коригування Cores per Socketзначення. У нашому випадку ми встановимо 6так, щоб у нас є 2 Sockets. Це дозволяє SQL Server використовувати всі 12 процесорів.

   

Важлива примітка: не встановлюйте значення, де або, Number of Coresабо Socketsбуло б непарне число. NUMA любить рівновагу, і, як правило, потрібно ділити на 2. Наприклад, конфігурація від 4 ядер до 3 розеток буде незбалансована. Насправді, якби ви працювали sp_Blitzз таким типом конфігурації, вона б кинула попередження про це.

Розділ 3.3 архітектури Microsoft SQL Server на VMware vSphere (попередження PDF) це детально окреслює. Практики, викладені у посібнику, застосовні до більшості всіх локальних віртуалізації SQL Server.

Ось ще кілька ресурсів, які я зібрав у своїх дослідженнях після посади Брента:

• Віртуалізація великих баз даних - планування ємності процесора VMware

• Віртуальна машина vCPU і vNUMA Правозахист - правила великого пальця

• Роз'єднання ядер на сокет від віртуальної топології NUMA в vSphere 6.5

Я закінчу захоплення RedGate SQL Monitor за останні 24 години. Основна зауваження - це використання процесора та кількість очікувань - під час наших пікових годин учора ми відчували велике використання процесора та очікування. Після цього простого виправлення ми в десятки разів покращили свою ефективність. Навіть наш дисковий введення / вивід значно зменшився. Це, здавалося б, легко не помітити налаштування, яке може покращити віртуальну продуктивність на порядок. Принаймні, це було не помічено нашими інженерами і повний д'ох момент.

Також, згідно з MSDN , стандарт SQL Server обмежений 64 ГБ оперативної пам’яті. Ми це "вирішили", розділивши базу даних на кілька примірників, але ситуація може цього не допустити.

Hmm 2016, здається, має 128 Гб як обмеження, але розбиття на екземпляр може бути варіантом.