SQL Server'ın “Toplam Sunucu Belleği” tüketimi 64 GB + daha fazla olan aylarca durgun

SQL Server 2016 Standard Edition 64-bit'in, kendisine ayrılan toplam belleğin tam yarısında (64 GB 128 GB) tam olarak kendini kapatmış gibi göründüğü tuhaf bir sorunla karşılaştım.

Çıktısı @@VERSION:

Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119) - 13.0.4466.4 (X64) Aralık 22 2017 11:25:00 Telif Hakkı (c) Windows Server 2012 R2 Datacenter 6.3'te Microsoft Corporation Standard Edition (64-bit) (64) Yapı 9600:) (Hiper Yönetici)

Çıktısı sys.dm_os_process_memory:

Ben sorgu zaman sys.dm_os_performance_counters, görüyorum Target Server Memory (KB)altındadır 131072000ve Total Server Memory (KB)sadece bu yarısından altında en altındadır 65308016. Çoğu senaryoda, bunun normal bir davranış olduğunu anlayacağım, çünkü SQL Server henüz kendisinin daha fazla bellek ayırması gerektiğine karar vermedi.

Ancak, 2 aydan fazla bir süredir ~ 64GB'da "sıkışmış". Bu süre zarfında, bazı veritabanlarında önemli miktarda bellek yoğun işlem gerçekleştirdik ve bu örneğe 40'a yakın veri tabanı ekledik. Toplamda 292 veritabanında oturuyoruz, her biri 4 MB’da önceden ayrılmış veri dosyaları, 256 MB’lık otomatik büyüme oranı ve 128 MB’lik otomatik büyüme oranı olan 2 GB günlük dosyaları. Her gece 12: 00'de tam bir yedekleme yapıyorum ve her 15 dakikada bir Pazartesi-Cuma günleri 6: 00'dan 20: 00'a kadar işlem günlüğü yedeklemelerine başladım. Bu veri tabanları genel işlem hacmi bakımından nispeten düşüktür, ancak SQL Server’ınTarget Server Memory doğal olarak yeni veritabanı eklemeleri, normal sorgu yürütmeleri ve çalıştırılan bellek yoğun ETL boru hatları aracılığıyla.

SQL Server örneğinin kendisi sanallaştırılmış (VMware) bir Windows Server 2012R2 sunucusunda 12 CPU, 144 GB bellek (128 GB, SQL Server'a 128 GB, Windows için 16 GB ayrılmış) ve 15K SAS sürücülü bir vSAN'a oturan 4 sanal disk üzerinde oturuyor . Windows doğal olarak 64 GB'lık bir C: diskinde ve 32GB'lık bir sayfa dosyasına sahip. Veri dosyaları 2 TB'lık bir D: diskine oturur, günlük dosyaları 2 TB'lık bir L: diskin üstüne oturur ve tempdb 256 GB'lık bir T: diskine oturur ve 8x16GB'lık dosyaları otomatik büyütmez.

Sunucuda çalışan başka bir SQL Server örneği olmadığını doğruladım MSSQLSERVER.

Bu sunucu tamamen yalnızca SQL Server örneğine adanmıştır, bu nedenle üzerinde çalışan başka bir uygulama veya servisimiz bulunmamaktadır.

RedGate SQL Monitor'ü analiz için kullanıyorum ve aşağıda son 18 günün tarihi Total Server Memory. Gördüğünüz gibi, bellek kullanımı Nisan ayının başlarında ~ 300 MB'lık tek bir artıştan yana tamamen durgun kaldı.

Bunun nedeni ne olabilir? SQL Server'ın kendisine ayrılan 64GB + ek bellek miktarını neden kullanmak istemediğini belirlemek için nelere daha yakından bakabilirim?

Çalışan çıktı sp_Blitz:

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

Öncelik 50: Performans :

• İşlemci Zamanlayıcıları Çevrimdışı - Benzeşim maskeleme veya lisanslama sorunları nedeniyle, bazı CPU çekirdeğine SQL Server erişilemez.

• Çevrimdışı Bellek Düğümleri - Benzeşme maskeleme veya lisans sorunları nedeniyle, belleğin bir kısmı kullanılamayabilir.

Öncelik 50: Güvenilirlik :

• Remote DAC Disabled - Dedicated Admin Connection'a (DAC) uzaktan erişim etkin değil. DAC, SQL Server yanıt vermediğinde uzaktan sorun gidermeyi çok daha kolay hale getirebilir.

Öncelik 100: Performans :

• Bir Sorgu İçin Birçok Plan - 300 plan önbelleğindeki tek bir sorgu için var - yani muhtemelen parametre sorunlarımız var.

• Sunucu Tetikleyicileri Etkin

  • Sunucu Tetikleyicisi [RG_SQLLighthouse_DDLTrigger] etkin. Bu tetikleyicinin ne yaptığını anladığınızdan emin olun - ne kadar az iş yaparsa o kadar iyi.

  • Sunucu Tetikleyicisi [SSMSRemoteBlock] etkin. Bu tetikleyicinin ne yaptığını anladığınızdan emin olun - ne kadar az iş yaparsa o kadar iyi.

Öncelik 150: Performans :

• Sorguları Birleştirme İpuçlarını Zorlama - Yeniden başlatmadan bu yana 1480 birleştirme ipucu örneği kaydedildi. Bu, sorguların SQL Server optimize edicisinin etrafında durduğu anlamına gelir ve ne yaptıklarını bilmiyorlarsa, bu durum yarardan çok zarar verebilir. Bu ayrıca DBA ayarlama çabalarının neden işe yaramadığını da açıklayabilir.

• Sorguları Zorlama Emri İpuçları - Yeniden başlatılmasından bu yana 2153 emir ipucu örnekleri kaydedildi. Bu, sorguların SQL Server optimize edicisinin etrafında durduğu anlamına gelir ve ne yaptıklarını bilmiyorlarsa, bu durum yarardan çok zarar verebilir. Bu ayrıca DBA ayarlama çabalarının neden işe yaramadığını da açıklayabilir.

Öncelik 170: Dosya Yapılandırması :

• C Sürücüde Sistem Veri Tabanı

  • master - Master veritabanı, C sürücüsünde bir dosyaya sahiptir. Sistem veritabanlarını C sürücüsüne yerleştirmek, alanı yetersiz kaldığında sunucunun çökme riski taşır.

  • model - Model veritabanında C sürücüsünde bir dosya bulunur. Sistem veritabanlarını C sürücüsüne yerleştirmek, alanı yetersiz kaldığında sunucunun çökme riski taşır.

  • msdb - msdb veri tabanı C sürücüsünde bir dosyaya sahiptir. Sistem veritabanlarını C sürücüsüne yerleştirmek, alanı yetersiz kaldığında sunucunun çökme riski taşır.

Öncelik 200: Bilgilendirici :

• Aynı Anda Başlayan Ajan İşleri - Birden fazla SQL Server Ajan işi aynı anda başlayacak şekilde yapılandırılmıştır. Ayrıntılı program listeleri için, URL'deki sorguyu görün.

• Ana Veri Tabanı master'ındaki tablolar - Ana veri tabanındaki CommandLog tablosu 30 Temmuz 2017 17:22 tarihinde son kullanıcılar tarafından oluşturuldu. Bir felaket durumunda ana veritabanındaki tablolar geri yüklenmeyebilir.

• TraceFlag On

  • Izleme bayrağı 1118 genel olarak etkindir.

  • Izleme bayrağı 1222 genel olarak etkindir.

  • İzleme bayrağı 2371 genel olarak etkindir.

Öncelik 200: Varsayılan Olmayan Sunucu Yapılandırması :

• Ajan XP'ler - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 0'dır ve 1 olarak ayarlanmıştır.

• yedekleme sağlama toplamı varsayılanı - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 0'dır ve 1 olarak ayarlanmıştır.

• yedekleme sıkıştırma varsayılanı - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 0'dır ve 1 olarak ayarlanmıştır.

• Paralellik için maliyet eşiği - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 5'tir ve 48 olarak ayarlanmıştır.

• maksimum paralellik derecesi - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 0'dır ve 12 olarak ayarlanmıştır.

• maksimum sunucu belleği (MB) - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 2147483647'dir ve 128000 olarak ayarlanmıştır.

• geçici iş yükleri için optimize et - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 0'dır ve 1 olarak ayarlanmıştır.

• gelişmiş seçenekleri göster - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 0'dır ve 1 olarak ayarlanmıştır.

• xp_cmdshell - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 0'dır ve 1 olarak ayarlanmıştır.

Öncelik 200: Güvenilirlik :

• Master'da Genişletilmiş Saklı İşlemler

• master - [sqbdata] genişletilmiş saklı yordam ana veritabanında bulunur. CLR kullanımda olabilir ve ana veritabanının şimdi yedekleme / kurtarma planlamanızın bir parçası olması gerekir.

  • master - [sqbdir] genişletilmiş saklı yordam ana veritabanında bulunur. CLR kullanımda olabilir ve ana veritabanının şimdi yedekleme / kurtarma planlamanızın bir parçası olması gerekir.

  • master - [sqbmemory] genişletilmiş saklı yordam ana veritabanında bulunur. CLR kullanımda olabilir ve ana veritabanının şimdi yedekleme / kurtarma planlamanızın bir parçası olması gerekir.

  • master - [sqbstatus] genişletilmiş saklı yordam ana veritabanında bulunur. CLR kullanımda olabilir ve ana veritabanının şimdi yedekleme / kurtarma planlamanızın bir parçası olması gerekir.

  • master - [sqbtest] genişletilmiş saklı yordam ana veritabanında bulunur. CLR kullanımda olabilir ve ana veritabanının şimdi yedekleme / kurtarma planlamanızın bir parçası olması gerekir.

  • master - [sqbtestcancel] genişletilmiş saklı yordam ana veritabanında bulunur. CLR kullanımda olabilir ve ana veritabanının şimdi yedekleme / kurtarma planlamanızın bir parçası olması gerekir.

  • master - [sqbteststatus] genişletilmiş saklı yordam ana veritabanında bulunur. CLR kullanımda olabilir ve ana veritabanının şimdi yedekleme / kurtarma planlamanızın bir parçası olması gerekir.

  • master - [sqbutility] genişletilmiş saklı yordam ana veritabanında bulunur. CLR kullanımda olabilir ve ana veritabanının şimdi yedekleme / kurtarma planlamanızın bir parçası olması gerekir.

  • master - [sqlbackup] genişletilmiş saklı yordam ana veritabanında bulunur. CLR kullanımda olabilir ve ana veritabanının şimdi yedekleme / kurtarma planlamanızın bir parçası olması gerekir.

Öncelik 210: Varsayılan Olmayan Veritabanı Konfigürasyonu :

• Okuma Taahhütlü Anlık Görüntü İzolasyonu Etkin - Bu veritabanı ayarı varsayılan değildir.

  • RedGate

  • RedGateMonitor

• Anlık Görüntü İzolasyonu Etkin - Bu veritabanı ayarı varsayılan değildir.

  • RedGate

  • RedGateMonitor

Öncelik 240: Bekleme İstatistikleri :

• 1 - SOS_SCHEDULER_YIELD - 1770.8 saat bekleme, saatte ortalama 115,9 dakika bekleme,% 100,0 sinyal bekleme, 1419212079 bekleme görevi, 4,5 ms ortalama bekleme süresi.

Öncelik 250: Bilgilendirici :

• SQL Server bir NT Service hesabı altında çalışıyor - NT Service \ MSSQLSERVER olarak çalışıyorum. Keşke bunun yerine bir Active Directory servis hesabım olsaydı.

Öncelik 250: Sunucu Bilgisi :

• Varsayılan İz İçeriği - Varsayılan iz, Nis 14 2018 11:21 ve 16 Nisan 2018 11:13 saatleri arasında 36 saatlik veri tutar. Varsayılan izleme dosyaları bulunur: C: \ Program Files \ Microsoft SQL Server \ MSSQL13.MSSQLSERVER \ MSSQL \ Log

• C Alanı - 196816.00MB C sürücüsünde ücretsiz

• D Yeri - E sürücüsünde 894823.00MB ücretsiz

• Drive L Space - F sürücüsünde 1361367.00MB ücretsiz

• Drive T Space - 114441.00MB G sürücüsünde ücretsiz

• Donanım - Mantıksal işlemciler: 12. Fiziksel bellek: 144GB.

• Donanım - NUMA Config

  • Düğüm: 0 Durum: ONLINE Çevrimiçi zamanlayıcılar: 4 Çevrimdışı zamanlayıcılar: 2 İşlemci Grubu: 0 Bellek düğümü: 0 Bellek VAS Ayrılmış GB: 186

  • Düğüm: 1 Durum: ÇEVRİMDIŞI Çevrimiçi zamanlayıcılar: 0 Çevrimdışı zamanlayıcılar: 6 İşlemci Grubu: 0 Bellek düğümü: 0 Bellek VAS Ayrılmış GB: 186

• Anında Dosya Başlatma Etkin - Hizmet hesabında Birim Bakım Görevleri Gerçekleştir izni var.

• Güç Planı - Sunucunuzda 2,60GHz CPU var ve dengeli güç modunda - Uh ... CPU'larınızın tam hızda çalışmasını istiyorsunuz, değil mi?

• Sunucu Son Yeniden Başlatma - Mar 9 2018 07:27

• Sunucu Adı - [düzenlenmiş]

• Hizmetler

  • Hizmet: SQL Server (MSSQLSERVER), NT Service \ MSSQLSERVER hizmet hesabı altında çalışır. Son başlangıç ​​saati: 9 Mar 2018 07:27. Başlangıç ​​türü: Otomatik, şu anda Çalışıyor.

  • Hizmet: SQL Server Agent (MSSQLSERVER), LocalSystem hizmet hesabı altında çalışır. Son başlangıç ​​zamanı: gösterilmiyor .. Başlangıç ​​tipi: Otomatik, şu anda Çalışıyor.

• SQL Server Son Yeniden Başlatma - Mar 9 2018 06:27

• SQL Server Hizmeti - Sürüm: 13.0.4466.4. Yama Seviyesi: SP1. Toplu Güncelleme: 7 PB. Sürüm: Standart Sürüm (64-bit). Kullanılabilirlik Grupları Etkin: 0 Kullanılabilirlik Grupları Yöneticisi Durum: 2

• Sanal Sunucu - Tür: (HYPERVISOR)

• Windows Sürümü - Windows'un oldukça modern bir sürümünü kullanıyorsunuz: Server 2012R2 dönemi, sürüm 6.3

Öncelik 254: Rundate :

• Kaptan'ın günlüğü: bir şey ve bir şey hakkında yıldız ...

Bahse girerim sanal CPU'ları, bazı CPU ve / veya bellek düğümlerinin çevrimdışı olduğu şekilde yapılandırmışsınızdır.

Sp_Blitz'i indirin (yasal uyarı: Bu ücretsiz açık kaynaklı komut dosyasının yazarlarından biriyim):

sp_Blitz @CheckServerInfo = 1;

CPU ve / veya bellek düğümleri çevrimdışı olma konusunda uyarılar arayın. SQL Server Standard Edition yalnızca ilk 4 CPU soketini görür ve VM'yi 6 çift çekirdekli CPU gibi bir şey olarak yapılandırmış olabilirsiniz. Enterprise Edition’ın 20 çekirdekli limitlerini görebildiğiniz bellek miktarını sınırlamaya benzer bir konuya varacaksınız .

Sp_Blitz'in çıktısını burada paylaşmak istiyorsanız, bu şekilde çalıştırarak Markdown'a çıktısını alabilirsiniz.

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

2018/04/16 Güncellemesi - onaylandı. Sp_Blitz çıkışını eklediniz (bunun için teşekkürler!) Ve aslında CPU ve bellek düğümlerinin çevrimdışı olduğunu gösteriyor. VM'yi her kim yaptıysa, onu 12 tek çekirdekli CPU olarak yapılandırdı, bu nedenle SQL Server Standard Edition yalnızca ilk 4 soketi (çekirdeği) ve bunlara bağlı belleği görüyor.

Düzeltmek için VM'yi kapatın, 2 soketli, 6 çekirdekli VM olarak yapılandırın ve ardından SQL Server Standard Edition tüm çekirdeği ve belleği görecektir. Bu aynı zamanda SOS_SCHEDULER_YIELD'inizi de azaltacaktır - şu anda, SQL Server'ınız ilk 4 çekirdeği kırıyor, ama hepsi bu. Bu düzeltmeden sonra, 12 çekirdeğin hepsinde de çalışabilecek.

Brent Ozar'ın eylem planına ek olarak sonuçları paylaşmak istedim. Brent'in belirttiği gibi, VMware'de Sanal Makineyi 12 adet tek çekirdekli CPU ile yanlış bir şekilde yapılandırdık. Bu, kalan 8 çekirdeğin SQL Server tarafından erişilememesiyle sonuçlandı ve sonuç olarak orijinal sorumda açıklanan bellek sorununa yol açtı. Sanal Makineyi uygun şekilde yapılandırmak için hizmetlerimizi dün gece bakım moduna geçirdik. Sadece hafızanın normal bir şekilde kaydığını görmekle kalmıyoruz, Brent'in de belirttiği gibi, bekleme sayısı katlanarak azaldı ve genel SQL Server performansımız fırladı. VNUMA yapılandırmaları artık iş yüklerimizi kesip alan küçük mutlu bileşenlerdir.

VMware vSphere 6.5 kullananlar için Brent tarafından açıklanan aksiyon öğesinin tamamlanması için kısa adımlar aşağıdaki gibidir.

1. VMware kümeniz için vSphere Web İstemcisi'ne giriş yapın ve SQL Server'ı barındıran Sanal Makine'ye göz atın. CPU ve bellek yapılandırmalarını ayarlamak için VM'niz çevrimdışı olmalıdır.

2. Birincil bölmede, sağ üst köşedeki düğmeyi Configure > VM hardwaretıklayın Edit. Sahip olduğunuz bir içerik menüsü açacaksınız Edit Settings. Başvuru için, aşağıdaki resim yanlış yapılandırma. Cores per SocketAyarladığımı unutmayın 1. SQL Server Standard Edition'ın sınırlamaları göz önüne alındığında, bu kötü bir yapılandırmadır.

   

3. Düzeltme, Cores per Socketdeğeri ayarlamak kadar basittir . Bizim durumumuzda, biz ayarlayın 6elimizdeki böylece 2 Sockets. Bu, SQL Server'ın tüm 12 işlemciyi kullanmasını sağlar.

   

Önemli bir not: Değeri, tek Number of Coresveya Socketsbir tuhaf sayı olacak şekilde ayarlamayın. NUMA dengeyi sever ve kurallara göre 2 ile bölünebilir olması gerekir. Örneğin, 4 çekirdekli 3 çekirdekli bir konfigürasyon dengesizleşebilir. Aslında, eğer sp_Blitzbu tür bir konfigürasyonla koşacak olsaydınız, bu konuda bir uyarı verirdi.

VMware vSphere'de Microsoft SQL Server Mimarisinde Bölüm 3.3 (PDF uyarısı) bunu ayrıntılı olarak açıklamaktadır. Teknik incelemede açıklanan uygulamalar, SQL Server'ın şirket içi sanallaştırmasının çoğunda uygulanabilir.

Brent’in görevinden sonra araştırmayla derlediğim birkaç kaynak daha:

• Büyük veritabanlarını sanallaştırma - VMware CPU kapasite planlaması

• Sanal Makine vCPU ve vNUMA Hak Düzenleme - Temel Kurallar

• VSphere 6.5'teki Soket Başına Çekirdeklerin Sanal NUMA Topolojisinden Ayrılması

Son 24 saat içinde RedGate SQL Monitor'dan bir yakalamaya son vereceğim. Öncelikli not, CPU kullanımı ve bekleme sayısıdır - dün yoğun saatlerimizde, yoğun CPU kullanımı ve bekleme istekleri yaşadık. Bu basit düzeltmeden sonra performansımızı on kat geliştirdik. Hatta disk G / Ç'lerimiz bile önemli ölçüde azaldı. Bu, büyüklük sırasına göre sanal performansı artırabilecek görünüşte kolayca gözden kaçan bir ayardır. En azından, mühendislerimiz ve tam bir o gün anı göz ardı edildi .

Ayrıca, MSDN’ye göre , SQL Server standardı 64 GB RAM’le sınırlıdır. Bunu veritabanını birden çok örneğe bölerek 'çözdük', ancak durumunuz buna izin vermeyebilir.

Hmm 2016'nın limiti 128GB gibi görünüyor, ancak örnek bölünmesi hala bir seçenek olabilir.