SQL Server에서 15 초 이상 걸리는 I / O 요청이 발생했습니다.

프로덕션 SQL Server에는 다음 구성이 있습니다.

가용성 그룹에 결합 된 3 개의 Dell PowerEdge R630 서버 3 개는 모두 RAID 배열 인 단일 Dell SAN 스토리지 장치에 연결됩니다.

PRIMARY에서 때때로 다음과 유사한 메시지가 표시됩니다.

SQL Server에서 데이터베이스 ID 8
의 [F : \ Data \ MyDatabase.mdf] 파일에서 완료되는 데 15 초 이상 걸리는 11 개의 I / O 요청이 발생했습니다 . OS 파일 핸들은 0x0000000000001FBC입니다.
최신 긴 I / O의 오프셋은 0x000004295d0000입니다.
긴 I / O의 지속 시간은 37397ms입니다.

우리는 성능 문제 해결에 초보자입니다

스토리지와 관련된이 특정 문제를 해결하는 가장 일반적인 방법 또는 모범 사례는 무엇입니까? 그러한 메시지의 근본 원인을 좁히려면 어떤 성능 카운터, 도구, 모니터, 앱 등을 사용해야합니까? 도움이 될 수있는 확장 된 이벤트 또는 감사 / 로깅이있을 수 있습니까?

비슷한 설정이 있으며 최근 로그에서 이러한 메시지가 발생했습니다. 우리는 DELL Compellent SAN을 사용하고 있습니다. 이러한 메시지를 수신 할 때 확인해야 할 몇 가지 사항은 다음과 같습니다.

• 경고 메시지가 가리키는 디스크의 Windows 성능 카운터를 구체적으로 검토하십시오.
  • 디스크 평균 읽는 시간
  • 디스크 평균 쓰기 시간
  • 디스크 읽기 바이트 / 초
  • 디스크 쓰기 바이트 / 초
  • 디스크 전송 / 초
  • 평균 디스크 대기열 길이
• 위의 평균입니다. 하나의 드라이브에 많은 데이터베이스 파일이있는 경우 이러한 평균으로 인해 결과가 왜곡되고 특정 데이터베이스 파일에서 병목 현상이 발생할 수 있습니다. dmv에서 각 파일의 평균 대기 시간을 반환하는 Paul S. Randal 에서이 쿼리를 확인하십시오 sys.dm_io_virtual_file_stats. 우리의 경우보고 된 평균 대기 시간은 수용 가능했지만, 덮개 아래에 평균 200ms 이상의 대기 시간을 가진 많은 파일이있었습니다.
• 타이밍을 확인하십시오. 패턴이 있습니까? 밤에 특정 시간에 더 자주 발생합니까? 그렇다면 해당 시간에 유지 보수 작업이 실행 중인지 또는 스케줄 된 활동으로 인해 디스크 활동이 증가하고 IO 서브 시스템에 병목 현상이 발생하는지 점검하십시오.
• Windows 이벤트 뷰어에서 오류를 확인하십시오. 스위치 나 SAN에 과부하가 걸리거나 응용 프로그램에 맞게 올바르게 설정되지 않은 경우이 로그에 일부 메시지가 표시 될 수 있으며이 정보를 SAN 관리자에게 가져가는 것이 좋습니다. 이 경우 하루 종일 iSCSI 연결 오류가 자주 발생하여 문제를 암시합니다.
• SQL Server 코드를 검토하십시오. 이러한 메시지를받을 때 즉시 IO 서브 시스템 문제라고 생각해서는 안되며이를 SAN 관리자에게 전달해서는 안됩니다. 귀하는 귀하의 역할을 수행하고 데이터베이스를 검토해야합니다. 많은 양의 데이터를 통해 자주 발생하는 잘못된 쿼리가 있습니까? 인덱싱이 잘못 되었습니까? 과도한 트랜잭션 로그 쓰기? 일부 오픈 소스 쿼리를 사용하여 데이터베이스에서 상태를 확인할 수 있습니다. 쿼리 계획이 어떻게 보이는지 확인하는 예제는 sp_blitzCache입니다.
• 이것을 무시하지 마십시오. 오늘 하루에 몇 번받을 수 있습니다. 몇 달 후에 워크로드가 증가하고 모니터링을 잊었을 때 증가하기 시작했습니다. 이러한 메시지를 많이 받으면 SQL Server가 특정 파일에 액세스하지 못할 수 있으며 tempdb 인 경우 좋지 않습니다. 우리의 경우 SQL Server 자체가 종료되는 것이 너무 나빴습니다.

우리의 솔루션은 스위치를 SAN 스위치로 업그레이드하는 것이 었습니다. 예, 이것들은 모두 SQL Server에서 다룰 내용입니다. 우리가 스위치를 찾게 된 것은 매일 SQL Server의 Windows 응용 프로그램 이벤트 뷰어에서 약 1500 개의 iSCSI pdu 연결 끊기 오류가 발생했다는 것입니다. SAN 관리자가 스위치를 조사했습니다.

업그레이드 직후 iSCSI 오류가 사라지고 모든 파일에 대해 평균 대기 시간이 약 50ms로 낮아졌으며 이는 응용 프로그램의 성능 향상과 관련이 있습니다. 이러한 점을 염두에두고 솔루션을 찾을 수 있기를 바랍니다.

이는 디스크 문제가 훨씬 적고 네트워킹 문제가 훨씬 더 자주 발생합니다. SAN의 N?

SAN 팀에 가서 디스크 속도가 느리다는 이야기를 시작하면 대기 시간이 0 밀리 초인 멋진 그래프가 표시되고 스테이플러가 나타납니다.

대신 SAN에 대한 네트워크 경로에 대해 문의하십시오. 다중 경로 인 경우 속도를 얻습니다.보고 있어야하는 속도에 대한 숫자를 얻으십시오. 서버 설정 당시의 벤치 마크가 있는지 묻습니다.

그런 다음 Crystal Disk Mark 또는 diskpd 를 사용하여 해당 속도를 확인할 수 있습니다 . 그들이 정렬되지 않으면 네트워킹 일 가능성이 높습니다.

또한 "FlushCache"및 "saturation"이 포함 된 메시지도 네트워크 경합의 징후 일 수 있으므로 오류 로그를 검색해야합니다.

DBA로서 이러한 일을 피하기 위해 할 수있는 한 가지는 유지 보수 및 기타 데이터가 많은 작업 (예 : ETL)이 동시에 진행되지 않도록하는 것입니다. 이는 스토리지 네트워킹에 많은 부담을 줄 수 있습니다.

: 당신은 또한 더 제안 여기에 대한 답변을 확인 할 수 있습니다 느린 체크 포인트 및 플래시 스토리지에 15초 I / O 경고

서버에서 SAN 으로 비슷한 주제에 대해 블로그를 작성했습니다.

SAN에 데이터를 저장하는 이유는 무엇입니까? 점은 무엇인가? 모든 데이터베이스 성능은 디스크 I / O에 연결되어 있으며 I / O를위한 장치가 하나만있는 서버 3 대를 사용하고 있습니다. 그건 말이 안 돼요 ... 불행히도 너무 일반적입니다.

사람들이 대규모 컴퓨터를 설계하려고하는 저조한 하드웨어 플랫폼을 만나면서 평생을 보냅니다. 여기의 모든 CPU 전원, 모든 디스크 ... 원격 RAM과 같은 것이 없기를 바랍니다. 그리고 가장 슬픈 것은 그들이 필요로하는 것보다 열 배나 더 큰 서버로이 설계의 효율성 부족을 보상한다는 것입니다. 나는 $ 1k 노트북보다 $ 400k 인프라가 느리다는 것을 보았다.

SQL 서버 소프트웨어는 매우 진보 된 소프트웨어로 하드웨어, CPU 코어, CPU 캐시, TLB, RAM, 디스크 컨트롤러, 하드 드라이브 캐시 등 모든 비트를 활용하도록 설계되었습니다. 거의 모든 파일 시스템 논리를 포함합니다. 일반 컴퓨터에서 개발되었으며 고급 시스템에서 벤치마킹되었습니다. 따라서 SQL 서버에는 자체 디스크가 있어야합니다. SAN에 설치하는 것은 컴퓨터를 "에뮬레이트"하는 것과 같으므로 모든 성능 최적화가 손실됩니다. SAN은 백업, 변경 불가능한 파일 및 방금 데이터를 추가 한 파일 (로그)을 저장하기위한 것입니다.

데이터 센터 관리자는 관리 할 스토리지 풀이 하나뿐이므로 각 서버에서 스토리지를 관리하는 것보다 훨씬 쉽기 때문에 SAN에 가능한 모든 것을 배치하는 경향이 있습니다. "나는 내 일을하고 싶지 않다"는 선택이고, 나쁜 것은 성능 문제를 다루어야하고 모든 회사가이 문제를 겪고 있기 때문이다. 설계된 하드웨어에 소프트웨어를 설치하기 만하면됩니다. 간단하게 유지하십시오. I / O 대역폭, 캐시 및 컨텍스트 스위치 오버 헤드, 리소스 지터 (리소스가 공유 될 때 발생 함)를 관리합니다. 결과적으로 동일한 원시 출력 전력으로 장치의 1/10을 유지하고, 운영 팀에게 많은 두통을 줄이며, 최종 사용자를 행복하고 생산적으로 만들어주는 성능을 얻고, 회사를 일하기 더 좋은 곳으로 만들고, 많은 에너지를 절약하십시오 (행성이 감사합니다).

당신은 의견에서 서버에 SSD를 넣는 것을 고려하고 있다고 말했습니다. SAN과 비교할 때 전용 SSD로 설정을 인식하지 못하므로 동일한 드라이브의 데이터 및 트랜잭션 로그 파일에서도 500 배 향상됩니다. 최신 SQL Server는 서로 다른 하드웨어 컨트롤러 채널 (대부분의 서버 마더 보드에는 여러 개)에 데이터 및 트랜잭션 로그를위한 별도의 SSD가 있습니다. 그러나 현재 설정과 비교하여 공상 과학에 대해 이야기하고 있습니다. SSD를 사용해보십시오.

좋아, 관심있는 사람은

몇 달 전에 3 개의 서버 각각에 직접 연결된 SSD 드라이브를 설치하고 SAN에서 해당 SSD 드라이브로 DB 데이터 및 로그 파일을 이동하여 몇 개월 전에 문제를 해결했습니다.

SSD 드라이브를 설치하기로 결정하기 전에이 문제에 대해 조사 한 내용 (이 질문의 모든 게시물의 권장 사항 사용)에 대한 요약입니다.

1) 세 서버 모두에서 다음 드라이브에 대한 PerfMon 카운터 수집을 시작했습니다.

Disk F:SAN 기반 논리 디스크, MDF 데이터 파일
Disk I:포함 LDF 로그 파일 포함
Disk T:SSD, 직접 tempDB 전용

아래 그림은 2 주 동안 수집 된 평균 값입니다.

Disk I: (LDF)IO가 작고 대기 시간이 매우 낮으므로 디스크 I : 무시할
수 있음 Disk T: (TempDB)IO에 비해 더 큰 IO가 있음 을 알 수 있으며 Disk F: (MDF)동시에 대기 시간이 훨씬 더 좋습니다-0 ms

분명히 디스크 F에 문제가 있습니다. 데이터 파일이 상주하는 곳은 IO가 낮음에도 불구하고 대기 시간이 길고 평균 디스크 쓰기 큐가 높습니다.

2)이 웹 사이트의 쿼리를 사용하여 개별 데이터베이스에 대한 대기 시간 확인

https://www.brentozar.com/blitz/slow-storage-reads-writes/

1 차 서버에서 거의 150-250ms의 읽기 대기 시간과 150-450ms의 쓰기 대기 시간을 가진 몇 가지 활성 데이터베이스
흥미로운 점은 무엇입니까? master 및 msdb 데이터베이스 파일의 읽기 지연 시간은 최대 90ms로 , 데이터의 작은 크기와 낮은 IO로 인해 의심됩니다. SAN에 문제가있는 다른 표시

3) 구체적인시기는 없었다

"SQL Server에 문제가 발생했습니다 ..."메시지가 표시
되는 동안 해당 메시지가 기록 될 때 실행중인 유지 관리 또는 디스크가 많은 ETL이 없습니다.

4) Windows 이벤트 뷰어

"SQL Server에서 발생했습니다 ..."를 제외하고 문제를 암시하는 다른 항목을 표시하지 않았습니다.

5) 상위 10 개 쿼리 확인 시작

sp_BlitzCache (cpu, 읽기 등) 및 가능한 경우 최대한 활용
많은
데이터베이스를 인덱싱해도 데이터베이스를 인덱싱 해도 스토리지에 많은 영향을 줄 수있는 수퍼 IO 무거운 쿼리 는 없습니다.

6) 우리는 SAN 팀이 없습니다

SAN 에 대한 네트워크 경로를 도와주는 1 명의 sysadmin 만 있습니다. 다중 경로이며, 3 개의 서버 각각에 2 개의 네트워크 케이블이있어 스위치와 SAN으로 연결되며 1 기가 바이트 / 초로 가정됩니다

7) CrystalDiskMark 결과가 없습니다

또는 서버 설정 당시의 다른 벤치 마크 테스트 결과 속도 가 무엇인지 알 수 없으며 현재 속도가 프로덕션에 영향을 미쳤을 때 현재 속도를 확인하기 위해 벤치 마크 할 수 없습니다.

8) 해당 데이터베이스의 체크 포인트 이벤트에서 확장 이벤트 세션 설정

XE 세션은 "SQL Server에서 발생했습니다 ..."메시지 중에 체크 포인트가 실제로 느리게 발생 함을 발견하는 데 도움이되었습니다 (최대 90 초).

9) SQL Server 오류 로그

포함 된 "FlushCache" "Saturation"항목
지정된 데이터베이스의 검사 점 시간이 복구 간격 설정을 초과 할 때 표시됩니다.

세부 사항에 따르면 체크 포인트가 플러시하려고하는 데이터의 양이 적고 완료하는 데 오랜 시간이 걸리며 전체 속도는 약 0.25MB / 초입니다 ... 이상한

10) 마지막으로이 그림은 스토리지 문제 해결 차트를 보여줍니다.

"하드웨어 문제 : 시스템 관리자 / 하드웨어 공급 업체와 협의하여 SAN, 구 / 결함 드라이버, 컨트롤러, 펌웨어 등의 구성 오류를 수정하십시오."

또 다른 질문 "Slow checkpoint ..." 플래시 스토리지의 느린 체크 포인트 및 15 초 I / O 경고 Sean은 하드웨어 및 소프트웨어 수준에서 문제를 해결하기 위해 점검해야 할 항목에 대한 목록이 매우 훌륭했습니다.

우리의 sysadmin은 목록에서 모든 것을 확인할 수 없었기 때문에 우리는 단순히이 문제에서 일부 하드웨어를 던지기로 선택했습니다.

해결:

1TB SSD 드라이브를 주문하고 서버에 직접 설치

가용성 그룹이 있으므로 보조 복제본에서 SAN에서 SSD로 DB 데이터 파일을 마이그레이션 한 다음 장애 조치 및 이전 기본에서 파일을 마이그레이션하여 총 다운 타임을 최소화했습니다 (1 분 미만).

이제 각 서버에는 로컬 DB 데이터 복사본이 있으며 언급 된 SAN으로 전체 / 차이 / 로그 백업이 수행됩니다.
Windows 이벤트 뷰어 로그에 더 이상 "SQL Server에서 발생했습니다 ..."메시지와 백업 성능, 무결성 검사, 인덱스 재 구축, 쿼리 등이 크게 증가했습니다.

DB 파일을 SSD로 마이그레이션 한 후 IO 대기 시간 측면에서 성능이 얼마나 향상 되었습니까?

영향을 평가하기 위해 마이그레이션 2 주 전과 마이그레이션 4 주 후의 성능 Windows 성능 모니터 로그를 사용했습니다.

아래는 DB 수준 대기 시간 통계 비교입니다 (마이그레이션 전후에 SQL Server의 캡처 된 가상 파일 통계 사용).

요약

SAN에서 직접 연결된 로컬 SSD로 마이그레이션하는 것이 가치가
있었습니다. 스토리지 대기 시간에 큰 영향을 미쳤으며 평균 (특히 WRITE 작업) 평균 90 % 이상 향상되었으며 IO에서 20-50 초의 급격한 증가가 없습니다.

로컬 SSD로 이동하면 스토리지 성능 문제뿐만 아니라 우려했던 데이터 안전성도 해결되었습니다 (SAN에 장애가 발생하면 3 대의 서버 모두 동시에 데이터가 손실 됨)