Always On 가용성 그룹에서 로그 보내기 큐 문제 해결

아티클
03/29/2023

이 문서에서는 로그 보내기 큐와 관련된 문제에 대한 해결 방법을 제공합니다.

로그 보내기 큐란?

주 복제본(replica) 가용성 그룹 데이터베이스(예: INSERT, UPDATE및 DELETE)에 대한 변경 내용은 트랜잭션 로그에 기록되고 가용성 그룹 보조 복제본으로 전송됩니다. 로그 보내기 큐는 보조 복제본으로 전송되지 않은 주 데이터베이스의 로그 파일에 있는 로그 레코드 수를 정의합니다.

로그 보내기 큐의 증상 및 효과

로그 송신 큐는 모든 취약한 데이터를 저장합니다.

갑작스런 재해로 주 복제본(replica) 손실되고 이러한 변경 내용이 아직 도착하지 않은 보조 복제본(replica) 장애 조치(failover)하는 경우 이러한 변경 내용은 데이터베이스의 새 주 복제본(replica) 복사본에 표시되지 않습니다. 전체 데이터베이스 및 로그 백업을 실행할 때 저장되는 변경 내용은 제외됩니다.

로그 송신 큐가 증가하면 트랜잭션 로그 파일 증가가 발생합니다.

가용성 그룹에 정의된 데이터베이스의 경우 Microsoft SQL Server 아직 보조 복제본에 전달되지 않은 트랜잭션 로그의 모든 트랜잭션을 기본 복제본(replica) 유지해야 합니다. 로그 보내기 큐는 기본 복제본(replica) 기록된 변경 내용의 수량을 나타내며, 일반적인 로그 잘림 이벤트(예: 데이터베이스 로그 백업 중)에서 잘리지 않습니다. 크고 증가하는 로그 송신 큐는 데이터베이스 로그 파일을 호스트하는 드라이브의 여유 공간을 소진하거나 구성된 최대 트랜잭션 로그 파일 크기를 초과할 수 있습니다. 자세한 내용은 트랜잭션 로그가 큰 경우 오류 9002를 참조하세요.

다양한 진단 기능 보고서 가용성 그룹 로그 보내기 큐

SQL Server Management Studio Always On dashboard 로그 보내기 큐에 대해 보고합니다. 가용성 그룹이 비정상이라고 보고할 수 있습니다.

로그 보내기 큐에 대한 검사 방법

로그 보내기 큐는 데이터베이스별 측정값입니다. 기본 복제본(replica) Always On dashboard 사용하거나 주 또는 보조 복제본(replica) sys.dm_hadr_database_replica_states DMV(동적 관리 뷰)를 사용하여 이 값을 검사 수 있습니다. 성능 모니터 카운터는 보조 복제본(replica) 대한 로그 보내기 큐를 검사 데 사용됩니다.

다음 여러 섹션에서는 가용성 그룹 데이터베이스 로그 송신 큐를 적극적으로 모니터링하는 방법을 제공합니다.

쿼리 sys.dm_hadr_database_replica_state

DMV는 sys.dm_hadr_database_replica_states 각 가용성 그룹 데이터베이스에 대한 행을 보고합니다. 해당 보고서의 한 열은 입니다 log_send_queue_size. 이 값은 로그 송신 큐 크기(KB)입니다. 다음 쿼리와 같은 쿼리를 설정하여 로그 송신 큐 크기의 추세를 모니터링할 수 있습니다. 쿼리는 기본 복제본(replica) 실행됩니다. 조건자를 is_local=0 사용하여 및 가 관련된 보조 복제본(replica) log_send_queue_sizelog_send_rate 대한 데이터를 보고합니다.

WHILE 1=1
BEGIN
  SELECT drcs.database_name, ars.role_desc, drs.log_send_queue_size, drs.log_send_rate,
ars.recovery_health_desc, ars.connected_state_desc, ars.operational_state_desc, ars.synchronization_health_desc, *
  FROM sys.dm_hadr_availability_replica_states ars JOIN sys.dm_hadr_database_replica_cluster_states drcs ON ars.replica_id=drcs.replica_id
  JOIN sys.dm_hadr_database_replica_states drs ON drcs.group_database_id=drs.group_database_id
  WHERE ars.role_desc='SECONDARY' AND drs.is_local=0
  waitfor delay '00:00:30'
END

출력의 모양은 다음과 같습니다.

Always On dashboard 로그 보내기 큐 검토

로그 보내기 큐를 검토하려면 다음 단계를 수행합니다.

SSMS 개체 탐색기 가용성 그룹을 마우스 오른쪽 단추로 클릭하여 SSMS(SQL Server Management Studio)에서 Always On dashboard 엽니다.
대시보드 표시를 선택합니다.

가용성 그룹 데이터베이스는 마지막으로 나열되며 데이터베이스에 보고된 일부 데이터가 있습니다. 로그 송신 큐 크기(KB) 및 로그 송신 속도(KB/초)는 기본적으로 나열되지 않지만 다음 단계의 스크린샷과 같이 이 보기에 추가할 수 있습니다.
이러한 열을 추가하려면 가용성 그룹 데이터베이스 열 머리글을 마우스 오른쪽 단추로 클릭하고 사용 가능한 열 목록에서 선택합니다.
로그 보내기 큐 크기를 추가하려면 다음 스크린샷에서 빨간색으로 강조 표시된 헤더를 마우스 오른쪽 단추로 클릭합니다.

기본적으로 Always On dashboard 60초마다 이 데이터를 자동으로 새로 고칩니다.

성능 모니터 로그 보내기 큐 검토

로그 송신 큐는 각 보조 복제본(replica) 데이터베이스와 관련이 있습니다. 따라서 가용성 그룹 데이터베이스의 로그 송신 큐를 검토하려면 다음 단계를 수행합니다.

보조 복제본(replica) 성능 모니터 엽니다.
추가(카운터) 단추를 선택합니다.
사용 가능한 카운터에서 SQLServer:Database 복제본 및 로그 송신 큐 카운터를 선택합니다.
인스턴스 목록 상자에서 로그 보내기 큐에 검사 가용성 그룹 데이터베이스를 선택합니다.
추가 및 확인을 선택합니다.

로그 보내기 큐가 증가하는 모양은 다음과 같습니다.

로그 보내기 큐 값 해석

이 섹션에서는 로그 보내기 큐 크기의 값을 해석하는 방법을 설명합니다.

로그 송신 큐가 나쁜 경우는 언제인가요? 얼마나 많은 로그 송신 큐를 허용해야 하나요?

로그 보내기 큐가 값 0을 보고하는 경우 이는 해당 보고서 당시 로그 송신 큐가 발생하지 않는다는 것을 의미합니다. 그러나 프로덕션 환경이 사용 중인 경우 정상 AlwaysOn 환경에서도 로그 보내기 큐가 0 이외의 값을 자주 보고하는 것을 관찰해야 합니다. 일반적인 프로덕션 중에는 이 값이 0과 0이 아닌 값 사이에서 변동하는 것을 관찰해야 합니다.

시간이 지남에 따라 로그 전송 큐가 증가하는 것을 관찰하는 경우 추가 조사가 보장됩니다. 이 추가 작업은 무언가가 변경되었음을 나타냅니다. 로그 송신 큐의 급격한 증가를 관찰하는 경우 다음 측정값이 문제 해결에 유용합니다.

로그 전송 속도(KB/초)(AlwaysOn dashboard)
sys.dm_hadr_database_replica_states (DMV)
데이터베이스 복제본::미러된 트랜잭션/초(성능 모니터)

로그 전송 속도 및 미러된 트랜잭션/초의 기준 속도 가져오기

정상 AlwaysOn 성능 중에 사용 중인 가용성 그룹 데이터베이스에 대한 로그 전송 속도 및 미러된 트랜잭션/초 값을 모니터링합니다. 일반적으로 바쁜 업무 시간에는 어떤 모습일까요? 대규모 트랜잭션이 시스템에서 더 높은 트랜잭션 처리량을 유도하는 유지 관리 기간 동안의 모양은 어떻게 됩니까? 로그 송신 큐 증가를 관찰할 때 이러한 값을 비교하여 변경된 내용을 확인할 수 있습니다. 워크로드가 평소보다 클 수 있습니다. 로그 전송 속도가 평소보다 작으면 이유를 확인하기 위해 추가 조사가 필요할 수 있습니다.

워크로드 볼륨이 중요합니다.

100만 행에 대한 문, 1테라바이트 테이블의 인덱스 다시 작성 또는 수백만 개의 행을 삽입하는 ETL 일괄 처리와 같은 UPDATE 대규모 워크로드가 있는 경우 즉시 또는 시간이 지남에 따라 일부 로그 전송 큐 증가가 예상되어야 합니다. 이는 가용성 그룹 데이터베이스에서 갑자기 많은 수의 변경이 수행될 때 예상됩니다.

로그 보내기 큐를 진단하는 방법

특정 가용성 그룹 데이터베이스에 대한 로그 보내기 큐를 식별한 후에는 다음 섹션에서 설명한 대로 문제의 가능한 여러 근본 원인에 대해 검사 합니다.

중요

의미 있는 대기 유형 출력의 경우 다음 조건을 모니터링할 때 이전 섹션에서 설명한 방법 중 하나를 사용하여 로그 보내기 큐의 증가를 검사.

시스템이 너무 바빠서

기본 복제본(replica) 워크로드가 시스템의 CPU를 오버로드하고 있는지 확인합니다. 로그 보내기 큐가 증가하는 경우 DMV를 sys.dm_os_schedulers 쿼리하고 를 모니터링합니다 high runnable_tasks_count. 이 개수는 당시 실행된 미해결 작업을 나타냅니다.

SELECT scheduler_address, scheduler_id, cpu_id, status, current_tasks_count, runnable_tasks_count, current_workers_count, active_workers_count
FROM sys.dm_os_schedulers

다음 표는 결과의 샘플입니다. 값이 증가하면 runnable_tasks_count 많은 수의 작업이 CPU 시간을 기다리고 있음을 나타냅니다.

scheduler_address	scheduler_id	cpu_id	상태	current_tasks_count	runnable_tasks_count	current_workers_count	active_workers_count
0x000002778D 200040	0	0	오프라인으로 표시	1	0	2	1
0x000002778D 220040	1	1	온라인 표시	108	12	115	107
0x000002778D 240040	2	2	온라인 표시	113	2	123	113
0x000002778D 260040	3	3	온라인 표시	105	11	116	105
0x000002778D 480040	4	4	온라인 표시	108	15	117	108
0x000002778D 4A0040	5	5	온라인 표시	100	25	110	99
0x000002778D 4C0040	6	6	온라인 표시	105	23	113	105
0x000002778D 4E0040	7	7	표시	109	25	116	109
0x000002778D 700040	8	8	온라인 표시	98	10	112	98
0x000002778D 720040	9	9	온라인 표시	114	1	130	114
0x000002778D 740040	10	10	온라인 표시	110	25	120	110
0x000002778D 760040	11	11	온라인 표시	83	8	93	83
0x000002778D A00040	12	12	온라인 표시	104	4	117	104
0x000002778D A20040	13	13	온라인 표시	108	32	118	108
0x000002778D A40040	14	14	온라인 표시	102	12	113	102
0x000002778D A60040	15	15	온라인 표시	104	16	116	103

해결 방법: 높은 runnable_task_count를 검색하는 경우 시스템의 워크로드를 줄이거나 시스템에서 사용할 수 있는 CPU 수를 늘입니다.

네트워크 대기 시간

이 조건은 보조 복제본(replica) 주 복제본(replica) 물리적으로 원격인 경우에 특히 일반적입니다. 다중 사이트 가용성 그룹을 사용하면 고객이 재해 복구 및 보고를 위해 여러 사이트에 비즈니스 데이터 복사본을 배포할 수 있습니다. 이렇게 하면 원격 위치에서 프로덕션 데이터 복사본에 거의 실시간으로 변경 내용을 사용할 수 있습니다.

보조 복제본(replica) 주 복제본(replica) 호스트되는 경우 네트워크 대기 시간 및 주 복제본(replica) 데이터베이스에서 생성되는 만큼 빠르게 원격 보조 데이터베이스에 변경 내용을 보낼 수 없기 때문에 로그 보내기 큐가 발생할 수 있습니다.

중요

SQL Server 단일 연결을 사용하여 주 복제본에서 보조 복제본으로 변경 내용을 동기화합니다. 따라서 보조 복제본(replica) 원격인 경우 파이프의 너비는 SQL Server 보낼 수 있는 데이터의 양에 영향을 미치지 않습니다. 대신 이 크기는 파이프의 네트워크 대기 시간(연결 속도)에 따라 달라집니다.

네트워크 대기 시간 테스트

흐름 제어 설정이 네트워크 대기 시간에 기여하는지 확인

Microsoft SQL Server 가용성 그룹은 흐름 제어 게이트를 사용하여 모든 가용성 복제본에서 네트워크 리소스, 메모리 및 기타 리소스를 과도하게 사용하지 않도록 합니다. 이러한 흐름 제어 게이트는 가용성 복제본의 동기화 상태에 영향을 주지 않습니다. 그러나 RPO를 비롯한 가용성 데이터베이스의 전반적인 성능에 영향을 줄 수 있습니다.

이후 버전의 SQL Server 흐름 제어가 입력되는 임계값을 변경합니다. 이렇게 하면 흐름 제어가 로그 송신 큐와 같은 증상에 미치는 영향을 완화하는 데 도움이 될 수 있습니다. 흐름 제어 및 흐름 제어 임계값 변경 기록에 대한 자세한 내용은 흐름 제어 게이트를 참조하세요.

성능 모니터 사용하여 기본 복제본(replica) 데이터를 캡처하여 흐름 제어를 모니터링할 수 있습니다. 데이터베이스 흐름 제어를 모니터링하려면 SQLServer:Database Replica 카운터를 추가하고 데이터베이스 흐름 제어 지연 및 데이터베이스 흐름 제어/초 카운터를 선택합니다. 인스턴스 대화 상자에서 데이터베이스 흐름 제어에 검사 가용성 그룹 데이터베이스를 선택합니다. 흐름 제어에 복제본(replica) 가용성을 검색하고 모니터링하려면 SQLServer:Availability Replica 카운터를 추가하고 흐름 제어 시간(ms/초) 및 흐름 제어/초 카운터를 선택합니다.
Windows 다시 시작이 네트워크 대기 시간에 영향을 미치는지 확인

정체 Windows 다시 시작 TCP 설정을 True로 설정하여 로그 보내기 큐를 발생시키는 네트워크 성능 문제를 트리거할 수 있습니다. 이는 Windows Server 2016 기본 설정이었습니다. 로그 보내기 큐가 관찰되는 가용성 그룹 복제본을 호스트하는 Windows 서버에서 정체 창 다시 시작 이 False 로 설정되어 있는지 확인합니다.

PS C:\WINDOWS\system32> Get-NetTCPSetting | Select SettingName, CwndRestart

TCP 정체 Windows 다시 시작 속성을 False로 설정하는 방법에 대한 자세한 내용은 Set-NetTCPSetting(NetTCPIP)을 참조하세요.

동기화 프로세스에 대한 자세한 내용은 Always On 가용성 그룹에 대한 성능 모니터링을 참조하세요. 또한 이 문서에서는 몇 가지 주요 메트릭을 계산하는 방법을 보여 줍니다. 일반적인 성능 문제 해결 시나리오에 대한 링크를 제공합니다.

ping을 사용하여 대기 시간 샘플 가져오기

node1(기본 복제본(replica))의 명령줄에서 ping node2(보조 복제본(replica)):

C:\Users\customer>ping node2
Pinging node2.customer.corp.company.com [<ip address>] with 32 bytes of data:
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=94ms
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=97ms
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=94ms
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=119ms

Ping statistics for 2<ip address>:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 94ms, Maximum = 119ms, Average = 101ms

독립 도구를 사용하여 기본에서 보조로 네트워크 처리량 테스트

NTttcp와 같은 도구를 사용하여 단일 연결을 사용하여 주 복제본과 보조 복제본 간의 네트워크 처리량을 독립적으로 검색합니다. 네트워크 대기 시간은 로그 송신 큐의 일반적인 원인입니다. 다음 단계에서는 NTttcp와 같은 독립적인 도구를 사용하여 네트워크 처리량을 측정하는 방법을 보여 있습니다.

중요

SQL Server 단일 연결을 사용하여 기본 복제본(replica) 보조 복제본(replica) 변경 내용을 보냅니다. 다음 섹션에서는 단일 연결(SQL Server 같은 방식으로)을 사용하여 처리량을 정확하게 비교하도록 NTttcp를 구성하고 실행합니다.

Github - microsoft/ntttcp에서 NTttcp를 다운로드할 수 있습니다.

NTttcp를 실행하려면 다음 단계를 수행합니다.
1. 도구를 다운로드하여 기본 및 보조 SQL Server 기반 서버에 복사합니다.
2. 보조 복제본(replica) 서버에서 관리자 권한 명령 프롬프트 창을 열고 디렉터리를 NTttcp 도구 폴더로 변경한 다음 다음 명령을 실행합니다.
  
  ntttcp.exe -r -m 1,0,<secondaryipaddress>-a 16 -t 60
  
  참고
  
  이 명령에서 는 <secondaryipaddress> 보조 복제본(replica) 서버의 실제 IP 주소에 대한 자리 표시자입니다.
3. 주 복제본(replica) 서버에서 관리자 권한 명령 프롬프트 창을 열고 디렉터리를 NTttcp 도구 폴더로 변경한 다음 보조 복제본(replica) 서버의 실제 IP 주소를 다시 지정하여 다음 명령을 실행합니다.
  
  ntttcp.exe -s -m 1,0,<secondaryipaddress>-a 16 -t 60
  
  다음 스크린샷은 보조 및 주 복제본에서 실행되는 NTttcp를 보여 줍니다. 네트워크 대기 시간으로 인해 이 도구는 739KB/초의 데이터만 보낼 수 있습니다. SQL Server 보낼 수 있을 것으로 예상할 수 있습니다.
  
  보조 복제본의 NTttcp
  
  주 복제본의 NTttcp

성능 모니터 카운터 검토

NTttcp에서 보고하는 내용을 확인합니다. 주 복제본(replica) SQL Server 대규모 트랜잭션이 실행됩니다. 기본 복제본(replica) 성능 모니터 시작한 후 네트워크 인터페이스::Bytes Sent/sec 카운터를 추가합니다. 이 카운터는 기본 복제본(replica) 약 777KB/초의 데이터를 보낼 수 있음을 확인합니다. 이는 NTttcp 테스트에서 보고한 739KB/초 값과 유사합니다.

또한 주 복제본(replica) SQL Server::D atabases::Log Bytes Flushed/sec 값을 보조 복제본(replica) 동일한 데이터베이스에 대해 SQL Server::D atabase Replica::Log Bytes Received/sec와 비교하는 것도 유용합니다. 평균적으로 "agdb" 데이터베이스에서 생성된 변경 내용의 최대 20MB/초가 관찰됩니다. 그러나 보조 복제본(replica) 평균적으로 5.4MB의 변경 내용만 수신합니다. 이로 인해 아직 보조 복제본(replica) 전송되지 않은 데이터베이스 트랜잭션 로그의 미해결 변경 내용의 기본 복제본(replica) 로그 보내기 큐가 발생합니다.

"agdb" 데이터베이스에 대한 주 복제본 로그 바이트 Flushed/초

데이터베이스 agdb에 대한 보조 복제본 로그 바이트 수신/초

다음을 통해 공유