Странная проблема с производительностью SQL Server 2016


14

У нас есть один экземпляр SQL Server 2016 SP1, работающий на виртуальной машине VMware. Он содержит 4 базы данных, каждая для отдельного приложения. Все эти приложения находятся на отдельных виртуальных серверах. Ни один из них еще не используется. Однако люди, тестирующие приложения, сообщают о проблемах с производительностью.

Вот статистика сервера:

  • 128 ГБ ОЗУ (макс. Память 110 ГБ для SQL Server)
  • 4 ядра при 4,6 ГГц
  • 10 Гбит подключение к сети
  • Все хранилище на основе SSD
  • Программные файлы, файлы журнала, файлы базы данных и база данных tempdb находятся на отдельных разделах сервера.
  • ASD

Пользователи выполняют доступ к одному экрану через приложение ERP на основе C ++.

Когда я стресс-тестирую SQL Server с Microsoft ostress использующим много маленьких запросов или большой запрос, я получаю максимальную производительность. Клиент только душит, потому что он не может ответить достаточно быстро.

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

Согласно запросу Пола Рэндала « Скажи мне, где болит », 50% всех событий ожидания ASYNC_NETWORK_IO.

Это может означать проблемы с сетью или проблемы с производительностью сервера приложений или клиента. Ни один из них даже не использует свои ресурсы на максимальной мощности. Большую часть времени процессор составляет около 26% на всех машинах (клиент, сервер приложений, сервер БД).

Задержка сетевого подключения составляет около 1-3 мс. IO сервера db имеет максимальную скорость записи 20 МБ / с при обычном использовании с приложением (среднее значение 7-9 МБ / с). Когда я стресс-тест, я получаю около 5 ГБ / с.

Размер кэша буфера составляет 60 ГБ для БД нашей системы ERP, 20 ГБ для нашего программного обеспечения для финансирования, 1 ГБ для программного обеспечения обеспечения качества, 3 ГБ для системы архивирования документов.

Я дал учетной записи SQL Server право использовать мгновенную инициализацию файлов . Это не увеличило производительность ни в малейшей степени.

Ожидаемая продолжительность жизни страницы составляет около 15k + при нормальном использовании. Падает примерно до 0,05 тыс. В конце тяжелого стресс-тестирования, что и следовало ожидать. Пакет / сек около 2-8k, в зависимости от загруженности.

Я бы сказал, что приложение ERP просто плохо написано, но я не могу, потому что все приложения затронуты. Даже при минимальной нагрузке.

И все же я не могу точно определить, что является причиной этого. Есть ли какие-либо советы, подсказки, приложения, документы о лучших / худших методах или что-то еще, что вы, ребята, имеете в виду по этой проблеме?

Это результаты sp_BlitzFirst:

введите описание изображения здесь

введите описание изображения здесь

Я пробежал 600 секунд. Я запустил его во время высокой нагрузки приложения. 1/3 от времени это ASYNC_NETWORK_IO. Я также проверил сетевое соединение с NTttcp, PsPing, ipferf3и pathping. Ничего необычного Время отклика не более 3 мс, в среднем 0,3 мс. Пропускная способность составляет около 1000 МБ / с.

Мое расследование всегда приводит к ASYNC_NETWORK_IOтому, что я стану номером 1

Мы исследовали результат отключения Large-Receive-Offload функции в VMware. Мы все еще тестируем, но результаты кажутся противоречивыми. Наш первый «тест» показал продолжительность 19 минут (максимальный результат - 13 минут, что достигается только при запуске приложения на виртуальной машине с самим SQL Server). Второй результат - 28 минут, что очень плохо.

Первый результат нашего «теста» составил 19 минут. И это хорошо. Потому что максимальный результат составил 13 минут (что достижимо только тогда, когда приложение тестирует виртуальную машину с самим SQL Server). Это сильно намекает на некоторые проблемы, связанные с сетью. Или проблема с конфигурацией VMware.

Я в настоящее время теряюсь в том, какие методы использовать, чтобы прибить это к узкому месту.

Максимальная производительность с приложением достижима только тогда, когда приложение работает на виртуальной машине с самим SQL Server. Если приложение выполняется на любой другой виртуальной машине или виртуальном рабочем столе, продолжительность нашего теста увеличивается в три раза (с 13 минут до 40 минут и более). Все конечные точки (виртуальная машина SQL Server, виртуальная машина сервера приложений и виртуальный рабочий стол) используют одно и то же физическое оборудование. Мы перенесли все остальные конечные точки на другое оборудование.

РЕДАКТИРОВАТЬ: Кажется, что проблема вернулась. После установки режима энергосбережения с сбалансированной на высокую производительность мы фактически значительно улучшили время отклика. Но сегодня я снова запустил sp_BlitzFirst с 300-секундной выборкой. Это результат:

Это результат

Он показывает больше секунды времени ожидания для ASYNC_NETWORK_IO, чем секунд, которые выполнялись sp_blitzfirst.

Ответы:


18

Если ваше основное ожидание - ASYNC_NETWORK_IOпроблема не в SQL Server. Это почти всегда связано с узким местом приложения. Я имею в виду не узкое место на сервере приложений, а скорее узкое место в приложении.

Узкое место приложения обычно возникает из-за построчной обработки, когда SQL Server отправляет данные:

  • Приложение запрашивает данные у SQL Server
  • SQL Server отправляет данные быстро
  • Приложение говорит SQL Server подождать, пока он обрабатывает каждую строку
  • SQL Server записывает время ожидания, ASYNC_NETWORK_IOпока приложение сообщает об ожидании

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

sp_BlitzFirst выход

LCK_M_SЖдать не высока. На нем только 2 секунды 30-секундного сэмпла, а его среднее значение составляет всего 400 мс. Это очень, очень вряд ли проблема. ASYNC_NETWORK_IOваше лучшее ожидание в этом образце. Все еще проблема приложения. Если вам нужна помощь с LCKматериалом, нам нужно увидеть соответствующие запросы.

Даже ASYNC_NETWORK_IOне так уж плохо в этом образце. Мои глаза становятся большими, когда время ожидания равно или превышает размер выборки. Вот когда я копаюсь.

Весь Ваш вопрос ASYNC_NETWORK_IO. Это не проблема SQL Server. Это проблема либо с приложением (выполняющим построчную обработку, когда SQL Server отправляет данные), либо с сервером приложений (вы уже сказали, что все в порядке), либо с сетью (вы сказали, что с сетью все в порядке). Так что проблема с приложением. Приложение C ++ должно быть исправлено.


6

Чтобы ответить на мой собственный вопрос: основной причиной появления ASYNC_NETWORK_IO на нашем SQL Server в качестве верхнего типа ожидания было то, что вместо него energy savingбыл установлен параметр сервера Windows . После этого мы поговорили с некоторыми администраторами vmware, и все они сказали, что этот параметр снижает производительность . 'balanced''high performance'

Решения для этого:

  • Не устанавливайте контроль энергопотребления при установке Windows Server
  • Установите режим энергосбережения на высокую производительность для всех серверов через групповую политику

Все другие проблемы / статистика, касающиеся ASYNC_NETWORK_IO, связаны с плохим написанием нашего приложения ERP. Спасибо всем, кто помог мне с решением этой проблемы, ваши комментарии, предложения и советы были очень полезны и полезны!


Многие BIOS теперь имеют более детальный контроль энергосбережения, например, управление энергопотреблением сетевых карт. Интересно, возможно ли по-прежнему иметь масштабирование частоты и избежать ожидания ввода-вывода на NIC, просто отключив его энергосберегающие режимы.
ajeh
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.