VMware 가상 머신에서 실행되는 단일 SQL Server 2016 SP1 인스턴스가 있습니다. 각각 다른 응용 프로그램을위한 4 개의 데이터베이스가 포함되어 있습니다. 이러한 응용 프로그램은 모두 별도의 가상 서버에 있습니다. 아직 프로덕션 환경에서 사용중인 제품은 없습니다. 그러나 애플리케이션을 테스트하는 사람들은 성능 문제를보고합니다.
서버 통계는 다음과 같습니다.
- 128GB RAM (SQL Server의 경우 최대 110GB 메모리)
- 4.6GHz에서 4 코어
- 10GBit 네트워크 연결
- 모든 스토리지는 SSD 기반
- 프로그램 파일, 로그 파일, 데이터베이스 파일 및 tempdb는 서버의 별도 파티션에 있습니다.
- asd
사용자는 C ++ 기반 ERP 응용 프로그램을 통해 단일 화면 액세스를 수행하고 있습니다.
ostress많은 작은 쿼리 또는 큰 쿼리를 사용하여 Microsoft에서 SQL Server를 스트레스 테스트하면 최대 성능을 얻습니다. 클라이언트가 충분히 답할 수 없기 때문에 제한하는 것은 클라이언트입니다.
그러나 사용자가 거의없는 경우 SQL Server는 거의 아무것도하지 않습니다. 그러나 사람들은 응용 프로그램에 저장하기 위해 영원히 기다려야합니다.
Paul Randal의 ” 문제가있는 곳을 알려주십시오 “쿼리에 따르면 모든 대기 이벤트의 50 %는 ASYNC_NETWORK_IO입니다.
이는 네트워크 문제 또는 응용 프로그램 서버 또는 클라이언트의 성능 문제를 의미 할 수 있습니다. 이들 중 어느 것도 원격으로 최대 용량으로 리소스를 사용하지 않습니다. 대부분의 경우 CPU는 모든 시스템 (클라이언트, appserver, db 서버)에서 약 26 %입니다.
네트워크 연결 대기 시간은 약 1-3ms입니다. DB 서버의 IO는 응용 프로그램을 정상적으로 사용하는 동안 최대 20MB / s 쓰기 속도입니다 (avg는 7-9MB / s 임). 스트레스 테스트를하면 약 5GB / s 정도가됩니다.
버퍼 캐시 크기는 ERP 시스템의 DB의 경우 60GB, 금융 소프트웨어의 경우 20GB, 품질 보증 소프트웨어의 경우 1GB, 문서 보관 시스템의 경우 3GB입니다.
SQL Server 계정에 Instant File Initialization 을 사용할 수있는 권한을 부여했습니다 . 그것은 조금이라도 성능을 향상시키지 못했습니다.
정상적인 사용시 페이지 수명은 약 15k 이상입니다. 심한 스트레스 테스트가 끝나면 약 0.05k로 떨어집니다. 배치 / 초는 작업량에 따라 약 2-8k입니다.
ERP 앱이 잘못 작성되었다고 말하지만 모든 응용 프로그램이 영향을 받기 때문에 할 수는 없습니다. 최소한의 워크로드에서도.
그러나 나는 이것을 일으키는 원인을 정확히 알 수 없습니다. 이 문제와 관련하여 팁, 힌트 자습서, 응용 프로그램, 모범 사례 또는 최악의 사례 문서 또는 염두에 두어야 할 사항이 있습니까?
결과는 sp_BlitzFirst다음 과 같습니다.
나는 그것을 600 초 동안 달렸다. 앱의 작업량이 많을 때 시작했습니다. 시간의 1/3입니다 ASYNC_NETWORK_IO. 나는 또한과 네트워크 연결 테스트 NTttcp, PsPing, ipferf3,와 pathping. 특이한 것은 없습니다. 응답 시간은 최대 3ms, 평균 0.3ms입니다. 처리량은 약 1000MB / s입니다.
조사 결과 항상 ASYNC_NETWORK_IO대기자 수가 1 위가되었습니다.
Large-Receive-OffloadVMware 에서 기능 을 비활성화 한 결과를 조사했습니다 . 아직 테스트 중이지만 결과가 일치하지 않는 것 같습니다. 첫 번째 ‘벤치 마크’는 19 분의 지속 시간을 가져 왔습니다 (최상의 결과는 13 분이며, 앱이 SQL Server 자체가있는 VM에서 실행될 때만 달성됩니다). 두 번째 결과는 28 분이며 이는 실제로 나쁘다.
우리의 ‘벤치 마크’의 첫 결과는 19 분이었습니다. 어느 것이 좋니. 최상위 결과는 13 분 (애플리케이션이 SQL Server 자체가있는 VM에서 벤치마킹 할 때만 가능함)이기 때문입니다. 이것은 일부 네트워크 관련 문제를 강력하게 암시합니다. 또는 VMware 구성에 문제가 있습니다.
나는 현재 병목 현상을 해결하기 위해 어떤 방법을 사용하지 못하고 있습니다.
앱의 최대 성능은 앱이 SQL Server 자체가있는 VM에서 실행될 때만 달성 할 수 있습니다. 앱이 다른 VM 또는 가상 데스크톱에서 실행되면 벤치 마크 기간이 13 분에서 40 분 이상으로 3 배가됩니다. 모든 끝점 (SQL Server의 VM, 앱 서버의 VM 및 가상 데스크톱)이 동일한 물리적 하드웨어를 사용하고 있습니다. 다른 모든 엔드 포인트를 다른 하드웨어로 옮겼습니다.
편집 : 문제가 돌아온 것 같습니다. 에너지 절약 모드를 밸런스에서 고성능으로 설정 한 후 실제로 응답 시간이 대폭 향상되었습니다. 그러나 오늘 저는 300 초 샘플로 sp_BlitzFirst를 다시 실행했습니다. 결과는 다음과 같습니다.
sp_blitzfirst가 실행 된 시간보다 ASYNC_NETWORK_IO에 대한 대기 시간이 2 초 이상 표시됩니다.
답변
기본 대기가 ASYNC_NETWORK_IO인 경우 SQL Server에 문제가없는 것입니다. 거의 항상 응용 프로그램 병목 현상으로 인해 발생합니다. 응용 프로그램 서버의 병목 현상이 아니라 응용 프로그램의 병목 현상을 의미합니다.
응용 프로그램 병목 현상은 일반적으로 SQL Server가 데이터를 보내는 동안 행 단위 처리로 인해 발생합니다.
- 응용 프로그램이 SQL Server에서 데이터를 요청하고 있습니다
- SQL Server가 데이터를 빠르게 보내고 있습니다
- 응용 프로그램은 각 행을 처리하는 동안 SQL Server가 대기하도록 지시합니다.
ASYNC_NETWORK_IO응용 프로그램이 대기하도록 지시하는 동안 SQL Server에서 대기 시간 기록
그 대신 응용 프로그램은 SQL Server의 모든 데이터를 소비해야하며 행 단위 처리를 수행합니다. 이 시점에서 SQL Server가 제대로 작동하지 않습니다.
sp_BlitzFirst 산출
LCK_M_S대기는 높지 않다. 30 초 샘플의 2 초만 있으며 평균은 400ms입니다. 그것은 문제가 될 가능성이 거의 없습니다. ASYNC_NETWORK_IO샘플에서 가장 기다려야합니다. 여전히 응용 프로그램 문제입니다. 당신이 LCK물건에 대한 도움을 원한다면 , 우리는 관련된 쿼리를 볼 필요가 있습니다.
ASYNC_NETWORK_IO그 샘플 에서도 그렇게 나쁘지 않습니다. 대기 시간이 샘플 크기 이상이면 눈이 커집니다. 내가 파고 때입니다.
전체 문제는 ASYNC_NETWORK_IO입니다. 이것은 SQL Server 문제가 아닙니다. 응용 프로그램 (SQL Server가 데이터를 보내는 동안 행 단위로 처리하는 중), 응용 프로그램 서버 (이미 정상이라고 말함) 또는 네트워크 (네트워크가 정상이라고 말함)에 문제가 있습니다. 따라서 문제는 응용 프로그램과 관련이 있습니다. C ++ 앱을 수정해야합니다.
답변
내 자신의 질문에 대답하기 위해 : ASYNC_NETWORK_IO가 SQL Server에 최상위 대기 유형으로 나타나는 주된 이유 energy saving는 Windows 서버 설정이 'balanced'대신 설정 되었기 때문 입니다 'high performance'. 우리는 이후 일부 VM웨어 관리자 얘기, 그들은 모두 있다고 말했다 이 설정은 성능을 죽인다 .
이에 대한 솔루션은 다음 중 하나입니다.
- Windows 서버를 설치할 때 에너지 제어를 설치하지 마십시오
- 그룹 정책을 통해 모든 서버에서 에너지 절약 모드를 고성능으로 설정
ASYNC_NETWORK_IO와 관련된 다른 모든 문제 / 통계는 잘못 작성된 ERP 앱과 관련이 있습니다. 이 문제를 해결하는 데 도움을 주신 모든 분들께 감사드립니다. 귀하의 의견, 제안 및 조언은 매우 환영하고 도움이되었습니다!