긴 "클라이언트 처리 시간"으로 인해 느린 원격 SELECT 문

프로덕션 서버 (SQL Server 2008, 매우 강력한 시스템)에 연결되어있는 동안이 SELECT 문은 2 초가 걸리며 모든 필드 (총 4MB의 데이터)를 뱉어냅니다.

SELECT TOP (30000) *
FROM person
WITH(NOLOCK);

어떤에서 다른 같은 네트워크에있는 상자 같은 쿼리합니다 (SQL 인증 또는 Windows 인증을 사용하여 연결) 일분 8 초 .

인덱싱 문제 나 쿼리 관련 문제가 아님을 설명하기 위해이 매우 간단한 문장으로 테스트하고 있습니다. (현재 모든 쿼리에 성능 문제가 있습니다 ...)

행은 한꺼번에 나옵니다. 첫 번째 행을 즉시 가져온 다음 행이 일괄 처리 될 때까지 1 분 이상 기다립니다.

원격 상자에서 쿼리를 실행할 때의 클라이언트 통계는 다음과 같습니다.

Query Profile Statistics
  Number of INSERT, DELETE and UPDATE statements 0
  Rows affected by INSERT, DELETE, or UPDATE statements 0
  Number of SELECT statements  2
  Rows returned by SELECT statements 30001
  Number of transactions 0

Network Statistics
  Number of server roundtrips 3
  TDS packets sent from client        3
  TDS packets received from server 1216
  Bytes sent from client         266
  Bytes received from server 4019800

Time Statistics
  Client processing time 72441 ms (72 seconds)
  Total execution time   72441 ms
  Wait time on server replies 0

"클라이언트 처리 시간"이 총 실행 시간과 같다는 것을 알 수 있습니다.

실제 데이터 전송에 오랜 시간이 걸리는 이유를 진단하기 위해 어떤 조치를 취할 수 있는지 아는 사람이 있습니까?

머신 간의 데이터 전송 속도를 제한하거나 제한하는 SQL 구성 매개 변수가 있습니까?

귀하의 문제는 귀하의 정보에 따라 네트워크와 관련이 있습니다. 따라서 그것은 네트워크 전문가와 거래해야합니다 (나는 아닙니다).

도움이 될 것 :

• 더 빠른 NIC 카드 (SQL 서버).
• 서버 (웹 서버와 SQL Server) 사이에 할당 된 / 특정 NIC 카드 / 서브넷 추가.

웹 서버가 SQL 서버와 동일한 서브넷에 있습니까?

라우터 / 브릿지 등이 있습니까?

SQL Server에서 가능한 많은 변경 사항은 다음과 같습니다.

• 독점 MS "TDS 프로토콜"을 사용하여 SQL Server에서 출력 데이터를 보냅니다.
• TDS 버퍼의 기본 크기는 4KB입니다. MSDB : "네트워크 패킷 크기 옵션"을 참조하십시오.
• 데이터 압축 (SQL Server 또는 외부 응용 프로그램 사용)-데이터의 특성에 따라 다릅니다.

기본 크기를 사용하고 있습니다. 통계 참조 : "서버 1216에서 수신 한 TDS 패킷"(4MB / 1K = 4KB). 예, TDS 버퍼의 크기를 변경할 수 있습니다. Google 참조 : "TDS 프로토콜 배치 크기"

"SQL의 네트워크 패킷 크기가 실제로 왕복 트래픽을 결정합니까?"라는 주제에 대한 좋은 토론입니다.

그러나 TDS 패키지 크기를 변경하면 예상 할 수없는 결과가 발생하며 예외적 인 경우에만 프로덕션 환경에서 사용해야합니다.

중간 계층에서 아키텍처 변경 또는 데이터 캐싱 도입도 도움이 될 것입니다.

이 문제는 이제 해결되었습니다.

네트워크 문제였으며 SQL 상자에서 10GB / s NIC 카드 대신 100MB / s NIC 카드를 사용하고있었습니다 .

올바른 네트워크 카드를 사용하도록 네트워크 구성을 변경하면 문제가 해결되었습니다. 이제 프로덕션 SQL 상자와 네트워크의 다른 상자에서 모든 쿼리에 대해 비슷한 성능을 얻습니다.

도와 주셔서 감사합니다.

처음 읽을 때 네트워크 대기 시간 문제가있는 것 같습니다. Network Perfmon 카운터를 보셨습니까? 그것들은 네트워크에 무슨 일이 일어나고 있는지에 대한 표시를 줄 수 있습니다.

에서 견적 어떤 성능 모니터 카운터 나는 모니터링해야하고 그들 각각이 무엇을 의미하는지?

네트워크 IO

네트워크 I / O를 측정하기 위해 다음 카운터를 사용할 수 있습니다.

네트워크 인터페이스 바이트 총계 / 초

임계 값 : 네트워크 대역폭의 80 % 이상 지속 된 값.

의미 :이 카운터는 각 네트워크 어댑터를 통해 바이트를 보내고받는 속도를 나타냅니다. 이 카운터는 네트워크 어댑터의 트래픽이 포화 상태인지 여부와 다른 네트워크 어댑터를 추가해야 하는지를 알려줍니다. 문제를 얼마나 빨리 식별 할 수 있는지는 사용중인 네트워크 유형과 다른 응용 프로그램과 대역폭을 공유하는지 여부에 따라 다릅니다.

수신 된 네트워크 인터페이스 바이트 / 초

이 카운터는 각 네트워크 어댑터를 통해 바이트를받는 속도를 나타냅니다. 수신 대역폭을 총 대역폭의 일부로 계산할 수 있습니다. 이렇게하면 클라이언트에서 들어오는 데이터를 최적화해야하거나 들어오는 트래픽을 처리하기 위해 다른 네트워크 어댑터를 추가해야한다는 것을 알 수 있습니다.

보낸 네트워크 인터페이스 바이트 / 초

이 카운터는 각 네트워크 어댑터를 통해 바이트가 전송되는 속도를 나타냅니다. 수신 대역폭을 총 대역폭의 일부로 계산할 수 있습니다. 이렇게하면 클라이언트로 전송되는 데이터를 최적화해야하거나 아웃 바운드 트래픽을 처리하기 위해 다른 네트워크 어댑터를 추가해야합니다.

ServerBytes 총 / 초

이 값은 네트워크 용량의 50 %를 넘지 않아야합니다.

이 카운터는 네트워크를 통해 보내고받은 바이트 수를 나타냅니다. 값이 클수록 병목 현상으로 네트워크 대역폭이 나타납니다. 모든 서버의 총 바이트 / 초 합계가 네트워크의 최대 전송 속도와 대략 같으면 네트워크를 분할해야 할 수도 있습니다.

프로세서 % 인터럽트 시간

이 카운터는 프로세서가 하드웨어 인터럽트 수신 및 서비스에 소비하는 시간의 백분율을 나타냅니다. 이 값은 네트워크 어댑터와 같이 인터럽트를 생성하는 장치의 활동을 간접적으로 나타냅니다.

네트워크 인터페이스 (*) 출력 대기열 길이

이 카운터는 네트워크 어댑터에서 대기중인 스레드 수를 확인합니다. 네트워크 어댑터에서 대기중인 스레드가 많은 경우 시스템은 네트워크 대기 시간 또는 네트워크 대역폭으로 인해 네트워크 I / O를 포화시킬 가능성이 높습니다.

출력 큐 길이는 출력 패킷 큐의 길이입니다 (패킷 단위). 이 길이가 2보다 길면 지연이 발생하고 병목 현상을 찾아 제거해야합니다 (가능한 경우). 이 구현에서는 NDIS (Network Driver Interface Specification)에 의해 요청이 큐에 대기되므로 항상 0입니다.

몇 가지 예비 질문 : 1) 서버에 Prod에 SQL 클라이언트가 있습니다. 서버 머신을 설정 했습니까? 따라서 동일한 컴퓨터에있는 클라이언트에서 동일한 쿼리를 작성하면 2 초 안에 완료됩니까? 이 작업을 시도 했습니까? 정말 2 초인가요? 2) 프로덕션 환경의 구성이 변경되었다 (또는 프로덕션 서버가 다른 네트워크 / 전체 서버로 재 구축 됨). 이전 프로덕션 환경에서 쿼리 소비 시간은 얼마입니까?

동일한 네트워크의 다른 상자에서 ... 같은 쿼리는 1 분, 8 초가 걸립니다. 3) 약 70 초 동안 주어진 네트워크의 특정 컴퓨터 (특정 컴퓨터를 추출)에있는 클라이언트에서 쿼리가 반환되고 클라이언트에서 소비된다고 말하고 있습니까? 제대로 이해 했습니까? 3.1 부수적으로이 질의의 소비시기는 무엇입니까? 4) 그러나 쿼리 출력 소비 시간을 사용하는 특정 클라이언트 시스템의 경우 : 클라이언트 실행 시간 15:30 : 48 분 15 분? (그리고 이번에는 분명히 받아 들일 수 없습니다)? 옳은? 5) 문제가 단일 클라이언트 시스템으로 제한됩니까? 아니면 (새로운 환경에서) 모든 클라이언트 / 미드 티어 등의 머신에? 6) 핑으로 표시되는 지연 시간은 얼마입니까? 클라이언트 컴퓨터에서 서버로? 7) 귀하 (또는 네트워크 관리자)는 tracert를 두 가지 방법으로 (클라이언트에서 서버로, 서버에서 클라이언트로) 실행 했습니까? 얼마나 많은 홉? 결합 된 시간은 무엇입니까? 8) 오래된 생산 네트워크가 살아 있습니까? Ping과 Traceroute를 사용하여 비교할 수 있습니까-클라이언트와 서버 사이의 시간과 홉은 무엇입니까?

궁금한 점 : 이것은 쿼리의 예입니까? 또는 검색어의 정확한 문구? 쿼리에 실제로 WHERE 절이 포함되어 있지 않습니까? 나에게 이것이 매우 드문 일이라고 동의하십시오. 테이블에 클러스터 된 인덱스가 있거나 힙입니까? 테이블에는 모두 몇 개의 행이 포함되어 있습니까? 테이블이 심하게 조각 나나요? 호기심에서 : 왜 TOP NNN을 선택해야합니까? ROWCOUNT NNN을 설정하고 SELECT *? 이 쿼리는 클라이언트가 하루에 몇 번 발행합니까? 1? 100? 1MLN? 기본 데이터는 정적이거나 동적이며 많이 변경됩니까? 얼마 (하루에 0.01 %, 하루에 1 %, 하루에 10 %) 쿼리 출력은 프로그래밍 방식으로 처리됩니까? (사용자가 아닙니까?) 왜 중간 계층에 캐시 / 저장되지 않습니까? 감사합니다, 알렉세이