64GB 이상 사용 가능하여 몇 달 동안 SQL Server의 "Total Server Memory"소비가 정체 됨

SQL Server 2016 Standard Edition 64 비트가 할당 된 총 메모리의 정확히 절반 (64GB의 128GB)에서 멈춰있는 이상한 문제가 발생했습니다.

출력 @@VERSION은 다음과 같습니다.

Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119)-13.0.4466.4 (X64) 2017 년 12 월 22 일 11:25:00 저작권 (c) Windows Server 2012 R2 Datacenter 6.3의 Microsoft Corporation Standard Edition (64 비트) ( 빌드 9600 :) (하이퍼 바이저)

출력 sys.dm_os_process_memory은 다음과 같습니다.

내가 쿼리 할 때 sys.dm_os_performance_counters, 나는 Target Server Memory (KB)at에 131072000있고 그것의 Total Server Memory (KB)절반에 불과하다는 것을 알 수 있습니다 65308016. 대부분의 시나리오에서 SQL Server가 아직 추가 메모리를 할당해야한다고 결정하지 않았기 때문에 이것이 정상적인 동작이라는 것을 알고 있습니다.

그러나 현재 2 개월 이상 ~ 64GB에서 "고착"되었습니다. 이 기간 동안 일부 데이터베이스에서 상당한 양의 메모리 집약적 인 작업을 수행했으며 인스턴스에 약 40 개의 데이터베이스를 추가했습니다. 우리는 총 292 개의 데이터베이스를 사용하고 있으며, 각각은 4MB의 사전 할당 된 데이터 파일과 256MB의 자동 증가율과 2GB의 로그 파일과 128MB의 자동 증가율을 갖습니다. 매일 밤 12:00 AM에 전체 백업을 수행하고 월요일부터 금요일까지 오전 6 시부 터 오후 8 시까 지 15 분 간격으로 트랜잭션 로그 백업을 시작합니다. 이 데이터베이스는 전체 처리량이 상대적으로 낮지 만 SQL Server가 데이터를 처리하지 못해서 문제가 발생하는 것에 회의적입니다.Target Server Memory 새로운 데이터베이스 추가, 정상적인 쿼리 실행 및 메모리 집약적 인 ETL 파이프 라인을 통해 자연스럽게 실행됩니다.

SQL Server 인스턴스 자체는 12 개의 CPU, 144GB의 메모리 (128GB-SQL Server, 16GB는 Windows 용으로 예약 됨) 및 15K SAS 드라이브가있는 vSAN 위에있는 총 4 개의 가상 디스크가있는 가상화 된 (VMware) Windows Server 2012R2 서버 위에 있습니다. . Windows는 64GB C : 페이지 파일이 32GB 인 디스크에 자연스럽게 배치됩니다. 데이터 파일은 2TB D : 디스크에 있고 로그 파일은 2TB L : 디스크 위에 있고 tempdb는 자동 증가없이 8x16GB 파일이있는 256GB T : 디스크에 있습니다.

서버 외에 다른 SQL Server 인스턴스가 서버에서 실행되고 있지 않은지 확인했습니다 MSSQLSERVER.

이 서버는 전적으로 SQL Server 인스턴스 전용이므로 메모리를 소비 할 수있는 다른 응용 프로그램이나 서비스는 없습니다.

RedGate SQL Monitor를 분석에 사용하며 아래는 지난 18 일의 기록입니다 Total Server Memory. 보시다시피, 메모리 사용률은 4 월 초 ~ 300MB의 단일 증가를 제외하고는 완전히 정체되어 있습니다.

이것의 원인은 무엇입니까? SQL Server가 할당 된 추가 64GB 이상의 메모리를 사용하지 않는 이유를 확인하기 위해 무엇을 자세히 살펴볼 수 있습니까?

실행 결과 sp_Blitz:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

우선 순위 50 : 성능 :

• CPU 스케줄러 오프라인-선호도 마스킹 또는 라이센스 문제로 인해 일부 CPU 코어에 SQL Server에 액세스 할 수 없습니다.

• 메모리 노드 오프라인-선호도 마스킹 또는 라이센스 문제로 인해 일부 메모리를 사용하지 못할 수 있습니다.

우선 순위 50 : 신뢰성 :

• Remote DAC Disabled-DAC (Dedicated Admin Connection)에 대한 원격 액세스가 활성화되어 있지 않습니다. DAC를 사용하면 SQL Server가 응답하지 않을 때 원격 문제 해결이 훨씬 쉬워집니다.

우선 순위 100 : 성능 :

• 단일 쿼리에 대한 많은 계획-계획 캐시에 단일 쿼리에 대한 300 개의 계획이 있습니다. 이는 아마도 매개 변수화 문제가있을 수 있음을 의미합니다.

• 서버 트리거 활성화

  • 서버 트리거 [RG_SQLLighthouse_DDLTrigger]가 활성화되었습니다. 트리거가 수행하는 작업을 이해해야합니다. 작업이 적을수록 더 좋습니다.

  • 서버 트리거 [SSMSRemoteBlock]이 활성화되었습니다. 트리거가 수행하는 작업을 이해해야합니다. 작업이 적을수록 더 좋습니다.

우선 순위 150 : 성능 :

• 조인 힌트 강제 쿼리-재시작 이후 1480 개의 조인 힌트 인스턴스가 기록되었습니다. 이는 쿼리가 SQL Server 옵티 마이저를 사용하고 있다는 것을 의미하며, 수행중인 작업을 모르는 경우 좋은 것보다 더 많은 피해를 줄 수 있습니다. DBA 튜닝 노력이 효과가없는 이유도 설명 할 수 있습니다.

• 주문 힌트 쿼리 조회-재시작 이후 2153 개의 주문 힌트 인스턴스가 기록되었습니다. 이는 쿼리가 SQL Server 옵티 마이저를 사용하고 있다는 것을 의미하며, 수행중인 작업을 모르는 경우 좋은 것보다 더 많은 피해를 줄 수 있습니다. DBA 튜닝 노력이 효과가없는 이유도 설명 할 수 있습니다.

우선 순위 170 : 파일 구성 :

• C 드라이브의 시스템 데이터베이스

  • master-마스터 데이터베이스에는 C 드라이브에 파일이 있습니다. C 드라이브에 시스템 데이터베이스를 배치하면 공간이 부족할 때 서버가 충돌 할 위험이 있습니다.

  • model-모델 데이터베이스에는 C 드라이브에 파일이 있습니다. C 드라이브에 시스템 데이터베이스를 배치하면 공간이 부족할 때 서버가 충돌 할 위험이 있습니다.

  • msdb-msdb 데이터베이스에는 C 드라이브에 파일이 있습니다. C 드라이브에 시스템 데이터베이스를 배치하면 공간이 부족할 때 서버가 충돌 할 위험이 있습니다.

우선 순위 200 : 정보 제공 :

• 동시에 시작되는 에이전트 작업-여러 SQL Server 에이전트 작업이 동시에 시작되도록 구성되어 있습니다. 자세한 일정 목록은 URL의 쿼리를 참조하십시오.

• 마스터 데이터베이스 마스터의 테이블-마스터 데이터베이스의 CommandLog 테이블은 최종 사용자가 2017 년 7 월 30 일 5:22 PM에 작성했습니다. 재해시 마스터 데이터베이스의 테이블이 복원되지 않을 수 있습니다.

• TraceFlag On

  • 추적 플래그 (1118)는 전체적으로 가능하다.

  • 추적 플래그 1222는 전체적으로 사용 가능합니다.

  • 추적 플래그 2371은 전체적으로 사용 가능합니다.

우선 순위 200 : 비 기본 서버 구성 :

• 에이전트 XP-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.

• 백업 체크섬 기본값-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.

• 백업 압축 기본값-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.

• 병렬 처리 비용 임계 값-이 sp_configure 옵션이 변경되었습니다. 기본값은 5이며 48로 설정되었습니다.

• max degree of parallelism-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 12로 설정되었습니다.

• max server memory (MB)-이 sp_configure 옵션이 변경되었습니다. 기본값은 2147483647이며 128000으로 설정되었습니다.

• 임시 작업에 최적화-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.

• show advanced options-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.

• xp_cmdshell-이 sp_configure 옵션이 변경되었습니다. 기본값은 0이며 1로 설정되었습니다.

우선 순위 200 : 신뢰성 :

• 마스터의 확장 저장 프로 시저

• master-[sqbdata] 확장 저장 프로 시저가 master 데이터베이스에 있습니다. CLR이 사용 중일 수 있으며 이제 마스터 데이터베이스가 백업 / 복구 계획의 일부 여야합니다.

  • master-[sqbdir] 확장 저장 프로 시저가 master 데이터베이스에 있습니다. CLR이 사용 중일 수 있으며 이제 마스터 데이터베이스가 백업 / 복구 계획의 일부 여야합니다.

  • master-[sqbmemory] 확장 저장 프로 시저가 master 데이터베이스에 있습니다. CLR이 사용 중일 수 있으며 이제 마스터 데이터베이스가 백업 / 복구 계획의 일부 여야합니다.

  • master-[sqbstatus] 확장 저장 프로 시저가 master 데이터베이스에 있습니다. CLR이 사용 중일 수 있으며 이제 마스터 데이터베이스가 백업 / 복구 계획의 일부 여야합니다.

  • master-[sqbtest] 확장 저장 프로 시저가 master 데이터베이스에 있습니다. CLR이 사용 중일 수 있으며 이제 마스터 데이터베이스가 백업 / 복구 계획의 일부 여야합니다.

  • master-[sqbtestcancel] 확장 저장 프로 시저가 master 데이터베이스에 있습니다. CLR이 사용 중일 수 있으며 이제 마스터 데이터베이스가 백업 / 복구 계획의 일부 여야합니다.

  • master-[sqbteststatus] 확장 저장 프로 시저가 master 데이터베이스에 있습니다. CLR이 사용 중일 수 있으며 이제 마스터 데이터베이스가 백업 / 복구 계획의 일부 여야합니다.

  • master-[sqbutility] 확장 저장 프로 시저가 master 데이터베이스에 있습니다. CLR이 사용 중일 수 있으며 이제 마스터 데이터베이스가 백업 / 복구 계획의 일부 여야합니다.

  • master-[sqlbackup] 확장 저장 프로 시저가 master 데이터베이스에 있습니다. CLR이 사용 중일 수 있으며 이제 마스터 데이터베이스가 백업 / 복구 계획의 일부 여야합니다.

우선 순위 210 : 비 기본 데이터베이스 구성 :

• 커밋 된 스냅 샷 격리 읽기 사용-이 데이터베이스 설정이 기본값이 아닙니다.

  • 레드 게이트

  • RedGateMonitor

• Snapshot Isolation Enabled-이 데이터베이스 설정이 기본값이 아닙니다.

  • 레드 게이트

  • RedGateMonitor

우선 순위 240 : 대기 통계 :

• 1-SOS_SCHEDULER_YIELD-1770.8 시간의 대기, 시간당 115.9 분의 평균 대기 시간, 100.0 % 신호 대기, 1419212079 대기 작업, 4.5ms 평균 대기 시간.

우선 순위 250 : 정보 제공 :

• SQL Server가 NT 서비스 계정으로 실행 중입니다. NT Service \ MSSQLSERVER로 실행 중입니다. 대신 Active Directory 서비스 계정이 있었으면합니다.

우선 순위 250 : 서버 정보 :

• 기본 추적 내용-기본 추적은 2018 년 4 월 14 일 11:21 PM과 2018 년 4 월 16 일 11:13 AM 사이에 36 시간의 데이터를 보유합니다. 기본 추적 파일은 C : \ Program Files \ Microsoft SQL Server \ MSSQL13.MSSQLSERVER \ MSSQL \ Log에 있습니다.

• C 드라이브 공간-C 드라이브에서 196816.00MB 무료

• 드라이브 D 공간-E 드라이브에서 비어있는 894823.00MB

• 드라이브 L 공간-F 드라이브에서 1361367.00MB 여유 공간

• T 드라이브-G 드라이브에서 114441.00MB의 여유 공간

• 하드웨어-논리 프로세서 : 12. 실제 메모리 : 144GB.

• 하드웨어-NUMA 구성

  • 노드 : 0 상태 : 온라인 온라인 스케줄러 : 4 오프라인 스케줄러 : 2 프로세서 그룹 : 0 메모리 노드 : 0 메모리 VAS 예약 GB : 186

  • 노드 : 1 상태 : 오프라인 온라인 스케줄러 : 0 오프라인 스케줄러 : 6 프로세서 그룹 : 0 메모리 노드 : 0 메모리 VAS 예약 GB : 186

• 인스턴트 파일 초기화 사용-서비스 계정에 볼륨 유지 관리 작업 수행 권한이 있습니다.

• 전원 계획-서버에 2.60GHz CPU가 있고 균형 전원 모드에 있습니다. 어 .. CPU를 최고 속도로 실행 하시겠습니까?

• 서버 마지막 재시작-2018 년 3 월 9 일 오전 7:27

• 서버 이름-[편집 됨]

• 서비스

  • 서비스 : SQL Server (MSSQLSERVER)는 서비스 계정 NT Service \ MSSQLSERVER에서 실행됩니다. 마지막 시작 시간 : 2018 년 3 월 9 일 오전 7:27 시작 유형 : 자동, 현재 실행 중

  • 서비스 : SQL Server 에이전트 (MSSQLSERVER)는 서비스 계정 LocalSystem에서 실행됩니다. 마지막 시작 시간 : 표시되지 않음. 시작 유형 : 자동, 현재 실행 중입니다.

• SQL Server 마지막 ​​다시 시작-2018 년 3 월 9 일 오전 6:27

• SQL Server 서비스-버전 : 13.0.4466.4. 패치 레벨 : SP1. 누적 업데이트 : CU7. 에디션 : Standard Edition (64 비트). 가용성 그룹 사용 : 0. 가용성 그룹 관리자 상태 : 2

• 가상 서버-유형 : (하이퍼 바이저)

• Windows 버전-최신 버전의 Windows : Server 2012R2 시대, 버전 6.3을 실행 중입니다.

우선 순위 254 : 실행 일 :

• 함장의 일지 : 무엇인가를 별표로 표시 ...

일부 CPU 노드 및 / 또는 메모리 노드가 오프라인 상태가되도록 가상 CPU를 구성한 것 같습니다.

다운로드 sp_Blitz (: 그 무료 오픈 소스 스크립트의 저자 중 한 명이야 부인을)하고 실행 :

sp_Blitz @CheckServerInfo = 1;

오프라인 상태 인 CPU 및 / 또는 메모리 노드에 대한 경고를 찾으십시오. SQL Server Standard Edition은 처음 4 개의 CPU 소켓 만 볼 수 있으며 VM을 6 개의 듀얼 코어 CPU와 같이 구성했을 수 있습니다. Enterprise Edition의 20 코어 제한이 볼 수있는 메모리 양을 제한하는 방식 과 비슷한 문제가 발생합니다 .

sp_Blitz의 출력을 여기에서 공유하려면 다음과 같이 Markdown으로 출력하여 질문에 복사 / 붙여 넣을 수 있습니다.

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

2018/04/16 업데이트-확인되었습니다.sp_Blitz 출력을 연결했습니다 (감사합니다!). 실제로 CPU 및 메모리 노드가 오프라인 상태임을 나타냅니다. VM을 만든 사람은 누구나 12 개의 단일 코어 CPU로 구성하므로 SQL Server Standard Edition은 처음 4 개의 소켓 (코어)과 연결된 메모리 만 볼 수 있습니다.

이를 수정하려면 VM을 종료하고 2 소켓, 6 코어 VM으로 구성하면 SQL Server Standard Edition에서 모든 코어와 메모리를 볼 수 있습니다. 또한 SOS_SCHEDULER_YIELD의 대기 시간도 줄어 듭니다. 지금 당장 SQL Server가 처음 4 개의 코어를 망치고 있습니다. 이 수정 후에는 12 개 코어 모두에서 작동 할 수 있습니다.

브렌트 오자르의 행동 계획에 대한 부록으로서 나는 결과를 공유하고 싶었다. Brent가 지적했듯이 VMware 내에서 12 개의 단일 코어 CPU로 가상 머신을 잘못 구성했습니다. 이로 인해 나머지 8 개의 코어에 SQL Server가 액세스 할 수 없었으므로 원래 질문에 설명 된 메모리 문제가 발생했습니다. 우리는 VM을 적절하게 재구성하기 위해 어젯밤 서비스를 유지 관리 모드로 전환했습니다. 메모리가 정상적인 방식으로 증가 할뿐만 아니라 Brent도 암시 한 것처럼 대기 수는 기하 급수적으로 감소했으며 전체 SQL Server 성능은 급등했습니다. vNUMA 구성은 이제 워크로드를 통해 조각난 작은 구성 요소입니다.

VMware vSphere 6.5를 사용하는 사용자의 경우 Brent에서 설명하는 작업 항목을 완료하는 간단한 단계는 다음과 같습니다.

1. VMware 클러스터의 vSphere Web Client에 로그인하고 SQL Server를 호스팅하는 가상 시스템을 찾습니다. CPU 및 메모리 구성을 조정하려면 VM이 오프라인 상태 여야합니다.

2. 기본 창에서로 이동하여 오른쪽 상단 Configure > VM hardware의 Edit버튼을 클릭합니다 . 가있는 상황에 맞는 메뉴가 열립니다 Edit Settings. 참고로 아래 이미지는 잘못된 구성입니다. 로 Cores per Socket설정했습니다 1. SQL Server Standard Edition의 제한 사항을 감안할 때 이는 잘못된 구성입니다.

   

3. 수정은 Cores per Socket값 을 조정하는 것만 큼 간단 합니다. 우리의 경우에는을 6갖도록 설정했습니다 2 Sockets. 이를 통해 SQL Server는 12 개의 프로세서를 모두 사용할 수 있습니다.

   

중요 사항 : 할 일이 어느 위치로 값을 설정하지 Number of Cores또는이 Sockets홀수가 될 것입니다. NUMA는 균형을 좋아하며 일반적으로 2로 나눌 수 있어야합니다. 예를 들어, 4 개의 코어에서 3 개의 소켓으로 구성된 구성은 불균형합니다. 실제로이 sp_Blitz유형의 구성 으로 실행 하는 경우 이에 대한 경고가 표시됩니다.

VMware vSphere에서 Microsoft SQL Server 설계 (PDF 경고)의 3.3 절 에이 내용이 자세히 설명되어 있습니다. 백서에 요약 된 사례는 대부분의 온-프레미스 SQL Server 가상화에 적용됩니다.

다음은 브렌트 포스트 이후의 연구를 통해 편집 한 자료입니다.

• 대용량 데이터베이스 가상화-VMware CPU 용량 계획

• 가상 시스템 vCPU 및 vNUMA Rightsizing – 규칙

• vSphere 6.5의 가상 NUMA 토폴로지에서 소켓 당 코어 분리

지난 24 시간 동안 RedGate SQL Monitor에서 캡처를 마치겠습니다. 가장 주목할 점은 CPU 사용률과 대기 수입니다. 어제 사용량이 많은 시간 동안 CPU 사용량이 많고 대기 경합이 발생했습니다. 이 간단한 수정 후에는 성능이 10 배 향상되었습니다. 디스크 I / O조차도 크게 줄었습니다. 이것은 가상 성능을 몇 배나 향상시킬 수있는 겉으로는 쉽게 간과되는 설정입니다. 적어도, 그것은 우리의 엔지니어와 완벽한 간과되었다 디부 오 순간.

또한 MSDN 에 따르면 SQL Server 표준은 64GB의 RAM으로 제한됩니다. 데이터베이스를 여러 인스턴스로 분할하여이를 해결했지만 상황에 따라 허용되지 않을 수 있습니다.

흠 2016은 128GB를 제한으로 보이지만 인스턴스 분할은 여전히 ​​옵션 일 수 있습니다.