ASYNC_NETWORK_IO 대기 유형은 걱정할 사항이 있습니까?

실행하는 데 시간이 오래 걸리는 저장 프로 시저 목록을 살펴보면 대기 시간이 가장 큰 것으로 나타났습니다. 그러나 대부분의 대기 시간 (81 %)은 ASYNC_NETWORK_IO이며 이유는 다음과 같습니다. 저장 프로 시저가 약 400MB의 정보를 전송합니다.

문서에서 ASYNC_NETWORK_IO의 원인은 클라이언트가 많은 데이터를 처리 할 수 없으며 이는 사실 일 수 있다는 것입니다. 클라이언트가 ADO.NET을 통해 저장 프로 시저를 호출 한 다음 데이터 세트를 처리하기 때문에 클라이언트를 유지하는 방법을 잘 모르겠습니다.

따라서이 정보가 주어지면이 절차의 ASYNC_NETWORK_IO 대기 유형에 대해 걱정해야합니까? 실제로 서버 성능에 영향을 줍니까?

추가 정보 :

SQL Server 2005의 서비스 팩 2를 사용하고 있습니다.
클라이언트 응용 프로그램은 SQL Server와 같은 상자에 있습니다 (알고 있습니다.하지만 아무것도 할 수는 없습니다).

— AngryHacker
소스

이 유형의 대기에 대해 생각하는 가장 좋은 방법은 쿼리에 원인이 없으므로 클라이언트에 데이터를 반환하는 것입니다. 또한 Access에서 테이블을 연결 한 많은 항목이 표시됩니다. 클라이언트 앱에 따라 한 가지 가능성은 데이터를 더 작은 청크로 나누거나 더 적은 데이터를 반환하는 것입니다. 이것이 옵션이 아닌 경우 옵션을 줄이기 위해 수행 할 수있는 작업이 제한 될 수 있습니다.

— JNK

클라이언트 앱이 공유 메모리 또는 TCP / IP를 사용하여 연결되어 있습니까? 클라이언트 앱과 SQL Server가 동일한 프로세서 코어 세트를 공유하고 있거나 선호도 마스킹 기술을 사용하여 분리합니까?

— Jon Seigel

기본 연결 유형이며 특별한 것은 없으므로 공유 메모리를 사용하고 있습니다. 동일한 코어 세트를 사용하는 두 앱 모두 선호도가 없습니다.

— AngryHacker

스토리지가 SAN입니까 아니면 로컬입니까?

— Eric Higgins

@EricHiggins 로컬 RAIDed 하드 드라이브 세트입니다.

— AngryHacker

말했듯이이 대기 유형은 응용 프로그램이 SQL Server를 따라 가지 못하고 있음을 나타냅니다. 이제 실제로 의미하는 바는 SQL Server가 원하는 속도로 네트워크를 통해 데이터를 전송할 수 없다는 것입니다.

두 가지 근본적인 원인이있을 수 있습니다.

앱이 비효율적으로 작성되었으며 행을 충분히 빠르게 처리하지 않습니다.
네트워크가 최대입니다.

응용 프로그램 자체가 너무 느리면 다른 쿼리의 성능에 큰 영향을 미치지 않습니다. 반면에 파이프가 너무 작 으면 다른 쿼리가 결과를 보낼 수 없으므로 기다려야합니다.

그러나 후자의 경우 모든 연결이 ASYNC_NETWORK_IO에서 대기합니다. 그 영향을 명확하게 볼 수 있어야합니다.

— 세바스찬 마이 네
소스

글 머리 기호 1. 데이터 검색은 표준 코드를 사용하여 ADO.NET을 통해 수행됩니다. var dataSet = new DataSet(); var da = new SqlDataAdapter(command); da.Fill(dataSet); 따라서 정확히 무엇이 느릴 수 있는지 잘 모르겠습니다.

— AngryHacker

글 머리 기호 2의 경우 : 응용 프로그램은 SQL과 같은 상자에 있으며 연결은 공유 메모리 방법을 통해 이루어집니다. 이론적으로는 매우 빠릅니다.

— AngryHacker