다음을 통해 공유

SQL 하이퍼스케일 성능 문제 해결 진단

  • 아티클

적용 대상:Azure SQL Database

하이퍼스케일 데이터베이스에서 성능 문제를 해결하려면 일반적인 SQL 성능 튜닝 방법론 이 성능 조사의 출발점입니다. 그러나 하이퍼스케일의 분산된 아키텍처를 고려할 때 추가적인 진단 데이터를 고려해야 할 수도 있습니다. 이 문서는 하이퍼스케일 전용 진단 데이터를 설명합니다.

로그 기록 속도 대기 시간 감소

Azure SQL Database의 모든 데이터베이스 및 탄력적 풀은 로그 속도 거버넌스통해 로그 생성 속도를 관리합니다. 하이퍼스케일에서 로그 속도 거버넌스 제한은 컴퓨팅 크기에 관계없이 105MB/s로 설정됩니다. 이 값은 primary_max_log_rate의 열에 노출됩니다.

복구 가능성 SLA를 유지하려면 주 컴퓨팅 복제본의 로그 생성 속도를 줄여야 하는 경우가 있습니다. 예를 들어, 이 문제는 로그 서비스에서 새 로그 레코드를 적용하는 데 페이지 서버나 다른 컴퓨팅 복제본이 크게 뒤처진 경우에 발생할 수 있습니다. 하이퍼스케일 구성 요소가 없는 경우 로그 속도 거버넌스 메커니즘을 사용하면 로그 생성 속도가 100MiB/s에 도달할 수 있습니다. 이는 모든 하이퍼스케일 컴퓨팅 크기에서 유효한 최대 로그 생성 속도입니다.

참고 항목

150MiB/s의 로그 생성 속도는 프리미엄 시리즈 및 프리미엄 시리즈 메모리 최적화를 위한 옵트인 미리 보기 기능으로 사용할 수 있습니다. 자세한 내용 및 150MiB/s에 옵트인하려면 블로그: 2024년 11월 하이퍼스케일 개선 사항참조하세요.

로그 속도가 감소하면 다음 대기 유형이 sys.dm_os_wait_stats에 나타납니다.

대기 유형 이유
RBIO_RG_STORAGE 페이지 서버에 의한 지연된 로그 처리
RBIO_RG_DESTAGE 장기 로그 스토리지에 의한 지연된 로그 사용
RBIO_RG_REPLICA HA 보조 복제본 또는 이름이 지정된 복제본의 지연된 로그 소비
RBIO_RG_GEOREPLICA 지리적 위치에 있는 보조 복제본의 로그 처리 지연
RBIO_RG_DESTAGE 로그 서비스에 의한 지연된 로그 소비
RBIO_RG_LOCALDESTAGE 로그 서비스에 의한 지연된 로그 소비
RBIO_RG_STORAGE_CHECKPOINT 데이터베이스 검사점 지연으로 인한 페이지 서버에서의 로그 처리 지연
RBIO_RG_MIGRATION_TARGET 역방향 마이그레이션 중 하이퍼스케일이 아닌 데이터베이스에 의한 지연된 로그 소비

sys.dm_hs_database_log_rate() DMF(동적 관리 함수)는 로그 속도 감소를 이해하는 데 도움이 되는 추가 세부 정보를 제공합니다(있는 경우). 예를 들어 로그 레코드를 적용하는 데 어떤 특정 보조 복제본이 있는지, 아직 적용되지 않은 트랜잭션 로그의 총 크기는 무엇인지 알 수 있습니다.

페이지 서버 읽기

컴퓨팅 복제본은 데이터베이스의 전체 복사본을 로컬에서 캐시하지 않습니다. 컴퓨팅 복제본에 대한 로컬 데이터는 가장 자주 액세스하는 데이터 페이지의 하위 집합을 포함하는 버퍼 풀(메모리) 및 RBPEX(로컬 복원 버퍼 풀 확장) 캐시에 저장됩니다. 이 로컬 SSD 캐시는 컴퓨팅 크기에 비례하여 크기가 조정됩니다. 반면에 각 페이지 서버에는 유지 관리되는 데이터베이스 부분에 대한 전체 SSD 캐시가 있습니다.

컴퓨팅 복제본에서 읽기 IO가 실행되면 데이터가 버퍼 풀 또는 로컬 SSD 캐시에 없는 경우 요청된 LSN(로그 시퀀스 번호) 페이지가 해당 페이지 서버에서 가져옵니다. 페이지 서버의 읽기는 원격이며 로컬 SSD 캐시의 읽기보다 느립니다. I/O 관련 성능 문제를 해결할 때는 상대적으로 느린 페이지 서버 읽기를 통해 수행된 IO 수를 알 수 있어야 합니다.

여러 DMV(동적 관리 뷰) 및 확장 이벤트에는 페이지 서버에서 원격 읽기 수를 지정하는 열과 필드가 있으며 이는 총 읽기와 비교할 수 있습니다. 또한 쿼리 저장소는 쿼리 런타임 통계에서 페이지 서버 읽기를 캡처합니다.

  • 보고서 페이지 서버 읽기에 대한 열은 실행 동적 관리 뷰(DMV) 및 카탈로그 뷰에서 사용할 수 있습니다.
  • 페이지 서버 읽기 필드는 다음과 같은 확장 이벤트에 있습니다.
    • sql_statement_completed
    • sp_statement_completed
    • sql_batch_completed
    • rpc_completed
    • scan_stopped
    • query_store_begin_persist_runtime_stat
    • query_store_execution_runtime_info
  • ActualPageServerReads / ActualPageServerReadAheads 특성은 런타임 통계를 포함하는 계획에 대한 쿼리 계획 XML에 있습니다. 예를 들어: 
    <RunTimeCountersPerThread Thread="8" ActualRows="90466461" [...] ActualPageServerReads="0" ActualPageServerReadAheads="5687297" ActualLobPageServerReads="0" ActualLobPageServerReadAheads="0" />

    팁

    쿼리 계획 속성 창에서 이러한 특성을 보려면 SSMS 18.3 이상이 필요합니다.

가상 파일 통계 및 IO 계정

Azure SQL Database에서 sys.dm_io_virtual_file_stats() DMF는 IOPS, 처리량 및 대기 시간과 같은 데이터베이스 I/O 통계를 모니터링하는 한 가지 방법입니다. 하이퍼스케일의 I/O 특성은 분산 아키텍처인해 다릅니다. 이 섹션에서는 이 DMF에서 볼 수 있는 읽기 및 쓰기 I/O에 초점을 맞춥니다. 하이퍼스케일에서 이 DMF에 표시되는 각 데이터 파일은 페이지 서버에 해당합니다. 또한 DMF는 컴퓨팅 복제본의 로컬 SSD 캐시 및 트랜잭션 로그에 대한 I/O 통계를 제공합니다.

로컬 SSD 캐시 사용

로컬 SSD 캐시는 데이터베이스 엔진이 쿼리를 처리하는 동일한 컴퓨팅 복제본에 있기 때문에 이 캐시에 대한 I/O는 페이지 서버에 대한 I/O보다 빠릅니다. 하이퍼스케일 데이터베이스 또는 엘라스틱 풀에서 특수 행 sys.dm_io_virtual_file_stats()은 로컬 SSD 캐시에 대한 I/O 통계를 보고합니다. 이 행에는 0 열과 database_id 열 모두에 대한 file_id 값이 있습니다. 예를 들어 아래 쿼리는 데이터베이스 시작 이후 로컬 SSD 캐시 I/O 통계를 반환합니다.

SELECT *
FROM sys.dm_io_virtual_file_stats(0, NULL);

로컬 SSD 캐시로부터의 읽기 비율이 다른 모든 데이터 파일의 총 읽기에 대해 나타내는 것이 로컬 SSD 캐시 적중 비율입니다. 이 메트릭은 RBPEX cache hit ratio DMV에서 사용할 수 있는 RBPEX cache hit ratio base 및 성능 카운터에서 제공됩니다.

데이터 읽기

  • 컴퓨팅 복제본의 데이터베이스 엔진에서 읽기를 실행하면 로컬 SSD 캐시 또는 페이지 서버에서 또는 여러 페이지를 읽는 경우 둘의 조합으로 제공될 수 있습니다.
  • 컴퓨팅 복제본이 특정 데이터 파일(예: file_id 1이 있는 파일)에서 일부 페이지를 읽을 때 이 데이터가 로컬 SSD 캐시에만 있는 경우 이 읽기에 대한 모든 IO는 file_id 0에 대해 고려됩니다. 해당 데이터의 일부가 로컬 SSD 캐시에 있고 일부 부분이 페이지 서버에 있는 경우 IO는 로컬 SSD 캐시에서 제공되는 파트에 대해 file_id 0으로 간주되며 페이지 서버에서 제공되는 부분은 해당 파일로 간주됩니다.
  • 컴퓨팅 복제본이 페이지 서버에 특정 LSN의 페이지를 요청할 때, 페이지 서버가 요청된 LSN에 도달하지 않았다면 페이지가 반환되기 전에 컴퓨팅 복제본의 읽기는 페이지 서버가 따라잡을 때까지 대기합니다. 컴퓨팅 복제본의 페이지 서버에서의 모든 읽기 작업에 대해, 해당 IO가 대기 중일 때 PAGEIOLATCH_* 대기 유형이 표시됩니다. 하이퍼스케일에서 이 대기 시간은 페이지 서버에서 요청된 페이지를 필요한 LSN에 맞추는 시간과 페이지를 페이지 서버에서 컴퓨팅 복제본으로 전송하는 데 필요한 시간을 모두 포함합니다.
  • 큰 읽기 작업, 예를 들어, 미리 읽기와 같은 경우는 보통 분산 수집 방식의 읽기를 사용하여 수행됩니다. 이렇게 하면 단일 읽기 IO로 최대 4MB를 읽을 수 있습니다. 그러나 읽는 데이터가 로컬 SSD 캐시에 있는 경우 버퍼 풀과 로컬 SSD 캐시는 항상 8KB 페이지를 사용하므로 이러한 읽기는 여러 개의 개별 8KB 읽기로 간주됩니다. 따라서 로컬 SSD 캐시에 대해 표시되는 읽기 IO 수가 엔진에서 수행하는 실제 IO 수보다 클 수 있습니다.

데이터 쓰기

  • 기본 컴퓨팅 복제본은 페이지 서버에 직접 쓰지 않습니다. 대신 로그 서비스의 로그 레코드가 해당 페이지 서버에서 재생됩니다.
  • 컴퓨팅 복제본의 쓰기는 주로 로컬 SSD 캐시(file_id 0)에 기록됩니다. 8KB보다 큰 쓰기의 경우, 즉 수집-쓰기사용하여 수행되는 쓰기의 경우 버퍼 풀과 로컬 SSD 캐시는 항상 8KB 페이지를 사용하기 때문에 각 쓰기 작업은 로컬 SSD 캐시에 대한 여러 8KB 개별 쓰기로 변환됩니다. 따라서 로컬 SSD 캐시에 대해 표시되는 쓰기 IO 수가 엔진에서 수행하는 실제 IO 수보다 클 수 있습니다.
  • 페이지 서버에 해당하는 file_id 0 이외의 데이터 파일도 쓰기를 표시할 수 있습니다. 하이퍼스케일에서는 컴퓨트 복제본은 페이지 서버에 직접 쓰지 않으므로 이러한 쓰기가 시뮬레이션됩니다. I/O 통계는 컴퓨팅 복제본에서 발생할 때 고려됩니다. file_id 0 이외의 데이터 파일에 대한 컴퓨팅 복제본에 표시되는 IOPS, 처리량 및 대기 시간은 페이지 서버에서 발생하는 쓰기의 실제 I/O 통계를 반영하지 않습니다.

로그 쓰기

  • 주 컴퓨팅 복제본에서 로그 쓰기가 sys.dm_io_virtual_file_stats() 2의 file_id에 기록됩니다.
  • AlwaysOn 가용성 그룹과 달리 트랜잭션이 주 컴퓨팅 복제본에서 커밋되는 경우 로그 레코드는 보조 복제본에서 확정되지 않습니다. 하이퍼스케일에서는 로그가 로그 서비스에서 안정화된 후, 보조 복제본에 비동기적으로 적용됩니다. 로그 쓰기는 실제로 보조 복제본에서 발생하지 않으므로 보조 복제본의 sys.dm_io_virtual_file_stats() 로그 IO를 트랜잭션 로그 I/O 통계로 사용하면 안 됩니다.

리소스 사용률 통계의 데이터 IO

하이퍼스케일이 아닌 데이터베이스에서 리소스 거버넌스 데이터 IOPS 제한과 관련된 데이터 파일에 대한 읽기 및 쓰기 IOPS가 결합되어 sys.dm_db_resource_stats 및 sys.resource_stats 뷰, avg_data_io_percent 열에 보고됩니다. 탄력적 풀에 해당하는 DMV는 sys.dm_elastic_pool_resource_stats 및 sys.elastic_pool_resource_stats입니다. 데이터베이스 및 탄력적 풀들에 대한 데이터 IO 백분율 Azure Monitor 메트릭으로 동일한 값이 보고됩니다.

하이퍼스케일 데이터베이스에서, 이러한 열과 메트릭은 컴퓨트 복제본에서만 로컬 SSD 저장소의 제한에 대한 데이터 IOPS 활용도를 보고합니다. 여기에는 로컬 SSD 캐시와 tempdb 데이터베이스에 대한 I/O가 포함됩니다. 이 열의 100% 값은 리소스 거버넌스가 로컬 스토리지 IOPS를 제한하고 있음을 나타냅니다. 성능 문제와 상관 관계가 있는 경우 워크로드를 조정하여 더 적은 IO를 생성하거나 컴퓨팅 크기를 늘려 최대 데이터 IOPS제한리소스 거버넌스를 늘입니다. 로컬 SSD 캐시 읽기 및 쓰기의 리소스 거버넌스의 경우 시스템은 데이터베이스 엔진에서 발급할 수 있는 더 큰 IO가 아닌 개별 8KB IO를 계산합니다.

페이지 서버의 데이터 IO는 리소스 사용률 보기나 Azure Monitor 메트릭에서는 보고되지 않지만, 앞서 설명한 것처럼 sys.dm_io_virtual_file_stats()에 보고됩니다.

관련 콘텐츠