RAID 6에 SSD가 설정된 SAN을 사용하고 서버 백업에는 Veeam을, SQL Server 백업에는 LiteSpeed를 사용하여 Windows VMWare 플랫폼에서 SQL Server를 실행하는 환경이 있습니다.
지난 1년 동안 가끔 데이터베이스가 크롤링 속도로 느려지는 문제가 여러 번 발생했습니다. 디스크 큐 길이는 높지만 디스크 바이트/초가 허용되는 것보다 훨씬 낮습니다.
다음은 데이터베이스 서버의 성능 모니터입니다. 이 문제가 발생하면 Avg. 디스크 큐 길이는 항상 수백 범위에 있고 디스크 바이트/초는 약 5-15MB/초로 유지됩니다. 정상 작동 중에(이 문제가 발생하지 않는 경우) 디스크 바이트/초는 900MB/초 정도까지 올라갑니다.
이 문제가 발생하기 시작한 이후로 스위치를 포함한 SAN 하드웨어를 교체했습니다. 그러나 문제는 새 하드웨어에서도 계속됩니다.
내 이론은 이것이 SQL Server 문제가 아니라는 것입니다. 문제가 SQL Server가 디스크 I/O를 포화시키는 것이라면 훨씬 더 높은 디스크 바이트/초가 표시되어야 하기 때문입니다. 그러나 이 문제가 발생할 때마다 Disk Bytes/sec는 항상 매우 낮습니다.
아마도 데이터베이스 서버에서 실행되거나 동일한 VMWare/SAN을 사용하는 다른 서버에서 실행되는 백업 소프트웨어일 것이라고 생각했지만 이 문제가 발생하는 동안 서버 백업이나 SQL Server 백업이 실행되지 않는 것 같습니다. 사고.
마지막으로 생각한 것은 이것이 VMWare의 문제라는 것이었습니다. 그러나 VMWare에 연락했지만 지금까지는 도움을 받을 수 없었습니다.
데이터베이스 서버를 재부팅하면 문제가 해결됩니다. 하루 만에 문제가 다시 발생하는 경우도 있고, 몇 달이 지나도 문제가 다시 발생하지 않는 경우도 있습니다. 문제가 발생할 때마다 데이터베이스에서 실행되는 일반적인 워크로드 이외의 어떤 것도 인식하지 못합니다.
디스크 처리량이 필요한 처리량의 약 1%로 느려지는 경우 이 문제의 원인은 무엇입니까?
답변1
HDD는 작업 대기열이 길어질수록 속도가 느려지고 그 반대의 경우도 마찬가지입니다. HDD에 적용할 수 있는 IOPS 수가 매우 제한되어 있습니다(등급 및 RPM에 따라 대략 40-200). 그 이상으로 수요가 증가하면 성능이 더욱 저하됩니다.
HDD 어레이를 생성하면 어레이 전체에서 가능한 총 읽기 IOPS 수가 증가하지만 일반적으로 개별 IOPS를 단순히 합산하는 것보다 적습니다. 쓰기 IOPS는 더 복잡하며 RAID 수준, 캐싱 등에 크게 의존합니다.
그 이상에는 SSD와 적절한 컨트롤러가 필요합니다.
답변2
이미 SSD를 사용하고 계시므로 SSD에서 TRIM이 제대로 처리되지 않는 문제가 제가 겪었던 문제와 유사할 수 있다고 제안합니다. SSD에서 데이터 블록을 지우는 작업은 즉각적이지 않습니다. 재사용을 위해 블록을 준비하는 것은 느린 프로세스일 수 있으며 속도 저하의 원인이 될 수 있습니다. 사용 가능하고 준비된 블록이 모두 소진되면 어레이가 새 블록처럼 급격히 느려질 수 있습니다. 블록이 준비되어 있습니다. SAN이 이것이 SSD임을 인식하고 백그라운드 TRIM이 활성화되어 있는지 확인하십시오.