다음을 통해 공유


느린 것으로 보이는 전체 SQL Server 또는 데이터베이스 애플리케이션 문제 해결

적용 대상: SQL Server

SQL Server 인스턴스 또는 특정 애플리케이션에 대해 쿼리를 실행하면 모든 쿼리가 느려집니다. 이 문제를 해결하려면 다음 단계를 수행합니다.

1단계: 애플리케이션 문제 해결

애플리케이션 계층을 확인합니다. 애플리케이션에서 쿼리를 가져와서 SQL Server 인스턴스에서 수동으로 실행하고 실행 방법을 확인합니다. 이러한 방식으로 여러 쿼리를 테스트합니다. SQL Server 인스턴스에서 쿼리가 더 빠른 경우 애플리케이션 또는 애플리케이션 서버 계층에서 문제가 발생할 수 있습니다.

참고 항목

데이터베이스 애플리케이션과 SSMS 간의 쿼리 성능 차이를 염두에 두어야 합니다.

애플리케이션이 다른 서버에서 실행되는 경우 애플리케이션 서버의 성능을 확인합니다(2단계: 문제 해결을 위한 OS 문제 해결 참조). 애플리케이션 개발 팀에 참여하여 애플리케이션 관련 문제를 확인해야 할 수 있습니다.

2단계: OS 문제 해결

SQL Server가 실행 중인 운영 체제가 느리게 응답하는지 확인합니다. 예를 들어 마우스가 느리게 이동하거나, 창이 오랫동안 응답하지 않거나, 서버에 대한 원격 데스크톱 액세스가 느리거나, 서버의 공유에 연결하는 속도가 느립니다.

이 문제는 다른 서비스 또는 애플리케이션으로 인해 발생할 수 있습니다. Perfmon을 사용하여 문제를 해결합니다.

다른 OS 성능 문제는 Windows Server 성능 문제 해결 설명서를 참조 하세요.

일반적인 문제는 다음과 같습니다.

이 문제는 시스템에서 실행되는 다른 애플리케이션, OS 또는 드라이버로 인해 발생할 수 있습니다.

이 문제를 해결하려면 작업 관리자, 성능 모니터 또는 리소스 모니터를 사용하여 이 문제를 식별합니다. 자세한 내용은 높은 CPU 사용량 문제 해결 지침을 참조 하세요.

3단계: 네트워크 문제 해결

네트워크 계층에 문제가 있어 애플리케이션과 SQL Server 간의 통신 속도가 느려질 수 있습니다. 이 문제를 해결하려면 다음 방법을 사용합니다.

  • 한 가지 증상은 SQL Server 쪽에서 대기하는 것일 ASYNC_NETWORK_IO 수 있습니다. 자세한 내용은 ASYNC_NETWORK_IO 대기 유형으로 인해 발생하는 느린 쿼리 문제 해결을 참조하세요.

  • 네트워크 관리자와 협력하여 네트워크 문제(방화벽, 라우팅 등)를 확인합니다.

  • 네트워크 추적수집하고 네트워크 재설정 및 재전송 이벤트를 확인합니다. 문제 해결 아이디어는 간헐적 또는 주기적 네트워크 문제를 참조하세요.

  • Perfmon 카운터를 사용하도록 설정하여 NIC(네트워크 인터페이스 수준)에서 네트워크 성능을 확인합니다. 삭제된 패킷과 오류 패킷은 0개여야 합니다. 네트워크 인터페이스 대역폭을 확인합니다.

    • 네트워크 인터페이스\삭제된 패킷 수신됨
    • 네트워크 인터페이스\패킷이 오류를 수신했습니다.
    • 네트워크 인터페이스\패킷 아웃바운드 삭제됨
    • 네트워크 인터페이스\패킷 아웃바운드 오류
    • Network Interface\Bytes Total/Sec
    • 네트워크 인터페이스\현재 대역폭

4단계: SQL Server의 높은 CPU 사용량 문제 해결

시스템에서 CPU 집약적 쿼리를 실행하는 경우 다른 쿼리에 CPU 용량이 부족해질 수 있습니다. 그러나 쿼리에서 발생하는 높은 CPU 사용량은 쿼리를 최적화해야 한다는 표시일 수 있습니다. 다음 단계에 따라 문제를 해결합니다.

  1. 먼저 SQL Server에서 높은 CPU 사용량(Perfmon 카운터 사용)을 발생시키는지 확인합니다.
  2. CPU 사용량에 영향을 주는 쿼리를 식별합니다.
  3. 통계를 업데이트합니다.
  4. 누락된 인덱스를 추가합니다.
  5. 매개 변수에 민감한 이슈를 조사하고 해결합니다.
  6. SARGability 문제를 조사하고 해결합니다.
  7. 무거운 추적을 사용하지 않도록 설정합니다.
  8. 스핀 잠금 경합을 수정 SOS_CACHESTORE 합니다.
  9. 가상 머신을 구성합니다.
  10. CPU를 더 추가하여 시스템을 강화합니다.

자세한 문제 해결 단계는 SQL Server에서 CPU 사용량이 많은 문제 해결을 참조 하세요.

5단계: SQL Server에서 과도한 I/O로 인해 속도가 느려지는 문제 해결

SQL Server 워크로드의 전반적인 속도가 느려지는 또 다른 일반적인 이유는 I/O 문제입니다. I/O 속도 저하는 시스템의 대부분의 또는 모든 쿼리에 영향을 줄 수 있습니다. 다음 방법을 사용하여 문제를 해결합니다.

  • 하드웨어 문제를 확인합니다.

    • SAN 구성이 잘못되었습니다(스위치, 케이블, HBA, 스토리지).
    • I/O 용량을 초과했습니다(백 엔드 스토리지뿐만 아니라 전체 SAN 네트워크 전체에서 불균형, SAN을 공유하는 모든 서버의 I/O 처리량 확인).
    • 드라이버 또는 펌웨어 문제 또는 업데이트
  • I/O를 많이 발생시키고 I/O 요청으로 디스크 볼륨을 포화시키는 최적이 아니면 SQL Server 쿼리를 확인합니다.

    • 많은 수의 논리적 읽기(또는 쓰기)를 유발하는 쿼리를 찾고 해당 쿼리를 조정하여 적절한 인덱스를 사용하는 디스크 I/O를 최소화하는 것이 첫 번째 단계입니다.
    • 최상의 계획을 선택할 수 있는 충분한 정보를 쿼리 최적화 프로그램에서 제공하므로 통계를 업데이트된 상태로 유지합니다.
    • 쿼리 및 테이블을 다시 디자인하면 향상된 I/O에 도움이 될 수 있습니다.
  • 필터 드라이버: 파일 시스템 필터 드라이버가 많은 I/O 트래픽을 처리하는 경우 SQL Server I/O 응답에 심각한 영향을 미칠 수 있습니다.

    • 바이러스 백신 검사에서 데이터 폴더를 제외하고 I/O 성능에 영향을 주지 않도록 소프트웨어 공급업체에서 필터 드라이버 문제를 수정했습니다.
  • 다른 애플리케이션: SQL Server를 사용하는 동일한 컴퓨터의 다른 애플리케이션은 과도한 읽기 또는 쓰기 요청으로 I/O 경로를 포화시킬 수 있습니다. 이 경우 I/O 하위 시스템이 용량 제한을 초과하여 SQL Server의 I/O 속도가 느려질 수 있습니다. 애플리케이션을 식별하고 튜닝하거나 다른 곳으로 이동하여 I/O 스택에 미치는 영향을 제거합니다. 이 문제는 다른 컴퓨터에서 실행되지만 이 SQL Server 컴퓨터와 동일한 SAN을 공유하는 애플리케이션으로 인해 발생할 수도 있습니다. SAN 관리자와 협력하여 I/O 트래픽의 균형을 조정합니다(하드웨어 문제 확인 참조).

SQL Server와 관련된 I/O 관련 문제에 대한 자세한 해결은 I/O 문제로 인한 느린 SQL Server 성능 문제 해결을 참조하세요.

6단계: 메모리 문제 해결

쿼리가 메모리 부여() 또는 컴파일 메모리(RESOURCE_SEMAPHORERESOURCE_SEMAPHORE_QUERY_COMPILE)를 기다리는 경우 시스템 전체 또는 SQL Server 내부의 메모리가 부족하면 속도가 느려질 수 있습니다. 다음 방법을 사용하여 문제를 해결합니다.

  • Perfmon 카운터를 사용하여 OS 수준에서 외부 메모리를 확인합니다.

    • Memory\Available MBytes
    • Process(*)\Working Set (모든 인스턴스)
    • Process(*)\Private Bytes (모든 인스턴스)
  • 내부 메모리 압력의 경우 SQL Server 쿼리를 사용하여 sys.dm_os_memory_clerks 쿼리하거나 DBCC MEMORYSTATUS를 사용합니다.

  • SQL Server 오류 로그에서 701 오류를 확인합니다.

자세한 문제 해결 단계는 SQL Server의 메모리 부족 또는 메모리 부족 문제 해결을 참조 하세요.

7단계: 차단 문제 해결

잠금 획득은 데이터베이스 시스템의 리소스를 보호하는 데 사용됩니다. 잠금을 오랫동안 획득하고 다른 세션이 해당 잠금을 기다리는 경우 차단 시나리오에 직면하게 됩니다.

SQL Server와 같은 데이터베이스 시스템에서는 항상 짧은 차단이 발생합니다. 그러나 특히 대부분의 또는 모든 쿼리가 잠금을 기다리는 경우 차단이 길어지면 전체 서버가 응답하지 않는 것으로 인식될 수 있습니다.

다음 단계를 사용하여 문제를 해결합니다.

  1. sys.dm_exec_requests DMV 출력의 열 blocking_session_id 또는 저장 프로시저 출력의 열을 BlkBy sp_who2 확인하여 헤드 차단 세션을 식별합니다.

  2. 헤드 차단 체인이 실행하는 쿼리(장기간 잠금을 보유하는 항목)를 찾습니다.

    헤드 차단 세션에서 적극적으로 실행되는 쿼리가 없는 경우 애플리케이션 문제로 인해 분리된 트랜잭션이 있을 수 있습니다.

  3. 헤드 차단 쿼리를 다시 디자인하거나 조정하여 더 빠르게 실행하거나 트랜잭션 내의 쿼리 수를 줄입니다.

  4. 쿼리에 사용되는 트랜잭션 격리를 검사하고 조정합니다.

차단 시나리오에 대한 자세한 문제 해결은 SQL Server 차단 문제 이해 및 해결을 참조 하세요.

8단계: 스케줄러 문제 해결(비수익, 교착 상태 스케줄러, 생성되지 않는 IOCP 수신기, 리소스 모니터)

SQL Server는 협조적 일정 메커니즘(Schedulers)을 사용하여 CPU에서 예약하기 위해 OS에 스레드를 노출합니다. SQL 스케줄러와 관련된 문제가 있는 경우 SQL Server 스레드는 쿼리, 로그인, 로그아웃 등의 처리를 중지할 수 있습니다. 결과적으로 SQL Server는 영향을 받는 스케줄러 수에 따라 부분적으로 또는 완전히 응답하지 않는 것처럼 보일 수 있습니다. 스케줄러 문제는 제품 버그, 외부 및 필터 드라이버 및 하드웨어 문제를 비롯한 다양한 문제로 인해 발생할 수 있습니다.

다음 단계에 따라 이러한 문제를 해결합니다.

  1. SQL Server 오류 로그에서 보고된 SQL Server 응답 부족 시 다음과 같은 오류가 있는지 확인합니다.

    • ***********************************************
      *
      * BEGIN STACK DUMP:
      * 03/10/22 21:16:35 spid 22548
      *
      * Non-yielding Scheduler
      *
      ***********************************************
      
    • **********************************************
      *
      * BEGIN STACK DUMP:
      * 03/25/22 08:50:29 spid 355
      *
      * Deadlocked Schedulers
      *
      * ********************************************
      
      
    • * *******************************************************************************                                
      *                                                                                                                
      * BEGIN STACK DUMP:                                                                                              
      * 09/07/22 23:01:04 spid 0                                                                                     
      *                                                                                                                
      * Non-yielding IOCP Listener                                                                                     
      *                                                                                                                
      * *******************************************************************************   
      
    • * ********************************************
      *
      * BEGIN STACK DUMP:
      * 07/25/22 11:44:21 spid 2013
      *
      * Non-yielding Resource Monitor
      *
      * ********************************************
      
  2. 이러한 오류 중 하나를 찾으면 사용 중인 SQL Server의 CU(버전 누적 업데이트)를 식별합니다. 현재 CU 이후 배송된 CU에 고정된 문제가 있는지 확인합니다. SQL Server 수정 사항은 현재 지원되는 SQL Server 버전에 사용할 수 있는 최신 업데이트를 참조 하세요. 자세한 수정 목록을 보려면 이 Excel 파일을 다운로드할 수 있습니다.

  3. SQL Server 예약 및 생성 문제 해결을 사용하여 더 많은 아이디어를 얻을 수 있습니다.

  4. 교착 상태 스케줄러로 이어질 수 있는 과도한 차단 시나리오 또는 대규모 병렬 처리 쿼리를 확인합니다. 자세한 내용은 교착 상태 스케줄러의 타오를 참조 하세요.

  5. 생성되지 않는 IOCP 수신기의 경우 시스템이 메모리가 부족하고 SQL Server가 페이징되고 있는지 확인합니다. 또 다른 이유는 바이러스 백신 또는 침입 방지 소프트웨어가 I/O API 호출을 가로채 스레드 작업을 느리게 하는 것일 수 있습니다. 자세한 내용은 특정 모듈 또는 필터 드라이버가 로드될 때 IOCP 수신기가 실제로 수신 대기 중입니까?성능 및 일관성 문제를 참조하세요.

  6. 리소스 모니터 문제의 경우 경우에 따라 이 문제와 관련이 없을 수도 있습니다. 자세한 내용은 리소스 모니터가 SQL Server를 실행하는 서버에서 생성하지 않는 조건을 입력하는 것을 참조 하세요.

  7. 이러한 리소스가 도움이 되지 않는 경우 \LOG 하위 디렉터리에서 만든 메모리 덤프를 찾고 분석을 위해 메모리 덤프를 업로드하여 Microsoft CSS에서 지원 티켓을 엽니다.

9단계: 리소스 집약적 프로파일러 또는 XEvent 추적 찾기

활성 확장 이벤트 또는 SQL Server Profiler 추적, 특히 텍스트 열(데이터베이스 이름, 로그인 이름, 쿼리 텍스트 등)을 필터링하는 추적을 찾습니다. 가능하면 추적을 사용하지 않도록 설정하고 쿼리 성능이 향상되는지 확인합니다. 선택한 이벤트에 따라 각 스레드는 추가 CPU를 소비하여 전반적인 속도가 느려질 수 있습니다. 확장 이벤트에 대한 활성 추적을 식별하려면 sys.dm_xe_sessions 및 Profiler 추적을 참조하세요. sys.traces를 참조하세요.

SELECT * FROM sys.dm_xe_sessions
GO
SELECT * FROM sys.traces