Основні проблеми з продуктивністю на нашому виробничому SQL сервері, як я можу це усунути?

Це питання в основному є додатковим запитанням до цього питання:
Дивна проблема продуктивності на SQL Server 2016

Зараз ми стали продуктивними з цією системою. Хоча ще одна база даних додатків була додана до цього SQL-сервера з мого останнього допису.

це системна статистика:

• 128 ГБ оперативної пам’яті (максимальна пам'ять 110 ГБ для SQL Server)
• 4 ядра при 2,6 ГГц
• Підключення до мережі 10 ГБ
• Усі сховища засновані на SSD
• Програмні файли, файли журналів, файли бази даних та tempdb знаходяться на окремих розділах сервера
• Windows Server 2012 R2
• Версія VMware HPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17
• VMware Tools версії 10.0.9, збірка 3917699
• Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 28 жовтня 2016 18:17:30 Авторські права (c) Стандартна версія Microsoft Corporation (64-розрядна) для Windows Server 2012 R2 Standard 6.3 (збірка 9600:) (Гіпервізор)

Зараз у нашій системі є основні проблеми з продуктивністю. Дуже високе використання процесора та кількість потоків:

Зачекайте статистику монітора активності (я знаю, це не дуже надійно)

Результати sp_blitzfirst:

Результати sp_configure:

Розширені налаштування сервера (нещасність лише німецькою мовою)

Налаштування MAXDOP мене змінили.

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

Чи призведе до високого ASYNC_NETWORK_IO велике число потоків для sqlserver процесу? Я б уявив, що це охоплює багато працівників, тому що потоки неможливо закрити. Це так?

Я надамо будь-яку додаткову інформацію, необхідну вам Заздалегідь дякую за вашу підтримку!

Редагувати:

Результат sp_Blitz @OutputType = ‘markdown’, @CheckServerInfo = 1

Пріоритет 1: Резервне копіювання :

• Резервне копіювання на той же диск, де перебувають бази даних - 5 резервних копій, зроблених на диску E: \ за останні два тижні, де також живуть файли баз даних. Це становить серйозний ризик, якщо цей масив вийде з ладу.

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

• Останній хороший показник DBCC CHECKDB старше 2 тижнів

  • babtec_prod - Останній успішний CHECKDB: 2017-08-20 00: 01: 01.513

  • D3PR - Останній успішний CHECKDB: ніколи.

  • DEMO77 - Останній успішний CHECKDB: 2016-02-23 20: 31: 38.590

  • FINP - Останній успішний CHECKDB: 2017-04-23 22: 01: 19.133

  • GridVis_EnMs - Останній успішний CHECKDB: 2017-05-18 22: 10: 48.120

  • майстер - Останній успішний CHECKDB: ніколи.

  • модель

  • msdb

  • PROD77 - Останній успішний CHECKDB: 2016-02-23 21: 33: 24.343

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

• Магазин запитів вимкнено - у цій базі даних не включена нова функція магазину запитів SQL Server 2016.

  • babtec_prod

  • D3PR

  • DEMO77

  • FINP

  • GridVis_EnMs

Пріоритет 50: Події DBCC :

• DBCC DROPCLEANBUFFERS - Користувач schorsch запускав DBCC DROPCLEANBUFFERS 1 раз між 21 вересня 2017 11:57 та 21 вересня 2017 11:57 ранку. Якщо це виробнича скринька, знайте, що ви очищаєте всі дані з пам'яті, коли це відбувається. Який монстр це зробив би?

• DBCC SHRINK% - Користувач schorsch запустив файл зменшується 6 разів між 21 вересня 2017 р. 23:51 та 4 жовтня 2017 р. 9:02. Так, е-е, вони намагаються виправити корупцію чи спричинити корупцію?

• Загальні події - 287 подій DBCC відбулося між 19 вересня 2017 р. 13:40 та 4 жовтня 2017 р. 15:20. Це не включає CHECKDB та інші, як правило, доброякісні події DBCC.

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

• Зростання файлів уповільнене PROD77 - 2 наростання тривали більше 15 секунд. Розгляньте можливість встановлення автоматичного зростання файлів на менший приріст.

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

• Неоптимальна перевірка сторінки babtec_prod - База даних [babtec_prod] має TORN_PAGE_DETECTION для перевірки сторінки. SQL Server може важче розпізнати та відновити після пошкодження пам’яті. Подумайте замість цього використовувати CHECKSUM.

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

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

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

• Активні таблиці без кластерних індексів

  • babtec_prod - База даних [babtec_prod] має купи - таблиці без кластерного індексу - які активно запитуються.

  • D3PR - База даних [D3PR] має купи - таблиці без кластерного індексу - які активно запитуються.

  • DEMO77 - База даних [DEMO77] має купи - таблиці без кластерного індексу - які активно запитуються.

  • FINP - База даних [FINP] має купи - таблиці без кластеризованого індексу - які активно запитуються.

  • GridVis_EnMs - База даних [GridVis_EnMs] має купи - таблиці без кластерного індексу - які активно запитуються.

  • PROD77 - База даних [PROD77] має купи - таблиці без кластерного індексу - які активно запитуються.

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

• Іноземні ключі не довіряють

  • babtec_prod - База даних [babtec_prod] містить сторонні ключі, які, ймовірно, були відключені, дані були змінені, а потім ключ був знову ввімкнено. Простого включення ключа недостатньо для оптимізатора використовувати цей ключ - ми повинні змінити таблицю, використовуючи параметр WITH CHECK CHECK CONSTRAINT.

  • D3PR - У базі даних [D3PR] є сторонні ключі, які, ймовірно, були відключені, дані були змінені, а потім ключ був знову включений. Простого включення ключа недостатньо для оптимізатора використовувати цей ключ - ми повинні змінити таблицю, використовуючи параметр WITH CHECK CHECK CONSTRAINT.

• Неактивні таблиці без кластерних індексів

  • D3PR - База даних [D3PR] має купи - таблиці без кластеризованого індексу - які не були запитані після останнього перезапуску. Це можуть бути акуратно залишені резервні таблиці.

  • GridVis_EnMs - База даних [GridVis_EnMs] має купи - таблиці без кластеризованого індексу - які не були запитані після останнього перезапуску. Це можуть бути акуратно залишені резервні таблиці.

• Тригери на таблицях babtec_prod - База даних [babtec_prod] має 26 тригерів.

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

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

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

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

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

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

• Набір максимального розміру файлу

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

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

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

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

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

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

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

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

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

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

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

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

• Стиснення резервного копіювання за замовчуванням вимкнено - нещодавно відбулося некомпресоване повне резервне копіювання, а на рівні сервера компресія не включається. Стиснення резервного копіювання включено до SQL Server 2008R2 та новіших версій, навіть у Standard Edition. Ми рекомендуємо увімкнути компресію резервного копіювання за замовчуванням, щоб тимчасові резервні копії стискалися.

• Збірка - це Latin1_General_CS_AS FINP - різниці в зібранні між базами даних користувача та tempdb можуть спричинити конфлікти, особливо при порівнянні рядкових значень

• Збірка - SQL_Latin1_General_CP1_CI_AS - різниці в зібранні між базами даних користувача та tempdb можуть викликати конфлікти, особливо при порівнянні рядкових значень

  • DEMO77

  • PROD77

• Налаштований пов'язаний сервер - BWIN2 \ INFOR налаштований як пов'язаний сервер. Перевірте його конфігурацію безпеки під час з'єднання з sa, оскільки будь-який користувач, який запитує її, отримає дозволи адміністратора.

Пріоритет 200: Моніторинг :

• Робота агента без електронних листів

  • Завдання syspolicy_purge_history не було налаштовано для сповіщення оператора, якщо воно не працює.

  • Завдання upd_durchpreis_monatl не було налаштовано для сповіщення оператора, якщо воно не працює.

  • Завдання upd_fertmengen_woche не налаштовано для сповіщення оператора, якщо воно не працює.

  • Завдання upd_liegezeit_monatl не було налаштовано для сповіщення оператора, якщо воно не працює.

  • Завдання upd_vertreter_diff не налаштовано для сповіщення оператора, якщо воно не працює.

  • Завдання UPDATE_CONNECT_IK не налаштовано для сповіщення оператора, якщо воно не працює.

  • Завдання Wartung.Cleanup не налаштовано для сповіщення оператора, якщо воно не працює.

  • Задача Wartung.DBCC Check DB не була налаштована для сповіщення оператора, якщо вона не працює.

  • Завдання Wartung.Index neu erstellen не налаштовано для сповіщення оператора, якщо воно не працює.

  • Завдання Wartung.Statistiken aktualisieren не налаштовано для сповіщення оператора, якщо воно не працює.

  • Завдання Wartung.Transactionlog резервного копіювання не було налаштовано для сповіщення оператора про помилку.

  • Завдання Wartung.Vollbackup SystemDB не налаштовано для сповіщення оператора, якщо воно не працює.

  • Завдання Wartung.Vollbackup UserDB не налаштовано для сповіщення оператора, якщо воно не працює.

• Ніяких сповіщень про пошкодження - попередження про агент SQL Server не існує для помилок 823, 824 та 825. Ці три помилки можуть надати вам сповіщення про ранню несправність обладнання. Увімкнення їх може запобігти вам сильне серце.

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

• Не всі сповіщення налаштовані - не всі сповіщення агента SQL Server налаштовані. Це безкоштовний і простий спосіб отримувати сповіщення про корупцію, збої в роботі або великі несправності ще до того, як системи моніторингу підійдуть.

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

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

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

• мова повного тексту за замовчуванням - ця опція sp_configure була змінена. Його значення за замовчуванням - 1033, воно було встановлено на 1031.

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

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

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

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

• хв. пам'яті сервера (МБ) - ця опція налаштування sp_configure була змінена. Його значення за замовчуванням - 0, і воно встановлено на 10000.

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

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

• Поріг вартості паралелізму - встановіть 5, його значення за замовчуванням. Зміна цього налаштування sp_configure може зменшити очікування CXPACKET.

• Здійснення резервних копій знімків - за останні два тижні відбулося 9 резервних копій знімків, що вказує на те, що IO може замерзнути.

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

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

  • D3PR

  • FINP

• Увімкнено рекурсивні тригери - цей параметр бази даних не є типовим.

  • DEMO77

  • PROD77

• Функція ізоляції знімків увімкнена FINP - Цей параметр бази даних не є типовим.

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

• 1 - ASYNC_NETWORK_IO - 225,9 годин очікування, 143,5 хвилин середнього часу очікування на годину, 0,2% очікування сигналу, 2146022 завдання очікування, 378,9 мс середнього часу очікування.

• 2 - CXPACKET - 43,1 години очікування, 27,4 хвилини середнього часу очікування на годину, 1,5% очікування сигналу, 32608391 завдання очікування, 4,8 мс середнього часу очікування.

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

• SQL Server працює під обліковим записом служби NT

  • Я працюю як NT Service \ MSSQL $ INFOR. Я б хотів, щоб у мене був обліковий запис служби Active Directory.

  • Я працюю як NT Service \ SQLAgent $ INFOR. Я б хотів, щоб у мене був обліковий запис служби Active Directory.

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

• Зміст сліду за замовчуванням - слід за замовчуванням зберігає 760 годин даних між 3 вересня 2017 р. 20:34 та 5 жовтня 2017 р. 12:50. Файли трасування за замовчуванням знаходяться у: C: \ Програмні файли \ Microsoft SQL Server \ MSSQL13.INFOR \ MSSQL \ Log

• Диск C Space - 21308.00MB безкоштовно на диску C

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

• Диск F Space - 60193.00MB безкоштовно на F приводі

• Обладнання - Логічні процесори: 4. Фізична пам'ять: 128 ГБ.

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

• Останній перезапуск сервера - 1 жовтня 2017 р. 14:21

• Ім'я сервера - BWINPDB \ INFOR

• Послуги

  • Сервіс: сервер SQL (INFOR) працює під обліковим записом служби NT Service \ MSSQL $ INFOR. Останній час запуску: 1 жовтня 2017, 14:22. Тип запуску: Автоматичний, зараз працює.

  • Сервіс: агент-сервер SQL (INFOR) працює під обліковим записом служби NT Service \ SQLAgent $ INFOR. Останній час запуску: не показано .. Тип запуску: Автоматичний, на даний момент працює.

• Останній перезапуск SQL Server - 1 жовтня 2017, 14:22

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

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

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

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

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

Редагувати:

Я вже вивчив цей посібник з найкращих практик щодо налаштування сервера sql за допомогою vmware, і більшість із них ми встановили відповідно до цього документу. Незважаючи на те, що гіперперенос не активований і NUMA не активний на хості vmware. Однак для SQL Server встановлено значення NUMA.

Редагувати:

Я видав RECONFIGURE після встановлення гумової камери для паралелізму до 50, також моя настройка MAXDOP не була налаштована.

Я також перевірився з нашим адміністратором vmware, схоже, я був дезінформованим. Наші процесори встановлені на 2,6 ГГц, а не на 4,6 ГГц. Я виправив цю інформацію вище.

Редагувати:

Ми намагалися встановити деяку мережу, пов’язану з цим vmwarekb та керівництвом . Також ми додали ще 4 ядра до VM. Використання процесора залишилось колишнім.

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

Я отримав цю інформацію з результатів статистики очікування sp_Blitz (спасибі за вставку, що в):

1 - ASYNC_NETWORK_IO - 225,9 годин очікування, 143,5 хвилин середнього часу очікування на годину, 0,2% очікування сигналу, 2146022 завдання очікування, 378,9 мс середнього часу очікування.

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

Щоб усунути цю проблему далі, запустіть sp_WhoIsActive або sp_BlitzFirst (відмова від відповідальності: я один з авторів цього) - обидва будуть перелічувати запити, які виконуються в даний час. Подивіться на стовпчик інформації про очікування, знайдіть запити, які очікують на ASYNC_NETWORK_IO, і подивіться програми та сервери, з яких вони працюють.

Звідти ви можете спробувати:

• Перевірка, чи немає цих серверів додатків недостатньо (наприклад, якщо вони розміщені на процесорі чи підключення до диска) та налаштуйте їх
• Співпраця з розробниками додатків, щоб побачити, чи виконують вони обробку по рядках за результатами (як і для кожної рядки, що повертається з SQL Server, додаток вимикається і виконує деяку обробку, перш ніж запитати наступний рядок результатів)
• Робота з розробниками додатків для вибору меншої кількості даних (наприклад, менше рядків або менших стовпців, якщо їм не потрібні всі дані - іноді ви бачите це, коли люди випадково роблять SELECT * і повертають більше даних, ніж потрібно, або вони просять всі рядки, коли їм справді потрібні лише 1000 перших)

Оновлення за допомогою sp_WhoIsActive - у екрані sp_WhoIsActive, який ви опублікували, у вас є пара запитів, які чекають на ASYNC_NETWORK_IO. Для цього зверніться до вищевказаних інструкцій.

У решті запитів подивіться на стовпець "статус" sp_WhoIsActive - більшість з них "сплять". Це означає, що вони взагалі не працюють - вони чекають, коли програми на іншому кінці труби відправлять наступну команду. У них відкриті транзакції (див. Стовпець "open_tran_count"), але нічого не може зробити SQL Server для прискорення сплячої транзакції. Ці запити відкриті вже понад сорок хвилин (перша колонка в sp_WhoIsActive. Вони просто нічого не роблять. Ви повинні змусити цих людей здійснювати свої транзакції та закривати зв’язки. Це не проблема налаштування продуктивності.

Все, що ми бачимо тут, вказує на сценарій, коли ми чекаємо на додаток.

Щоб відповісти на моє власне питання. ASYNC_NETWORK_IO насправді не була справжньою проблемою. Ми вирішили проблему з продуктивністю, дотримуючись цього посібника щодо завантаженості, залежно від затримки

Найкращі практики для налаштування продуктивності навантажень, чутливих до затримок у VSphere VM

Тут я позначив налаштування, застосовані до нашої системи жовтим кольором:

Я думаю, що налаштуваннями, що найбільше впливали, були налаштування numa та встановлення чутливості затримки до високої . Які обох потрібні для чіткості виділення / резервування фізичних ядер CPU та оперативної пам’яті для VM.

Також ми додали більше ядер до VM, а тепер потрібно оновити ліцензію SQL Server із "Стандартної" на "Enterprise".

Схоже, Windows повідомляє про тактову частоту ядер 4,6 ГГц процесорних ядер як 2,6 ГГц ... Я б запустив такий інструмент, як CPU-Z, щоб перевірити, на якій швидкості вони насправді працюють, а потім подивитись на зміну параметрів живлення в і Windows, і BIOS / OS для відключення будь-яких налаштувань енергозбереження, які можуть знижувати ядра на меншу швидкість.