Основные проблемы с производительностью на нашем производственном SQL Server, как мне решить эту проблему?

Этот вопрос в основном является последующим вопросом к этому вопросу:
странная проблема с производительностью SQL Server 2016

Теперь мы стали продуктивно работать с этой системой. Хотя со времени моего последнего поста к этому SQL Server была добавлена ​​другая база данных приложений.

это статистика системы:

• 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 Standard Edition (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

  • master - база данных 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 Backup не настроено на уведомление оператора в случае сбоя.

  • Задание Wartung.Vollbackup SystemDB не было настроено для уведомления оператора в случае сбоя.

  • Задание Wartung.Vollbackup UserDB не было настроено для уведомления оператора в случае сбоя.

• Нет предупреждений о повреждении - оповещения агента SQL Server не существуют для ошибок 823, 824 и 825. Эти три ошибки могут дать вам уведомление о раннем сбое оборудования. Включение их может предотвратить вас от горя.

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

• Настроены не все оповещения - настроены не все оповещения агента SQL Server. Это бесплатный и простой способ получать уведомления о повреждениях, сбоях в работе или серьезных сбоях даже до того, как системы мониторинга обнаружат это.

Приоритет 200: Конфигурация сервера не по умолчанию :

• Агент XP - эта опция sp_configure была изменена. Его значение по умолчанию 0, и оно было установлено в 1.

• Database Mail XPs - эта опция 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: Конфигурация базы данных не по умолчанию :

• Read Committed Snapshot Isolation Enabled - этот параметр базы данных не используется по умолчанию.

  • 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: \ Program Files \ Microsoft SQL Server \ MSSQL13.INFOR \ MSSQL \ Log

• Диск C Space - 21308,00MB бесплатно на диске C

• Диск D Space - 280008,00MB бесплатно на диске D
• Drive E Space - 281618.00MB бесплатно на диске E

• Drive F Space - 60193.00MB бесплатно на F диске

• Аппаратное обеспечение - логические процессоры: 4. Физическая память: 128 ГБ.

• Оборудование - NUMA Config - Узел: 0 Состояние: ONLINE Онлайн-планировщики: 4 Автономные планировщики: 0 Группа процессоров: 0 Узел памяти: 0 Память VAS Зарезервировано ГБ: 281

• Последний перезапуск сервера - 1 октября 2017 г. 14:21

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

• Сервисы

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

  • Служба: SQL Server-Agent (INFOR) работает под учетной записью службы NT Service \ SQLAgent $ INFOR. Время последнего запуска: не показано. Тип запуска: автоматический, в данный момент работает.

• Последний перезапуск SQL Server - 1 октября 2017 г. 14:22

• Служба SQL Server - версия: 13.0.4001.0. Уровень патча: SP1. Издание: Standard Edition (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 ядра к виртуальной машине. Загрузка процессора осталась прежней.

Как уже говорилось в прошлый раз, когда вы задавали этот вопрос , ваше главное ожидание - 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. Для тех, обратитесь к вышеуказанным инструкциям.

В оставшейся части запросов посмотрите на столбец «status» sp_WhoIsActive - большинство из них «спят». Это означает, что они вообще не работают - они ждут, пока приложения на другом конце канала отправят свою следующую команду. У них есть открытые транзакции (см. Столбец «open_tran_count»), но SQL Server ничего не может сделать для ускорения спящей транзакции. Эти запросы были открыты более сорока минут (первый столбец в sp_WhoIsActive. Они просто больше ничего не делают. Вам нужно заставить этих людей зафиксировать свои транзакции и закрыть их соединения. Это не проблема настройки производительности.

Все, что мы видим здесь, указывает на сценарий, в котором мы ждем приложение.

Чтобы ответить на мой собственный вопрос. ASYNC_NETWORK_IO на самом деле не было настоящей проблемой. Мы исправили нашу проблему производительности, следуя этому руководству для рабочих нагрузок, чувствительных к задержке:

Рекомендации по настройке производительности чувствительных к задержкам рабочих нагрузок в виртуальных машинах vSphere

Я пометил настройки, которые мы применили к нашей системе, желтым цветом:

Я думаю, что настройками, которые оказали наибольшее влияние, были конфигурация numa и высокая чувствительность к задержке . И то, и другое требуется для явного выделения / резервирования физических ядер ЦП и ОЗУ для ВМ.

Мы также добавили больше ядер к виртуальной машине, и теперь нам нужно обновить лицензию SQL Server со стандартной на корпоративную.

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