|
SQLSERVER 사용자 연결 성능 카운터에 있는 SQL 인스턴스의 일반 통계 사용자 연결은 이에 대응합니다 성능 카운터에서 TCPv4Connections Established 문서로 참조할 수도 있습니다
SQLSERVER 서비스만 있는 기계에서,TCPV4 연결 설정 및 Mssql 사용자 연결이 두 매개변수는 기본적으로 동기화되어 있으며, 다음 테스트 내용에서 연결 수로 부릅니다
이 연결 수는 최대 동시성 제한과 유사하게 제한되어 있습니다. 이 한계에 도달하면, CPU, IO, MEM 자원이 여유 있어도 쿼리가 응답하지 않게 됩니다(일부 쿼리가 영향을 받는 것은 아닙니다).
TCPV4 연결 설정 및 Mssql 사용자 연결의 최대 가치는 다음 요인에 따라 달라집니다
a. 실행 문장의 복잡도가 관련이 있으며, 문장이 복잡할수록 최대 연결 수가 적어집니다(이 효과는 매우 중요합니다)
b. 요청의 스레드 동시성과 관련이 있습니다.
10개의 프로세스, 각 프로세스는 5,000개의 스레드를 열어 요청합니다,SELECT getdate()이 문장은 약 4000개에 도달하면 이미 포기됩니다(제 이해로는 많은 스레드가 리소스를 요청하지 않았지만, 요청 수가 많아 영향이 있다고 합니다).
10개의 프로세스, 각 프로세스는 1000개의 스레드를 열어 요청합니다, SELECT getdate()명세서는 10,000건을 넘을 수 있습니다.
c. 스레드 요청의 빈도와 관련이 있습니다
각 스레드가 쿼리를 실행하고 0-10,000밀리초 동안 일시정지하면, 중단되지 않은 것보다 더 적은 연결을 차지합니다
d. 시험에서 일부 닫히지 않은 연결부가 카운터를 팽창시키는 현상도 발견되었으나, 이에 대해서는 논의되지 않았습니다
10개의 프로세스, 각 프로세스는 1000개의 요청 스레드를 열고, 서버에서 쿼리 후 무작위로 (0초에서 10초까지) 일시정지합니다. 테스트 결과는 다음과 같습니다:
실행:[시스템]에서 * 선택하세요. [dbo]. [DBA_alert](이 쿼리는 200줄을 반환하며, 최대 연결 수는 700개이고 문제가 발생하기 시작합니다)
연결 수가 700에 도달하면 일부 오류가 보고되기 시작하고, 1200에 도달하면 많은 오류가 나타나 1800 부근의 연결 수가 멈춰 더 이상 증가하지 않습니다. 오류와 느린 연결이 많습니다
실행:SELECT getdate()형량(최대 연결 수는 3500개이며 문제가 시작됩니다)
연결 수가 3500에 도달하면 일부는 오류를 보고하기 시작하고, 최고 압력은 약 11,000에 도달하며, 연결 수는 여전히 서서히 증가하고 있습니다. 오류 및 느린 연결 끊김
결론은 다음과 같습니다: 주어진 압력 조건 하에서: 가장 간단하게 수행할 수 있는 방식SELECT getdate(), SELECT * FROM [시스템]을 실행할 때 최대 3500개까지 연결할 수 있습니다. [dbo]. [DBA_alert] 문장에서 최대 연결 수는 최대 700개까지만 가능합니다. 쿼리 타임아웃은 CPU, IO, MEM 모두 유휴 자원이 많을 때 발생합니다.
운영 환경에서는 10*1000개의 스레드 압력을 달성할 수 없지만, SQL은 테스트 환경보다 더 복잡합니다.
동시 번호병목 현상은 컴퓨터나 서버 네트워크 카드의 대역폭 때문이 아닙니다
위 내용을 증명하기 위해서입니다. 저는 다음과 같은 테스트를 했습니다. 대규모 동시성의 경우 exec dbo.run2;
ALTER 발동(dbo). [run2]
as
노카운트 설정
Get Date()
@i int를 선언하라
@i=0 집합
@i<1000 이 값이 1000일 때 최대 연결 수는 약 1300이고, 10일 때는 5000에 도달하는 것이 일반적입니다.
시작
[출판물]에 삽입하세요. [dbo]. [tb_test] ([name]) 값 (newid())
셋 @i=@i+1
끝
가자
변경 사이클 수는 반환 결과에 영향을 주지 않으며, 네트워크 카드 트래픽에 가해지는 압력은 동일하지만 한쪽은 빠르게 타임아웃되고 다른 쪽은 항상 확인할 수 있어 양쪽 네트워크 카드 대역폭 영향을 줄일 수 있습니다.
최대 연결 수가 정지할 때의 오류 내용:
netstat-최대 연결 수가 정체된 결과(확립됨):
최대 연결 수가 멈출 때 실행 중인 테스트 프로그램 다이어그램:
주목할 만한 점은:오류나 타임아웃과의 연결은 고르지 않으며, 일부 프로세스에 집중되어 있습니다. 즉, 일부 프로세스는 항상 정상적으로 실행될 수 있고, 다른 부분은 오랜 시간 오류를 보고합니다(프로세스의 시작 순서와는 무관하며, 일부 프로세스는 자원을 가지고 정상적으로 작동할 수 있지만, 원래 리소스의 스레드 내 다른 프로세스는 선점되어 새로운 리소스를 신청할 수 없으며, 반복적으로 오류를 보고합니다). 위 그림에서 보듯이, 두 번째와 일곱 번째 프로세스는 많은 타임아웃이 발생하기 시작했고, 다른 프로세스들은 계속 작동했습니다. 서버에서는 쿼리가 일부 기계에 의해 영향을 받지 않거나 덜 영향을 받는 것처럼 보일 수 있으며, 일부 기계는 크게 영향을 받습니다.
결론: SQLSERVER 사용자 연결의 상한선은 일련의 조건과 관련이 있지만, 병목 현상을 추정하고 예측하는 것은 여전히 가능합니다. 이 상한선에 도달하면 많은 쿼리가 느리고 타임아웃이 발생할 것입니다(비록 CPU, IO). MEM, 트래픽은 유휴 자원이 있을 때도 발생할 수 있습니다. 사실 TCP 파라미터를 변경하면 이 상한선이 올라가며, 나중에 보충 자료를 쓸 수도 있습니다
|
게시됨 2014. 11. 26. 오후 3:11:08
|
|
|
|
