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


16

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

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

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

추가 정보 :

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

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

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

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

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

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

답변:


14

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

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

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

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

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


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

글 머리 기호 2의 경우 : 응용 프로그램은 SQL과 같은 상자에 있으며 연결은 공유 메모리 방법을 통해 이루어집니다. 이론적으로는 매우 빠릅니다.
AngryHacker
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.