일반적으로 매주 전체 백업은 약 35 분 안에 완료되며 매일 diff 백업은 ~ 5 분 안에 완료됩니다. 화요일은 데일리가 거의 4 시간이 걸렸기 때문에 필요한 것 이상이되었습니다. 우연히도, 이것은 새로운 SAN / 디스크 구성을 얻은 직후에 시작되었습니다.
서버가 프로덕션 환경에서 실행 중이고 전체 문제가 없으며 백업 성능에서 주로 나타나는 IO 문제를 제외하고는 원활하게 실행되고 있습니다.
백업 중 dm_exec_requests를 보면 백업이 지속적으로 ASYNC_IO_COMPLETION을 기다리고 있습니다. 아하, 디스크 경합이 있습니다!
그러나 MDF (로그가 로컬 디스크에 저장 됨) 나 백업 드라이브에 활동이 없습니다 (IOPS ~ = 0-메모리가 충분합니다). 디스크 큐 길이도 ~ = 0입니다. CPU는 2-3 % 정도 움직입니다.
SAN은 Dell MD3220i이며 LUN은 6x10k SAS 드라이브로 구성됩니다. 서버는 두 개의 물리적 경로를 통해 SAN에 연결되어 있으며, 각각은 SAN에 중복 연결되는 별도의 스위치를 통해 연결됩니다. 총 4 개의 경로 중 2 개는 언제든지 활성화됩니다. 작업 관리자를 통해 두 연결이 모두 활성화되어 있는지 확인하여로드를 완벽하게 균등하게 분할 할 수 있습니다. 두 연결 모두 1G 전이중을 실행 중입니다.
우리는 점보 프레임을 사용했지만 여기서는 아무런 문제가 없도록 변경하지 않았습니다. 다른 LUN에 연결된 다른 서버 (같은 OS + config, 2008 R2)가 있으며 아무런 문제가 없습니다. 그러나 SQL Server를 실행하지 않고 CIFS를 공유합니다. 그러나 LUN의 기본 경로 중 하나는 번거로운 LUN과 동일한 SAN 컨트롤러에 있기 때문에이를 배제했습니다.
몇 가지 SQLIO 테스트 (10G 테스트 파일)를 실행하면 문제에도 불구하고 IO가 적절하다는 것을 알 수 있습니다.
sqlio -kR -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec: 3582.20
MBs/sec: 27.98
Min_Latency(ms): 0
Avg_Latency(ms): 3
Max_Latency(ms): 98
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 45 9 5 4 4 4 4 4 4 3 2 2 1 1 1 1 1 1 1 0 0 0 0 0 2
sqlio -kW -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec: 4742.16
MBs/sec: 37.04
Min_Latency(ms): 0
Avg_Latency(ms): 2
Max_Latency(ms): 880
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 46 33 2 2 2 2 2 2 2 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 1
sqlio -kR -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec: 1824.60
MBs/sec: 114.03
Min_Latency(ms): 0
Avg_Latency(ms): 8
Max_Latency(ms): 421
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 1 3 14 4 14 43 4 2 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 6
sqlio -kW -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec: 3238.88
MBs/sec: 202.43
Min_Latency(ms): 1
Avg_Latency(ms): 4
Max_Latency(ms): 62
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 0 0 0 9 51 31 6 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
나는 이것들이 어떤 식 으로든 철저한 테스트가 아니라는 것을 알고 있지만, 그것이 완전한 쓰레기가 아니라는 것을 알고 편안하게 만듭니다. 더 높은 쓰기 성능은 두 개의 활성 MPIO 경로로 인해 발생하지만 읽기는 그 중 하나만 사용합니다.
응용 프로그램 이벤트 로그를 확인하면 다음과 같이 흩어져있는 이벤트가 표시됩니다.
SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [J:\XXX.mdf] in database [XXX] (150). The OS file handle is 0x0000000000003294. The offset of the latest long I/O is: 0x00000033da0000일정하지는 않지만 정기적으로 발생합니다 (백 시간 동안 몇 시간, 더 많은 시간 백업). 해당 이벤트와 함께 시스템 이벤트 로그에 다음이 게시됩니다.
Initiator sent a task management command to reset the target. The target name is given in the dump data.
Target did not respond in time for a SCSI request. The CDB is given in the dump data.
이것들은 동일한 SAN / 컨트롤러에서 실행되는 문제가없는 CIFS 서버에서도 발생하며 내 인터넷 검색에서 중요하지 않은 것으로 보입니다.
모든 서버는 최신 드라이버와 동일한 NIC-Broadcom 5709C를 사용합니다. 서버 자체는 Dell R610입니다.
다음에 무엇을 확인할지 잘 모르겠습니다. 어떤 제안?
업데이트-perfmon을 실행
하면 평균 기록을 시도했습니다. 백업을 수행하는 동안 디스크 초 / 읽기 및 쓰기 성능 카운터. 백업은 엄청나게 시작된 다음 기본적으로 50 %에서 작동 중지를 멈추고 100 %로 천천히 크롤링하지만 시간은 20 배가 걸립니다.
사용중인 SAN 경로를 모두 표시하고 삭제합니다.
백업은 15:38:50 쯤에 시작되었습니다. 모든 것이 양호하게 보이면 일련의 피크가 있습니다. 나는 쓰기에 관심이 없으며 읽기 만 중단되는 것처럼 보입니다.
맨 끝에서 타오르는 성능이지만 매우 적은 동작 on / off에 유의하십시오.
평균은 전반적으로 양호하지만 최대 12 초를 참고하십시오.
업데이트-NUL 장치로 백업
읽기 문제를 분리하고 단순화하기 위해 다음을 실행했습니다.
BACKUP DATABASE XXX TO DISK = 'NUL'결과는 정확히 동일합니다. 버스트 읽기로 시작한 다음 중단되어 작업을 다시 시작한 다음 중단됩니다.
업데이트-IO
중단 Shawn이 권장 한 Jonathan Kehayias 및 Ted Kruegers 서적 (29 페이지) 의 dm_io_virtual_file_stats 쿼리를 실행했습니다 . 상위 25 개 파일 (각각 하나의 데이터 파일-모든 결과는 데이터 파일 임)을 보면 읽기가 쓰기보다 나쁜 것처럼 보일 수 있습니다. 쓰기는 SAN 캐시로 직접 이동하지만 콜드 읽기는 디스크에 충돌해야하기 때문일 수 있습니다. .
업데이트-대기 통계
몇 가지 대기 통계를 수집하기 위해 세 가지 테스트를 수행했습니다. 대기 통계는 Glenn Berry / Paul Randals 스크립트를 사용하여 쿼리 합니다. 그리고 확인하기 위해-백업은 테이프가 아니라 iSCSI LUN에 수행됩니다. 로컬 디스크에서 수행 한 결과는 NUL 백업과 비슷한 결과가 비슷합니다.
통계 지우기. 정상 하중 10 분 동안 실행 :
통계 지우기. 10 분 동안 실행, 정상로드 + 정상 백업 실행 (완료되지 않음) :
통계 지우기. 10 분 동안 실행, 정상로드 + NUL 백업 실행 (완료되지 않음) :
업데이트-Wtf, Broadcom?
Mark Storey-Smiths 제안과 Kyle Brandts의 Broadcom NIC에 대한 이전 경험을 바탕으로 몇 가지 실험을하기로 결정했습니다. 여러 활성 경로가 있으므로 중단없이 NIC 구성을 하나씩 쉽게 쉽게 변경할 수 있습니다.
TOE 및 Large Send Offload를 비활성화하면 거의 완벽하게 실행됩니다.
Processed 1064672 pages for database 'XXX', file 'XXX' on file 1.
Processed 21 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064693 pages in 58.533 seconds (142.106 MB/sec).그렇다면 범인, TOE 또는 LSO는 무엇입니까? TOE 활성화, LSO 비활성화 :
Didn't finish the backup as it took forever - just as the original problem!TOE 비활성화, LSO 활성화-보기 :
Processed 1064680 pages for database 'XXX', file 'XXX' on file 1.
Processed 29 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064709 pages in 59.073 seconds (140.809 MB/sec).그리고 통제권으로, 문제가 사라 졌음을 확인하기 위해 TOE와 LSO를 모두 비활성화했습니다.
Processed 1064720 pages for database 'XXX', file 'XXX' on file 1.
Processed 13 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064733 pages in 60.675 seconds (137.094 MB/sec).결론적으로 활성화 된 Broadcom NIC TCP 오프로드 엔진이 문제를 일으킨 것으로 보입니다. TOE가 비활성화 되 자마자 모든 것이 매력처럼 작동했습니다. 앞으로 더 이상 Broadcom NIC를 주문하지 않을 것입니다.
업데이트-다운으로 인해 CIFS 서버로 이동
오늘날 동일하고 작동하는 CIFS 서버는 IO 요청이 중단 된 것으로 나타났습니다. 이 서버는 SQL Server를 실행하지 않고 CIFS를 통해 공유를 제공하는 일반 Windows Web Server 2008 R2 만 실행했습니다. TOE를 비활성화하자마자 모든 것이 순조롭게 진행되었습니다.
Broadcom NIC를 전혀 피할 수 없다면 Broadcom NIC에서 TOE를 다시 사용하지 않을 것입니다.