(원래 DBA.StackExchange.com에 게시되었지만 폐쇄되었으므로 여기에서 더 관련성이 높기를 바랍니다.)
Alexander and the Terrible, Horrible, No Good, Very Bad...백업.
설정:
온프레미스에 있어요SQL 서버 2016 스탠다드 에디션에서 실행 중인 인스턴스가상 기기VMWare에서.
@@버전:
Windows Server 2016 Datacenter 10.0(빌드 14393: ) (하이퍼바이저)
서버 자체가 현재 할당되어 있습니다가상 프로세서 8개, 가지다32GB 메모리, 그리고 모든디스크는 NVMe입니다.돌아다니는 것1GB/초의 I/O. 데이터베이스 자체는 G: 드라이브에 있으며 백업은 P: 드라이브에 별도로 저장됩니다. 모든 데이터베이스의 총 크기는 약 500GB입니다(백업 파일 자체로 압축되기 전).
유지 관리 계획은 밤에 한 번(오후 10시 30분경) 실행되어 서버의 모든 데이터베이스에 대해 전체 백업을 수행합니다. 서버에서는 특별한 다른 어떤 것도 실행되지 않으며, 특히 그 시간에 실행되는 다른 어떤 것도 없습니다. 서버의 전원 계획은 "균형"으로 설정되어 있습니다. (그리고 "다음 시간 이후 하드 디스크 끄기"는 절대 끄지 말라고 하는 0분으로 설정되어 있습니다.)
무슨 일이에요:
지난 1년 동안 유지 관리 계획 작업의 총 실행 시간은 약 15분 정도 걸렸습니다.분완료할 총계입니다. 지난 주부터 소요 시간이 40배 정도, 약 15배로 급증했습니다.시간완료합니다.
유지 관리 계획이 느려진 당일에 변경된 것으로 알고 있는 유일한 것은 유지 관리 계획이 실행되기 전에 컴퓨터에 다음 Windows 업데이트가 설치되었다는 것입니다.
또한 동일한 Windows 업데이트를 수행한 후 이후에도 백업 속도가 느려지는 다른 VM에 유사하게 프로비저닝된 또 다른 SQL Server 인스턴스가 있습니다. Windows 업데이트가 직접적인 원인이라고 생각하여 완전히 롤백했지만 어쨌든 백업 유지 관리 계획은 여전히 매우 느리게 실행됩니다. 이상하게도 특정 데이터베이스에 대한 백업 복원은 매우 빠르게 이루어지며 NVMe에서 거의 전체 1GB/초의 I/O를 사용합니다.
내가 시도한 것:
Adam Mechanic의 sp_whoisactive를 사용할 때 백업 프로세스의 마지막 대기 유형이 항상 디스크 성능 문제를 나타냄을 확인했습니다. 나는 항상 다음과 같은 유형을 보고 대기 BACKUPBUFFER합니다 .BACKUPIOASYNC_IO_COMPLETION
백업 중에 서버 자체의 리소스 모니터를 보면 디스크 I/O 섹션에 사용 중인 총 I/O가 약 14MB/초에 불과한 것으로 표시됩니다(이 문제가 발생한 이후 제가 본 최대치는 다음과 같습니다). 30MB/초):
이 도움이 된 걸 발견 한 후DiskSpd 사용에 관한 Brent Ozar 기사, 유사한 매개변수 하에서 직접 실행해 보았습니다(서버에 8개의 가상 프로세서가 있고 쓰기를 50%로 설정했기 때문에 스레드 수를 8로 낮추었습니다). 이것이 정확한 명령입니다 diskspd.exe -b2M -d60 -o32 -h -L -t8 -W -w50 "C:\Users\...\Desktop\Microsoft DiskSpd\Test\LargeFile.txt". 저는 수동으로 생성한 1GB 미만의 텍스트 파일을 사용했습니다. 측정된 I/O는 괜찮은 것 같지만 디스크 지연 시간은 터무니없는 숫자를 보여주었습니다.
DiskSpd 결과는 말 그대로 믿기지 않는 것 같습니다. 더 자세히 읽은 후 데이터베이스당 디스크 대기 시간 메트릭을 반환하는 Paul Randall의 쿼리를 우연히 발견했습니다. 결과는 다음과 같습니다.
최악의 쓰기 지연 시간은 63밀리초이고 최악의 읽기 지연 시간은 6밀리초였습니다. 따라서 이는 DiskSpd와 큰 차이가 있는 것으로 보이며 내 문제의 근본 원인이 될 만큼 심각해 보이지는 않습니다. 추가로 교차 확인하면서 서버 자체에서 PerfMon 카운터 몇 개를 실행했습니다.이 마이크로소프트 기사, 결과는 다음과 같습니다.
여기서는 특별한 것이 없습니다. 제가 측정한 모든 카운터의 최대값은 0.007이었습니다(제가 생각하기에 밀리초라고 생각하시나요?). 마지막으로 인프라 팀에게 백업 작업 중에 VMWare가 기록한 디스크 대기 시간 측정항목을 확인하도록 시켰고 그 결과는 다음과 같습니다.
최악의 경우 자정 무렵에 약 200밀리초의 지연 시간이 급증했으며 가장 높은 I/O는 600KB/초였습니다(리소스 모니터에서 백업이 최소한 약 14MB/초의 I/O).
내가 시도한 다른 것들:
방금 더 큰 데이터베이스(약 250GB) 중 하나를 복원하려고 시도했는데 복원하는 데 총 8분 정도밖에 걸리지 않았습니다. 그런 다음 실행을 시도했는데 DBCC CHECKDB실행하는 데 총 16분이 걸렸지만(정상인지 확실하지 않음) 리소스 모니터에서도 비슷한 I/O 문제가 나타났습니다(지금까지 사용한 최대 I/O는 100MB/s였습니다). 아무것도 실행되지 않습니다.
다음은 처음 실행한 후 5% 완료된 후의 sp_whoisactive 결과입니다. DBCC CHECKDB이미 5% 완료된 후에도 남은 예상 시간이 약 5분 증가한 것을 확인할 수 있습니다.
시작:
5% 완료:
나는 이것이 단지 추정치이므로 정상이라고 생각하고 있으며 250GB 데이터베이스에 대해 16분은 그리 나쁘지 않은 것 같습니다(비록 그것이 정상인지는 확실하지 않지만). 그러나 다시 I/O는 최대치에 도달했습니다. 서버나 SQL 인스턴스에서 다른 어떤 것도 실행되지 않고 드라이브 기능의 약 10%만 사용됩니다.
결과는 다음과 같습니다의 DBCC CHECKDB오류가 보고되지 않았습니다.
또한 명령에 이상한 속도 저하 문제가 발생했습니다 SHRINK. 방금 SHRINK릴리스할 공간이 5%(약 14GB) 있는 데이터베이스를 시도했습니다 . 다음 작업의 90%를 완료하는 데 약 1분밖에 걸리지 않았습니다 SHRINK.
약 5분 후에도 여전히 동일한 완료율에서 멈춰 있으며 트랜잭션 로그 백업(보통 1~2초 내에 완료됨)이 약 30초 동안 경합 상태에 있습니다.
15분 후에 작업 SHRINK이 완료되지만 트랜잭션 로그 백업은 현재 약 6분 동안 여전히 경합 중이며 50%만 완료되었습니다. 나는 그들이 끝난 이후로 그 직후에 즉시 끝났다고 믿습니다 SHRINK. 리소스 모니터가 계속해서 I/O를 빨아들이는 것을 보여주었습니다.
SHRINK그런 다음 완료되면 명령 에 오류가 발생했습니다 .
다시 시도했는데 SHRINK위와 똑같은 결과가 나왔습니다.
그런 다음 P: 드라이브의 파일에 대한 T-SQL 백업을 수동으로 스크립팅하려고 시도했는데 유지 관리 계획 백업 작업처럼 느리게 실행되었습니다.
결국 3분정도 지나서 취소했는데 바로 롤백되더군요.
요약:
우연히도 Windows 업데이트가 설치된 직후 매일 밤 백업 유지 관리 계획 작업이 약 40배 느려졌습니다(15분에서 15시간). 해당 Windows 업데이트를 롤백해도 문제가 해결되지 않았습니다. SQL Server 대기 유형, 리소스 모니터 및 Microsoft DiskSpd는 디스크 문제(특히 I/O)를 나타내지만 Paul Randall의 쿼리, PerfMon 및 VMWare 로그의 다른 모든 측정에서는 디스크 문제를 보고하지 않습니다. 특정 데이터베이스에 대한 백업 복원은 빠르며 거의 전체 1GB/초 I/O를 사용합니다. 머리를 긁적이네요...
답변1
이 경우 실제로 디스크 문제가 발생했으며 이 특정 VM에 대한 SQL Server 내부 문제는 아니었습니다. 실제로 Veeam과 VMWare를 사용하면서 발생한 버그 사례가 되었습니다.
무슨 일이 일어났는지에 대한 제가 이해한 바를 요약하자면, Veeam 백업이 VMWare에서 완료된 것으로 인식되지 않은 것 같습니다. 그래서 매일 서버를 백업할 시간이 되면 VMWare는 Veeam에게 전날 다시 백업하도록 지시했고 이로 인해 2주 동안 누적되는 문제가 발생했습니다. (내가 그 설명을 망쳤다고 확신하지만, 내가 아는 범위는 대략 이 정도이다.)
Veeam/VMWare는 매일의 파일이 이전 파일보다 큰 각 스냅샷 파일을 삭제해야 했기 때문에 레벨 3 지원을 완료하는 데 약 26시간이 걸렸습니다. 그 후 VM이 다시 정상적으로 실행되었습니다. 분명히 이것은 기술 지원에 따르면 드문 문제가 아닙니다.
죄송합니다. 이는 매우 구체적인 문제이므로 다른 많은 사람들에게는 도움이 되지 않을 것입니다. 하지만 도움이 되기를 바랍니다.