왜 async_network_io 대기 유형이 발생합니까?

지난주에 우리 데이터베이스에 이상한 일이 일어났다. 갑자기 새로운 엔터티 등을 저장할 수 없었던 사용자들을 위해 애플리케이션이 차단되었습니다.

얼마 후 사용자에게 연결 시간이 초과되었습니다. 프로세스 64를 종료하면 정상적으로 다시 저장할 수 있습니다.

문제는 블록 동안 저장하려고 한 엔티티가이를 방지 해야하는 코드 (유일해야하지만 제약 조건이없는 숫자 열)가 있지만 DB에 두 번 이상 (최대 3 회) 삽입되었다는 것입니다 ... 확인은 코드에서 발생합니다).

우리는 Entity Framework 6.0을 사용합니다.

• 이 ASYNC_NETWORK_IO 대기 유형이 발생하는 이유와시기 및 이러한 유형을 피하는 방법을 아는 사람이 있습니까?
• 그리고 정확히 무엇을 의미합니까?

ASYNC_NETWORK_IO어떻게 든 클라이언트 응용 프로그램이 SQL Server가 결과를 제공하는 것만 큼 빠른 결과를 처리하지 않음을 나타냅니다. 이는 클라이언트 응용 프로그램 또는 서버와 클라이언트 응용 프로그램 간의 네트워크 연결 문제로 인해 발생할 수 있습니다.

Thomas LaRock 의 게시물을 참조하십시오

ASYNC_NETWORK_IO 대기는 두 시나리오 중 하나가 발생하고 있음을 나타냅니다. 첫 번째 시나리오는 세션 (예 : SPID)이 클라이언트 응용 프로그램이 결과 집합을 처리하고 더 많은 데이터를 처리 할 준비가되었다는 신호를 SQL Server로 다시 보내는 것을 기다리는 것입니다. 두 번째는 네트워크 성능 문제가있을 수 있다는 것입니다.

또는 Joe Sack의이 게시물

이미 알고 있듯이 ASYNC_NETWORK_IO (SQL 2005에서 확인) 및 NETWORKIO (SQL 2000에서 확인) 대기 유형은 SQL Server에서 결과를 충분히 빨리 처리하지 못하거나 네트워크 성능 문제와 관련된 호출 응용 프로그램과 관련이 있습니다. .

당신이 entity framework 브렌트 오자르에 의해이 게시물을 사용 하고 있기 때문에 너무 유용 할 수 있습니다

이러한 쿼리에 대한 대기 통계를 살펴보면 ASYNC_NETWORK_IO가 많으며 대개 1000+ 밀리 초인 것을 알았습니다. 그건 말도 안 돼요! CPU 시간이 적고 읽기가 거의없는 쿼리는 어떻게 완료하는 데 시간이 오래 걸립니까? 응용 프로그램이 수백만 행을 요구하는 것과 같지 않아 결과를 충분히 빨리 소비 할 수 없었습니다.

네트워크 문제를 나타내는 이름으로 인해 ASYNC_NETWORK_IO 대기 유형에 대한 몇 가지 오해가 있지만이 대기 유형의 이유는 매우 드 rare니다.

다음과 같은 두 가지 시나리오에서 과도한 ASYNC_NETWORK_IO 대기가 발생할 수 있습니다.

1. 세션은 처리 할 새 데이터를 받아 들일 수 있다는 신호를 SQL Server로 보내려면 클라이언트 응용 프로그램이 SQL Server로부터받은 데이터를 처리 할 때까지 기다려야합니다. 이는 잘못된 응용 프로그램 설계를 반영 할 수있는 일반적인 시나리오이며 ASYNC_NETWORK_IO 대기 유형 값이 과도하게 많이 발생하는 원인입니다.

   여기에는 과도한 ASYNC_NETWORK_IO 대기 유형 값을 유발하는 애플리케이션을 조사하고 종종이를 작성한 애플리케이션 개발자와 조정하는 것이 포함됩니다.

2. 네트워크 대역폭이 최대입니다. 이더넷이 막히면 응용 프로그램과의 데이터 전송 속도가 느려집니다. 이는 그 자체로 애플리케이션의 효율성을 떨어 뜨립니다.

이 페이지 에서 훨씬 더 자세한 내용을 볼 수 있습니다