У нас есть один экземпляр 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.
источник