Почему возникают типы ожидания async_network

10

На прошлой неделе в нашей базе произошло что-то странное. Внезапно приложение заблокировалось для наших пользователей, которые не смогли сохранить новые объекты и т. Д. После просмотра монитора активности SQL Server (2008 с режимом совместимости 2005) я увидел следующие три записи:

async_network_io типы ожидания

Через некоторое время пользователи получили тайм-аут соединения. Когда я убил процесс 64, они могли нормально сохранить снова.

Проблема в том, что сущности, которые они пытались сохранить во время блока, были вставлены в БД более одного раза (до 3 раз), даже несмотря на наличие кода, который должен предотвращать это (числовой столбец, который должен быть уникальным, но без ограничений). ... проверка происходит в коде).

Мы используем Entity Framework 6.0.

Кто-нибудь из вас знает, почему и когда возникают эти типы ожидания ASYNC_NETWORK_IO и как их избежать?
И что именно они имеют в виду?

sql-server sql-server-2008 entity-framework

— xeraphim
источник

1

Взгляните на эту статью Дуга Лейна: brentozar.com/archive/2015/07/… Это может касаться того, что вы видите с EF.

— Крис Груттемейер

Очень интересная статья! Спасибо, я посмотрю на это :)

— xeraphim

1

Проверьте хранилище статистики ожидания - ASYNC_NETWORK_IO . Используйте сценарий, который предлагает Павел, чтобы увидеть, есть ли другие проблемы.

— Кин Шах

12

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

Пожалуйста, обратитесь к сообщению Томас Ларок

Ожидание ASYNC_NETWORK_IO указывает на то, что происходит один из двух сценариев. Первый сценарий заключается в том, что сеанс (т. Е. SPID) ожидает, пока клиентское приложение обработает набор результатов и отправит обратно SQL Server сигнал о готовности обработать больше данных. Во-вторых, это может быть проблема производительности сети.

или этот пост от Джо Сэка

Как вы, возможно, уже знаете, типы ожидания ASYNC_NETWORK_IO (видимый в SQL 2005) и NETWORKIO (видимый в SQL 2000) связаны либо с вызывающим приложением, которое недостаточно быстро обрабатывает результаты из SQL Server, либо связано с проблемой производительности сети ,

Так как вы используете entity framework этот пост от Brent Ozar, это может быть полезно

Просматривая статистику ожидания для этих запросов, я обнаружил, что ASYNC_NETWORK_IO было много - часто более 1000 миллисекунд. Это тоже не имело никакого смысла! Как может запрос с таким небольшим временем процессора и таким небольшим чтением занимать так много времени? Не то чтобы приложение запрашивало миллионы строк и не могло потреблять результаты достаточно быстро.

— Том V - попробуйте topanswers.xyz
источник

6

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

Чрезмерное ожидание ASYNC_NETWORK_IO может произойти при двух сценариях:

Сеанс должен дождаться, пока клиентское приложение обработает данные, полученные от SQL Server, чтобы отправить SQL Server сигнал о том, что он может принять новые данные для обработки. Это распространенный сценарий, который может отражать плохой дизайн приложения, и является наиболее частой причиной чрезмерных значений типа ожидания ASYNC_NETWORK_IO.

Это включает в себя исследование приложения, которое вызывает чрезмерные значения типа ожидания ASYNC_NETWORK_IO, и часто координацию с разработчиками приложения, которые его создали.
Пропускная способность сети максимально. Засоренный Ethernet вызовет медленную передачу данных назад и вперед из приложения. Это само по себе ухудшит эффективность приложения.

Более подробную информацию можно найти на этой странице

— Монте Чавис
источник

Почему возникают типы ожидания async_network_io?