오래된 올 플래시 어레이에서 새로운 올 플래시 어레이 (서로 다르지만 잘 확립 된 공급 업체)로 마이그레이션 할 때 검사 점 동안 SQL Sentry에서 대기 시간이 길어지기 시작했습니다.
버전 : SQL Server 2012 Sp4
기존 스토리지에서는 체크 포인트 동안 "스파이크 (spikes)"가 2500 인 대기 시간이 약 2k였으며, 새 스토리지의 경우 스파이크는 일반적으로 피크가 50k에 가까운 10k입니다. 센트리는 우리에게 더 많은 것을 PAGEIOLATCH지적합니다. 우리 자신의 분석을 수행하면 PAGEIOLATCH and PAGELATCH대기 의 조합으로 보입니다 . Perfmon을 사용하면 일반적으로 체크 포인트가 많을수록 대기 시간이 길어 지지만 체크 포인트 동안 ~ 125MB를 플러시합니다. 우리의 작업량은 주로 쓰기입니다 (주로 삽입 / 업데이트).
스토리지 공급 업체는 이러한 체크 포인트 이벤트 중에 파이버 채널 직접 연결 어레이가 1ms 미만으로 응답하고 있음을 입증했습니다. HBA는 또한 어레이 번호를 확인합니다. 또한 큐 깊이가 8을 초과하지 않았기 때문에 HBA 큐잉 문제라고 생각하지 않습니다. 또한 ZIO, 실행 스로틀 및 큐 깊이 설정을 변경할 수없는 새로운 HBA도 시도했습니다. 또한 변경없이 서버 메모리를 500GB에서 1TB로 늘 렸습니다. 검사 점 프로세스 중에 2-4 개의 개별 코어 (16 개)가 100 %로 급등하지만 전체 CPU는 약 20 %입니다. BIOS도 고성능으로 설정되어 있습니다. 흥미롭게도 CPU가 비활성화되어 있어도 CPU가 일반적으로 C2 절전 상태에있는 것을 볼 수 있으므로 여전히 절전 상태가 C1을 넘어서는 이유를 연구하고 있습니다.
거의 모든 대기 시간이 가끔 PFS DCM 페이지 유형의 데이터 페이지에 있음을 알 수 있습니다. 대기는 tempdb가 아닌 사용자 DB에 있습니다. 또한 대기는 여러 데이터 페이지에 걸쳐 있으며 일부 SPID는 동일한 페이지에 대기하고 있습니다. 데이터베이스 디자인에는 몇 개의 인서트 핫스팟이 있지만 이전 스토리지와 동일한 디자인이 사용되었습니다.
이 쿼리 루프를 100 번 실행하면 디스크 대 메모리에서 대기중인 SPID 수를 파악할 수있었습니다.
SELECT
[owt].[wait_type], count(*) as waitcount
FROM sys.dm_os_waiting_tasks [owt]
WHERE [owt].[wait_type] LIKE 'PAGE%'
group by [owt].[wait_type]
order by 1
GO 100
"좋은"것은 동일한 모델 배열과 유사한 서버 사양을 가진 성능 환경에서 문제를 쉽게 재현 할 수 있다는 것입니다. 다른 곳을 보거나 문제를 좁히는 방법에 대한 의견을 보내 주셔서 감사합니다. 현재 우리의 다음 테스트에는 새로운 마더 보드와 더 많은 CPU를 갖춘 새로운 서버; SIOS 데이터 키퍼 비활성화 (이것은 오래된 스토리지를 가지고 있었음에도 불구하고); 다른 HBA 브랜드.
exec sp_Blitz @outputtype = 'markdown'우선 순위 5 : 안정성 :-위험한 타사 모듈-Sophos Limited-Sophos 버퍼 오버런 방지-SOPHOS ~ 2.DLL-의심되는 위험한 타사 모듈이 설치되어 있습니다.
우선 순위 200 : 정보 :-클러스터 노드-클러스터의 노드입니다. -TraceFlag On-추적 플래그 1117이 전역 적으로 활성화되었습니다. -트레이스 플래그 (1118)는 전체적으로 활성화된다. -추적 플래그 3226이 전체적으로 사용 가능합니다.
우선 순위 200 : 라이센싱 :-사용중인 Enterprise Edition 기능 * xxxxx-[xxxxxx] 데이터베이스가 압축을 사용하고 있습니다. 이 데이터베이스가 Standard Edition 서버로 복원되면 2016 SP1 이전 버전에서는 복원이 실패합니다. * xxxxx-[xxxxxx] 데이터베이스가 파티셔닝을 사용하고 있습니다. 이 데이터베이스가 Standard Edition 서버로 복원되면 2016 SP1 이전 버전에서는 복원이 실패합니다.
우선 순위 240 : 대기 통계 :-유의미한 대기가 감지되지 않음-이 서버가 유휴 상태에 앉아 있거나 누군가 최근 대기 통계를 지 웠을 수 있습니다.
우선 순위 250 : 서버 정보:-하드웨어-논리 프로세서 : 16. 실제 메모리 : 512GB. -하드웨어-NUMA 구성-노드 : 0 상태 : 온라인 온라인 스케줄러 : 8 오프라인 스케줄러 : 0 프로세서 그룹 : 0 메모리 노드 : 0 메모리 VAS 예약 GB : 1177-노드 : 1 상태 : 온라인 온라인 스케줄러 : 8 오프라인 스케줄러 : 0 프로세서 그룹 : 0 메모리 노드 : 1 메모리 VAS 예약 GB : 0-전원 계획-서버에 3.50GHz CPU가 있고 고성능 전원 모드에 있습니다.-서버 마지막 다시 시작-2018 년 7 월 4 일 4:56 AM-SQL Server 마지막 다시 시작-7 월 5 일 2018 5:11 AM-SQL Server 서비스-버전 : 11.0.7462.6. 패치 레벨 : SP4. 에디션 : Enterprise Edition (64 비트). 가용성 그룹 사용 : 1. 가용성 그룹 관리자 상태 : 1-가상 서버-유형 : (HYPERVISOR)-Windows 버전-최신 버전의 Windows : Server 2012R2 시대, 버전 6.3을 실행하고 있습니다.
우선 순위 200 : 비 기본 서버 구성:-에이전트 XP-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.-백업 압축 기본값-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.-차단 된 프로세스 임계 값-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 20으로 설정되었습니다.-병렬 처리 비용 임계 값-이 sp_configure 옵션이 변경되었습니다. 기본값은 5이고 30으로 설정되었습니다.-Database Mail XPs-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.-max degree of parallelism-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 8로 설정되었습니다.-max server memory (MB)-이 sp_configure 옵션이 변경되었습니다. 기본값은 2147483647이며 496640으로 설정되었습니다.-최소 서버 메모리 (MB)-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 8196으로 설정되었습니다.-특별 워크로드에 최적화-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.-원격 액세스-이 sp_configure 옵션이 변경되었습니다. 기본값은 1이며 0으로 설정되었습니다.-원격 관리자 연결-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.-시작 프로세스 검색-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.-고급 옵션 표시-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.-xp_cmdshell-이 sp_configure 옵션이 변경되었습니다.