프로덕션 SQL Server의 주요 성능 문제는 어떻게 해결합니까?

이 질문은 기본적으로이 질문에 대한 후속 질문입니다.
SQL Server 2016의 이상한 성능 문제

우리는 이제이 시스템으로 생산성을 높였습니다. 마지막 게시물 이후 다른 응용 프로그램 데이터베이스가이 SQL Server에 추가되었지만.

시스템 통계는 다음과 같습니다.

• 128GB RAM (SQL Server의 경우 최대 110GB 메모리)
• 4 코어 @ 2.6GHz
• 10GBit 네트워크 연결
• 모든 스토리지는 SSD 기반
• 프로그램 파일, 로그 파일, 데이터베이스 파일 및 tempdb는 서버의 별도 파티션에 있습니다.
• Windows Server 2012 R2
• VMware 버전 HPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17
• VMware Tools 버전 10.0.9, 빌드 3917699
• Microsoft SQL Server 2016 (SP1) (KB3182545)-13.0.4001.0 (X64) 2016 년 10 월 28 일 18:17:30 저작권 (c) Windows Server 2012 R2 Standard 6.3의 Microsoft Corporation Standard Edition (64 비트) (빌드 9600 :) (하이퍼 바이저)

우리 시스템에는 현재 중대한 성능 문제가 있습니다. 매우 높은 CPU 사용량 및 스레드 수 :

활동 모니터 대기 통계 (매우 신뢰할 수 없음)

sp_blitzfirst의 결과 :

sp_configure의 결과 :

고급 서버 설정 (불행한 독일어에서만)

MAXDOP 설정이 변경되었습니다.

나는 이것이 SQL Server 자체에서 문제가되지 않는다는 것을 알고 있습니다 . 가상화 (vmware), 네트워크 관련 (이미 테스트 했음) 또는 응용 프로그램 자체에 문제가있을 수 있습니다. 난 그냥 더 못 박고 싶어

ASYNC_NETWORK_IO가 많으면 SQL Server 프로세스의 스레드 수가 많아 집니까? 스레드를 닫을 수 없기 때문에 많은 작업자를 혼란스럽게 생각합니다. 맞습니까?

필요한 추가 정보를 제공해 드리겠습니다. 귀하의 지원에 미리 감사드립니다!

편집하다:

에 의한 결과 sp_Blitz @OutputType = ‘markdown’, @CheckServerInfo = 1

우선 순위 1 : 백업 :

• 데이터베이스가있는 동일한 드라이브에 백업-지난 2 주 동안 E : \ 드라이브에서 5 개의 백업이 수행되었으며 데이터베이스 파일도 있습니다. 해당 어레이에 장애가 발생하면 심각한 위험을 나타냅니다.

우선 순위 1 : 신뢰성 :

• 2 주 이상 지난 마지막 DBCC CHECKDB

  • babtec_prod-마지막으로 성공한 CHECKDB : 2017-08-20 00 : 01 : 01.513

  • D3PR-마지막으로 성공한 CHECKDB : 절대

  • DEMO77-최종 성공 CHECKDB : 2016-02-23 20 : 31 : 38.590

  • FINP-마지막으로 성공한 CHECKDB : 2017-04-23 22 : 01 : 19.133

  • GridVis_EnMs-마지막으로 성공한 CHECKDB : 2017-05-18 22 : 10 : 48.120

  • master-마지막으로 성공한 CHECKDB : 절대

  • 모델

  • msdb

  • PROD77-마지막으로 성공한 CHECKDB : 2016-02-23 21 : 33 : 24.343

우선 순위 10 : 성능 :

• 쿼리 저장소 비활성화-이 데이터베이스에서 새로운 SQL Server 2016 쿼리 저장소 기능이 활성화되지 않았습니다.

  • babtec_prod

  • D3PR

  • 데모 77

  • 핀

  • GridVis_EnMs

우선 순위 50 : DBCC 이벤트 :

• DBCC DROPCLEANBUFFERS-사용자 schorsch가 2017 년 9 월 21 일 오전 11시 57 분부터 2017 년 9 월 21 일 오전 11시 57 분까지 DBCC DROPCLEANBUFFERS를 1 회 실행했습니다. 이것이 프로덕션 박스 인 경우, 이런 상황이 발생하면 메모리에서 모든 데이터를 지우는 것입니다. 어떤 괴물이 그렇게할까요?

• DBCC SHRINK %-사용자 schorsch가 2017 년 9 월 21 일 11:51 PM과 Okt 4 2017 9:02 AM 사이에서 파일을 6 번 축소했습니다. 그래서, 그들은 부패를 고치려고합니까, 아니면 부패의 원인입니까?

• 전체 이벤트-287 개의 DBCC 이벤트가 2017 년 9 월 19 일 1:40 PM과 Okt 4 2017 3:20 PM 사이에 발생했습니다. CHECKDB 및 일반적으로 다른 양성 DBCC 이벤트는 포함되지 않습니다.

우선 순위 50 : 성능 :

• 파일 증가 속도가 느리다 PROD77-2 증가에는 각각 15 초 이상이 걸렸습니다. 파일 자동 증가를 더 작은 단위로 설정하십시오.

우선 순위 50 : 신뢰성 :

• 페이지 확인이 최적이 아님 babtec_prod-데이터베이스 [babtec_prod]에 페이지 확인을위한 TORN_PAGE_DETECTION이 있습니다. SQL Server는 저장소 손상을 인식하고 복구하는 데 시간이 오래 걸릴 수 있습니다. 대신 CHECKSUM을 사용하십시오.

우선 순위 100 : 성능 :

• 단일 쿼리에 대한 많은 계획-계획 캐시에 단일 쿼리에 대한 3576 계획이 있으므로 매개 변수화 문제가있을 수 있습니다.

우선 순위 110 : 성능 :

• 클러스터형 인덱스가없는 활성 테이블

  • babtec_prod-[babtec_prod] 데이터베이스에는 적극적으로 쿼리되는 힙 (클러스터형 인덱스가없는 테이블)이 있습니다.

  • D3PR-[D3PR] 데이터베이스에는 적극적으로 쿼리되는 힙 (클러스터형 인덱스가없는 테이블)이 있습니다.

  • DEMO77-[DEMO77] 데이터베이스에는 적극적으로 쿼리되는 힙 (클러스터형 인덱스가없는 테이블)이 있습니다.

  • FINP-[FINP] 데이터베이스에는 적극적으로 쿼리되는 힙 (클러스터형 인덱스가없는 테이블)이 있습니다.

  • GridVis_EnMs-[GridVis_EnMs] 데이터베이스에는 적극적으로 쿼리되는 힙 (클러스터형 인덱스가없는 테이블)이 있습니다.

  • PROD77-[PROD77] 데이터베이스에는 적극적으로 쿼리되는 힙 (클러스터형 인덱스가없는 테이블)이 있습니다.

우선 순위 150 : 성능 :

• 신뢰할 수없는 외래 키

  • babtec_prod-[babtec_prod] 데이터베이스에는 아마도 사용하지 않도록 설정되고 데이터가 변경된 다음 키가 다시 사용되도록 설정된 외래 키가 있습니다. 키를 활성화하는 것만으로는 최적화 프로그램이이 키를 사용하기에 충분하지 않습니다. WITH CHECK CHECK CONSTRAINT 매개 변수를 사용하여 테이블을 변경해야합니다.

  • D3PR-[D3PR] 데이터베이스에 아마도 사용하지 않도록 설정된 외래 키가 있고 데이터가 변경된 후 키가 다시 활성화되었습니다. 키를 활성화하는 것만으로는 최적화 프로그램이이 키를 사용하기에 충분하지 않습니다. WITH CHECK CHECK CONSTRAINT 매개 변수를 사용하여 테이블을 변경해야합니다.

• 클러스터형 인덱스가없는 비활성 테이블

  • D3PR-[D3PR] 데이터베이스에는 마지막 재시작 이후 쿼리되지 않은 힙 (클러스터형 인덱스가없는 테이블)이 있습니다. 백업 테이블이 부주의하게 남겨질 수 있습니다.

  • GridVis_EnMs-[GridVis_EnMs] 데이터베이스에는 마지막 재시작 이후 쿼리되지 않은 힙 (클러스터형 인덱스가없는 테이블)이 있습니다. 백업 테이블이 부주의하게 남겨질 수 있습니다.

• 테이블에 대한 트리거 babtec_prod-[babtec_prod] 데이터베이스에는 26 개의 트리거가 있습니다.

우선 순위 170 : 파일 구성 :

• C 드라이브의 시스템 데이터베이스

  • master-마스터 데이터베이스에는 C 드라이브에 파일이 있습니다. C 드라이브에 시스템 데이터베이스를 배치하면 공간이 부족할 때 서버가 충돌 할 위험이 있습니다.

  • model-모델 데이터베이스에는 C 드라이브에 파일이 있습니다. C 드라이브에 시스템 데이터베이스를 배치하면 공간이 부족할 때 서버가 충돌 할 위험이 있습니다.

  • msdb-msdb 데이터베이스에는 C 드라이브에 파일이 있습니다. C 드라이브에 시스템 데이터베이스를 배치하면 공간이 부족할 때 서버가 충돌 할 위험이 있습니다.

우선 순위 170 : 신뢰성 :

• 최대 파일 크기 세트

  • D3PR-[D3PR] 데이터베이스 파일 d3_data_01의 최대 파일 크기는 61440MB로 설정되어 있습니다. 공간이 부족하면 사용 가능한 드라이브 공간이 있어도 데이터베이스 작동이 중지됩니다.

  • D3PR-[D3PR] 데이터베이스 파일 d3_data_idx_01의 최대 파일 크기는 61440MB로 설정되어 있습니다. 공간이 부족하면 사용 가능한 드라이브 공간이 있어도 데이터베이스 작동이 중지됩니다.

  • D3PR-[D3PR] 데이터베이스 파일 d3_firm_01의 최대 파일 크기는 61440MB로 설정되어 있습니다. 공간이 부족하면 사용 가능한 드라이브 공간이 있어도 데이터베이스 작동이 중지됩니다.

  • D3PR-[D3PR] 데이터베이스 파일 d3_firm_idx_01의 최대 파일 크기는 61440MB로 설정되어 있습니다. 공간이 부족하면 사용 가능한 드라이브 공간이 있어도 데이터베이스 작동이 중지됩니다.

  • D3PR-[D3PR] 데이터베이스 파일 d3_log_01의 최대 파일 크기는 61440MB로 설정되어 있습니다. 공간이 부족하면 사용 가능한 드라이브 공간이 있어도 데이터베이스 작동이 중지됩니다.

  • D3PR-[D3PR] 데이터베이스 파일 d3_phys_01의 최대 파일 크기는 61440MB입니다. 공간이 부족하면 사용 가능한 드라이브 공간이 있어도 데이터베이스 작동이 중지됩니다.

  • D3PR-[D3PR] 데이터베이스 파일 d3_phys_idx_01의 최대 파일 크기는 61440MB로 설정되어 있습니다. 공간이 부족하면 사용 가능한 드라이브 공간이 있어도 데이터베이스 작동이 중지됩니다.

  • D3PR-[D3PR] 데이터베이스 파일 d3_sys_01의 최대 파일 크기는 20480MB로 설정되어 있습니다. 공간이 부족하면 사용 가능한 드라이브 공간이 있어도 데이터베이스 작동이 중지됩니다.

  • D3PR-[D3PR] 데이터베이스 파일 d3_usr_01의 최대 파일 크기는 20480MB로 설정되어 있습니다. 공간이 부족하면 사용 가능한 드라이브 공간이 있어도 데이터베이스 작동이 중지됩니다.

  • D3PR-[D3PR] 데이터베이스 파일 d3_wort_01의 최대 파일 크기는 20480MB로 설정되어 있습니다. 공간이 부족하면 사용 가능한 드라이브 공간이 있어도 데이터베이스 작동이 중지됩니다.

  • D3PR-[D3PR] 데이터베이스 파일 d3_wort_idx_01의 최대 파일 크기는 20480MB로 설정되어 있습니다. 공간이 부족하면 사용 가능한 드라이브 공간이 있어도 데이터베이스 작동이 중지됩니다.

우선 순위 200 : 정보 :

• 백업 압축 기본값 꺼짐-압축되지 않은 전체 백업이 최근에 발생했으며 서버 수준에서 백업 압축이 설정되지 않았습니다. 백업 압축은 Standard Edition에서도 SQL Server 2008R2 이상에 포함되어 있습니다. 임시 백업이 압축되도록 기본적으로 백업 압축을 설정하는 것이 좋습니다.

• 데이터 정렬이 Latin1_General_CS_AS FINP 인 경우-사용자 데이터베이스와 tempdb의 데이터 정렬 차이로 인해 특히 문자열 값을 비교할 때 충돌이 발생할 수 있습니다

• 데이터 정렬은 SQL_Latin1_General_CP1_CI_AS입니다. 사용자 데이터베이스와 tempdb의 데이터 정렬 차이로 인해 특히 문자열 값을 비교할 때 충돌이 발생할 수 있습니다

  • 데모 77

  • PROD77

• 연결된 서버 구성-BWIN2 \ INFOR이 연결된 서버로 구성되어 있습니다. sa를 연결하면 보안 구성을 점검하십시오.이를 조회하는 사용자는 관리자 레벨 권한을 갖기 때문입니다.

우선 순위 200 : 모니터링 :

• 실패 이메일이없는 에이전트 작업

  • syspolicy_purge_history 작업이 실패한 경우 운영자에게 알리도록 설정되지 않았습니다.

  • upd_durchpreis_monatl 작업이 실패한 경우 운영자에게 알리도록 설정되지 않았습니다.

  • upd_fertmengen_woche 작업이 실패한 경우 운영자에게 알리도록 설정되지 않았습니다.

  • upd_liegezeit_monatl 작업이 실패한 경우 운영자에게 알리도록 설정되지 않았습니다.

  • upd_vertreter_diff 작업이 실패한 경우 운영자에게 알리도록 설정되지 않았습니다.

  • UPDATE_CONNECT_IK 작업이 실패한 경우 운영자에게 알리도록 설정되지 않았습니다.

  • Wartung.Cleanup 작업이 실패한 경우 운영자에게 알리도록 설정되지 않았습니다.

  • Wartung.DBCC Check DB 작업이 실패한 경우 운영자에게 알리도록 설정되지 않았습니다.

  • Wartung.Index Neuersertellen 작업이 실패한 경우 운영자에게 알리도록 설정되지 않았습니다.

  • Wartung.Statistiken aktualisieren 작업이 실패한 경우 운영자에게 알리도록 설정되지 않았습니다.

  • Wartung.Transactionlog 백업 작업이 실패한 경우 운영자에게 알리도록 설정되지 않았습니다.

  • Wartung.Vollbackup SystemDB 작업이 실패한 경우 운영자에게 알리도록 설정되지 않았습니다.

  • Wartung.Vollbackup UserDB 작업이 실패한 경우 운영자에게 알리도록 설정되지 않았습니다.

• 손상에 대한 경고 없음-오류 823, 824 및 825에 대해 SQL Server 에이전트 경고가 없습니다.이 세 가지 오류는 초기 하드웨어 오류에 대한 알림을 제공 할 수 있습니다. 그것들을 사용하면 많은 비탄을 예방할 수 있습니다.

• Sev 19-25에 대한 경고 없음-심각도 수준 19에서 25에 대해 SQL Server 에이전트 경고가 없습니다. 이는 매우 심각한 SQL Server 오류입니다. 이러한 상황이 발생하면 오류를 더 빨리 복구 할 수 있습니다.

• 모든 경고가 구성되지는 않음-모든 SQL Server 에이전트 경고가 구성되지 않았습니다. 모니터링 시스템이 손상되기 전에도 손상, 작업 실패 또는 주요 중단을 알리는 무료의 쉬운 방법입니다.

우선 순위 200 : 비 기본 서버 구성 :

• 에이전트 XP-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.

• 데이터베이스 메일 XP-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.

• 기본 전체 텍스트 언어-이 sp_configure 옵션이 변경되었습니다. 기본값은 1033이며 1031로 설정되었습니다.

• 기본 언어-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.

• 파일 스트림 액세스 수준-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.

• max degree of parallelism-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 4로 설정되었습니다.

• max server memory (MB)-이 sp_configure 옵션이 변경되었습니다. 기본값은 2147483647이며 115000으로 설정되었습니다.

• 최소 서버 메모리 (MB)-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 10000으로 설정되었습니다.

• 원격 관리자 연결-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.

우선 순위 200 : 성능 :

• 병렬 처리 비용 임계 값-기본값 인 5로 설정하십시오. 이 sp_configure 설정을 변경하면 CXPACKET 대기 시간이 줄어 듭니다.

• 스냅 샷 백업 발생-지난 2 주 동안 9 개의 스냅 샷 모양 백업이 발생하여 IO가 정지되고 있음을 나타냅니다.

우선 순위 210 : 비 기본 데이터베이스 구성 :

• 커밋 된 스냅 샷 격리 읽기 사용-이 데이터베이스 설정이 기본값이 아닙니다.

  • D3PR

  • 핀

• 재귀 트리거 사용-이 데이터베이스 설정이 기본값이 아닙니다.

  • 데모 77

  • PROD77

• 스냅 샷 격리 사용 FINP-이 데이터베이스 설정은 기본값이 아닙니다.

우선 순위 240 : 대기 통계 :

• 1-ASYNC_NETWORK_IO-225.9 시간의 대기, 시간당 143.5 분의 평균 대기 시간, 0.2 % 신호 대기, 2146022 대기 작업, 378.9ms 평균 대기 시간.

• 2-CXPACKET-43.1 대기 시간, 27.4 분 평균 대기 시간, 1.5 % 신호 대기, 32608391 대기 작업, 4.8ms 평균 대기 시간.

우선 순위 250 : 정보 제공 :

• SQL Server가 NT 서비스 계정으로 실행 중

  • NT Service \ MSSQL $ INFOR로 실행 중입니다. 대신 Active Directory 서비스 계정이 있었으면합니다.

  • NT Service \ SQLAgent $ INFOR로 실행 중입니다. 대신 Active Directory 서비스 계정이 있었으면합니다.

우선 순위 250 : 서버 정보 :

• 기본 추적 내용-기본 추적은 2017 년 9 월 3 일 8:34 PM과 Okt 5 2017 12:50 PM 사이에 760 시간의 데이터를 보유합니다. 기본 추적 파일은 C : \ Program Files \ Microsoft SQL Server \ MSSQL13.INFOR \ MSSQL \ Log에 있습니다.

• 드라이브 C 공간-C 드라이브에서 21308.00MB 무료

• 드라이브 D 공간-D 드라이브에서 280008.00MB 무료
• E 드라이브 드라이브-E 드라이브에서 무료 281618.00MB

• 드라이브 F 공간-F 드라이브에서 60193.00MB 여유 공간

• 하드웨어-논리 프로세서 : 4. 실제 메모리 : 128GB.

• 하드웨어-NUMA 구성-노드 : 0 상태 : 온라인 온라인 스케줄러 : 4 오프라인 스케줄러 : 0 프로세서 그룹 : 0 메모리 노드 : 0 메모리 VAS 예약 GB : 281

• 서버 마지막 다시 시작-Okt 1 2017 2:21 PM

• 서버 이름-BWINPDB \ INFOR

• 서비스

  • 서비스 : SQL Server (INFOR)는 서비스 계정 NT Service \ MSSQL $ INFOR에서 실행됩니다. 마지막 시작 시간 : Okt 1 2017 2:22 PM. 시작 유형 : 자동, 현재 실행 중

  • 서비스 : SQL Server 에이전트 (INFOR)는 서비스 계정 NT Service \ SQLAgent $ INFOR에서 실행됩니다. 마지막 시작 시간 : 표시되지 않음. 시작 유형 : 자동, 현재 실행 중입니다.

• SQL Server 마지막 ​​다시 시작-Okt 1 2017 2:22 PM

• SQL Server 서비스-버전 : 13.0.4001.0. 패치 레벨 : SP1. 에디션 : Standard Edition (64 비트). AlwaysOn 사용 : 0. AlwaysOn 관리 상태 : 2

• 가상 서버-유형 : (하이퍼 바이저)

• Windows 버전-최신 버전의 Windows : Server 2012R2 시대, 버전 6.3을 실행 중입니다.

우선 순위 254 : 실행 일 :

• 함장의 일지 : 무엇인가를 별표로 표시 ...

편집하다:

vmware로 SQL Server를 설정하는 방법에 대한 모범 사례 가이드를 이미 연구 했으며이 백서에 따라 대부분 설정했습니다. 그러나 하이퍼 스레딩이 활성화되지 않고 NUMA가 vmware 호스트에서 활성화되지 않았습니다. SQL Server는 NUMA로 설정되어 있습니다.

편집하다:

병렬 처리에 대한 임계 값을 50으로 설정 한 후 RECONFIGURE를 발행했으며 MAXDOP 설정도 구성되지 않았습니다.

나는 또한 우리의 vmware 관리자와 확인했는데, 잘못 알고있는 것 같습니다. 우리의 CPU는 4.6GHz가 아닌 2.6GHz로 설정되어 있습니다. 위의 정보를 수정했습니다.

편집하다:

이 vmwarekb 및 guide 에 따라 일부 네트워크를 설정하려고했습니다 . 또한 VM에 4 개의 코어를 추가했습니다. CPU 사용량은 동일하게 유지되었습니다.

논의 된 바와 같이 이 질문을 마지막 시간을 , 최상위 대기는 ASYNC_NETWORK_IO입니다. SQL Server는 파이프의 다른 쪽 끝에서 컴퓨터가 다음 행의 쿼리 결과를 요약하기를 기다리고 있습니다.

sp_Blitz의 waits 통계 결과 에서이 정보를 얻었습니다 (붙여 줘서 감사합니다).

1-ASYNC_NETWORK_IO-225.9 시간의 대기, 시간당 143.5 분의 평균 대기 시간, 0.2 % 신호 대기, 2146022 대기 작업, 378.9ms 평균 대기 시간.

CPU 스레드 문제 해결을 진행하지 마십시오. 관련이 없습니다. 기본 대기 유형과 해당 대기 유형을 유발할 수있는 것들에 중점을 둡니다.

이 문제를 더 해결하려면 sp_WhoIsActive 또는 sp_BlitzFirst (면책 조항 : 저자 중 한 명)를 실행하십시오.이 두 가지 모두 현재 실행중인 쿼리를 나열합니다. 대기 정보 열을보고 ASYNC_NETWORK_IO를 기다리는 쿼리를 찾은 다음 실행중인 앱 및 서버를보십시오.

거기에서 시도해 볼 수 있습니다 :

• 해당 응용 프로그램 서버의 전원이 부족한지 확인 (예 : CPU에서 최대로 사용 중인지 또는 디스크로 페이징하는 등)
• 응용 프로그램 개발자와 협력하여 결과에 대해 행 단위로 처리 중인지 확인합니다 (SQL Server에서 다시 나오는 모든 행의 경우와 같이 응용 프로그램은 중단되고 다음 행의 결과를 요청하기 전에 일부 처리를 수행함).
• 응용 프로그램 개발자와 협력하여 적은 양의 데이터 (예 : 모든 데이터가 필요하지 않은 경우 적은 수의 행 또는 적은 열)를 선택하는 경우-사람들이 실수로 SELECT *를 수행하여 필요한 것보다 많은 데이터를 가져 오거나 요청하면 그들이 정말로 최고 1000 만 필요할 때 모든 행)

sp_WhoIsActive로 업데이트 -게시 한 sp_WhoIsActive 스크린 샷에서 ASYNC_NETWORK_IO를 기다리는 몇 가지 쿼리가 있습니다. 이에 대해서는 위의 지침을 참조하십시오.

나머지 쿼리에서 sp_WhoIsActive의 "상태"열을 살펴보십시오. 대부분 "잠자기"입니다. 그것은 그들이 전혀 작동하지 않는다는 것을 의미합니다-파이프의 다른 쪽 끝에있는 앱이 다음 명령을 보내기를 기다리고 있습니다. 트랜잭션이 열려 있지만 ( "open_tran_count"열 참조) SQL Server가 수면 트랜잭션 속도를 높이기 위해 할 수있는 일은 없습니다. 이 쿼리는 40 분 이상 열려 있습니다 (sp_WhoIsActive의 첫 번째 열입니다. 더 이상 아무 것도하지 않고 있습니다. 트랜잭션을 커밋하고 연결을 종료하도록해야합니다. 이것은 성능 조정 문제가 아닙니다.

우리가보고있는 모든 것은 앱을 기다리는 시나리오를 가리 킵니다.

내 자신의 질문에 답하십시오. ASYNC_NETWORK_IO는 실제로 실제 문제가 아니 었습니다. 지연 시간에 민감한 워크로드에 대해이 가이드를 따라 성능 문제를 해결했습니다.

vSphere VM에서 대기 시간에 민감한 워크로드의 성능 조정을위한 모범 사례

시스템에 적용한 설정을 여기에 노란색으로 표시했습니다.

가장 큰 영향을 미치는 설정은 numa 구성 및 대기 시간 민감도 를 높게 설정 한 것 입니다. 물리적 CPU 코어와 VM에 대한 RAM을 명시 적으로 할당 / 예약해야했습니다.

또한 VM에 더 많은 코어를 추가하여 이제 SQL Server 라이센스를 Standard에서 Enterprise로 업그레이드해야합니다.

Windows가 약 4.6Ghz CPU 코어의 클럭 속도를 2.6Ghz 로보 고하는 것 같습니다 ... CPU-Z와 같은 도구를 실행하여 실제로 실행중인 속도를 확인한 다음 전원 설정 변경을 살펴보십시오. Windows와 BIOS / 관리 OS 모두 코어를 느리게 조절하는 절전 설정을 비활성화합니다.