Этот вопрос в основном является последующим вопросом к этому вопросу:
странная проблема с производительностью 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 (спасибо за вставку этого в):
Не уходите от устранения неполадок потоков процессора - это не связано. Сосредоточьтесь на своем основном типе ожидания и вещах, которые могут вызвать этот тип ожидания.
Чтобы устранить эту проблему далее, запустите sp_WhoIsActive или sp_BlitzFirst (заявление об отказе: я один из авторов этого) - оба из них будут перечислять запросы, которые выполняются в настоящее время. Посмотрите на столбец информации об ожидании, найдите запросы, ожидающие ASYNC_NETWORK_IO, и посмотрите на приложения и серверы, с которых они работают.
Оттуда вы можете попробовать:
Обновите с помощью 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 / ОС управления, чтобы отключить любые параметры энергосбережения, которые могут замедлять работу ядер до более низкой скорости.
источник