실행하는 데 시간이 오래 걸리는 저장 프로 시저 목록을 살펴보면 대기 시간이 가장 큰 것으로 나타났습니다. 그러나 대부분의 대기 시간 (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